Software Request to Fanuc - the robot forum bugs and wish list

    RG should support more dirrent kind of file types. Not only iges when importin parts/fixtures etc. to RG.


    Also would be nice if Fanuc would make new tool like what they have earlier to make easily tp prorams. The program package was WinOLPC and there was program called WinTpe...That is/was best;=)

    I have a cell I'm working with right now that is based around WeldPRO...but I cannot import a robot that has LR Handling Tool into it, but if I could change the backup to HandlingTool, then I could import it. Maybe just an oversight or restrictions with the software, don't know. Would be nice to be able to mix and mingle whatever we need.


    EDIT: Oh and not a real major want/need, but more for the "cool" factor - VR support like ABB's software has.

    I would advocate to get rid of all the different core "Tool" softwares. Move to a single core operating system and have handling, welding, painting, dispensing, palletizing as plugins that can be added. The way it is now there is too much disparity between the different software packages. It doesn't feel cohesive and causes confusion.

  • Werner Hampel

    Changed the title of the thread from “Software Request to Fanuc - the robot forum wish list” to “Software Request to Fanuc - the robot forum bugs and wish list”.

    This is a hardware request instead of a software request;


    Put a feed-rate knob on the teach pendant. No more having to switch SHFTOV_ENB between I'm puckering because this is new code and this robot has run forever and I want to switch it quickly.

    I would like to see a number of changes to iRProgrammer that push it in the direction of a fully fledged TP IDE rather than a teach pendant alternative.


    My first big complaint is with the real-time compiling/Error checking forcing you to correct an invalid line immediately rather than just highlighting it. This also applies to copy pasted code which contains errors. It seems like there is already some limited support for this in the teach pendant editor (which will mark repeat LBL's with an asterisk and allow incomplete lines; both unsupported in the IRP editor). I think its great that it has error checking, just not great when it breaks my flow or doesn't allow me to make some sudo code and fill in the blanks later.


    I'd also like to see a way to permanently adjust or remove certain PC editor window elements. The position data window, jog window and especially the command list window are all but useless. Luckily you are able to resize and hide these windows...until you refresh or reopen the editor. This is doubly annoying if you open two windows side by side (and now have two jog windows, double the jogging!) and are forced to resize all 6 elements again. Clearly this is partly an issue with iRProgrammer being web interface based rather than a windows API based but I hope window layout could still be saved/cached.


    One of the more useful features of iRProgrammer is having side by side editor windows that can easily be copy and pasted between. However, after cycling the TP enabling switch on and off, the secondary editor window is covered with a grey overlay. I assume this is to mimic the behavior of the teach pendant only allowing programs to be run from the left hand window and to avoid conflicting data. However, there has to be a better way to accomplish this, not only because it prevents you from using the helpful Copy/Paste... but also because it can be circumnavigated by just deleting the "screenoverlay-exec" from the page source.

    Quote from domo_arigato

    Fun little trick with this one; you can create an empty SCARA cell, log into the iRProgrammer via your browser, build the programs, save them using a file back up, then copy the .TP files to another controller/workcell (as long as there are no SCARA specific commands or commands relying on software packages not present on both controllers).


    I've found this to be useful when I'm in the psuedocode stage of programming as it's a bit cumbersome to go through the whole process for just one or two programs; I also agree that the iRProgrammer is a huge step up but also very, very wonky at times. If they stopped iRProgrammer from compiling, throwing errors, and locking down any keyboard progress after every line entry, I'd be much, much happier with it.

    You are now able to serialize any roboguide cell with the IRprogrammer option, regardless of robot model.

    I don't believe I've mentioned this yet (didn't see it in my comment above)...But this one is simple and WHY do we NOT have the ability to do this yet...


    EDIT IIC ZONES LIKE SPACE CHECK/DCS! SERIOUSLY! Haha...Unless I'm missing something...I'm making a random Obstacle Box, positioning it in the CHUI world where I want the IIC Zone to be, Measure from Robot Zero to vertexes of the box, then inputting those numbers into the TP.


    But once again FANUC, seriously...why we can't edit IIC zones just as we can DCS and Space Check Function?? :uglyhammer2:


    Oh and one more thing: WHen setting up Parts on a tool, allow us to turn on/off multiple inputs. Like if a part would cover more than 1 prox, let us turn on RI:1 & 2-#...Rather than turn on R1, have BG_SIM job that says "Oh RI:1 is on and this is this part? Well then RI:2 and RI:3 are on as well"

    I don't think its been mentioned, but how about release notes for robot software auto-updates?


    It'd be really nice to know if the update that I'm about to apply can be expected to fix a given issue, or where I should be keeping an eye out for any possible changes. (Should I change my written operating instructions since a workaround isn't needed or might have an undesirable effect if said instructions are followed?)


    P.S: "General bugfixes" does not count as release notes.

    Default the TYPE under the SELECT screen to TP Programs or give the ability to create a default.


    When setting up virtually anything where you are recording a point and then have the ability to move to that point... do not put the moveto right next to the record. In fact moveto should be consistently on F2 and Record on F5... Far Far away from each other.


    Command instruction items should be more consistent. For example PR[i,j] jumps around all over the place in the instructions. Put it at the same level, same number every time. Same with many of the others that we use all the time.


    I LOVE that the HOLD or PAUSE button on a Motoman is a big round button at the top instead of hidden in the middle of the teach pendant on a Fanuc. Got to get operators and maintenance people to stop E-stopping the robot to stop the process normally, and get them using the hold button. It would be better if it was large and in charge!


    Should be more than one way to get out of a Controlled Start. Should also be able to hold down the Prev/Next keys and get out of it that way as well. Not intuitive at all for beginners.


    On the teach pendant, just make the blasted keyboard come up automatically instead of having to cursor down to Options/Keyboard then F5. I know we're building on old software, but why not save people some time...


    It's the little things that can make all the difference!

    Develop a wireless pendant with docking station so that when the pendant is docked it serves the purpose of the cable, but when undocked it communicates to the controller via Bluetooth or a wireless network. Also, having the ability to control multiple robots from a single pendant by selecting the robot you want to control would be great. I know there are safety device issues that must be hard wired, but I know other robot manufacturers have developed wireless pendants, so it shouldn't be impossible for FANUC to figure it out.

    Quote from white_raven

    Develop a wireless pendant with docking station so that when the pendant is docked it serves the purpose of the cable, but when undocked it communicates to the controller via Bluetooth or a wireless network. Also, having the ability to control multiple robots from a single pendant by selecting the robot you want to control would be great. I know there are safety device issues that must be hard wired, but I know other robot manufacturers have developed wireless pendants, so it shouldn't be impossible for FANUC to figure it out.

    I doubt that it is dependent on technical matters. More likely it has to do that the automotive industry doesn't want it. So therefor Fanuc lacks the financial incitement to implement the technology.

    But I agree, those cables have a tendency to get all tangled up. Although I know that they sell cable reels to fit the controller, for more easy handling of the cables...

    Quote from gpunkt

    I doubt that it is dependent on technical matters. More likely it has to do that the automotive industry doesn't want it. So therefor Fanuc lacks the financial incitement to implement the technology.

    But I agree, those cables have a tendency to get all tangled up. Although I know that they sell cable reels to fit the controller, for more easy handling of the cables...

    I work in the automotive industry, and our plant management has asked me about it before because of all the downtime we experience due to cables being cut and tangled together. We already have cable reels installed on all of our controllers but that doesn't really solve the problem. The operators and process techs still leave them strung out to be cut and damaged, and we have no way to track who is leaving them in that condition to discipline them. I explained to them all the reasoning as to why they don't make wireless pendants for industrial applications, but they didn't seem satisfied.

    Quote from white_raven

    I work in the automotive industry, and our plant management has asked me about it before because of all the downtime we experience due to cables being cut and tangled together. We already have cable reels installed on all of our controllers but that doesn't really solve the problem. The operators and process techs still leave them strung out to be cut and damaged, and we have no way to track who is leaving them in that condition to discipline them. I explained to them all the reasoning as to why they don't make wireless pendants for industrial applications, but they didn't seem satisfied.

    Wireless teach pendants have been in the RIA safety specfor ten years now. But none of the "tentpole" customers appear to have been willing to be the guinea pigs for the first actual release. Your managers may want wireless TPs, but I'd bet your corporate safety office would have a very different reaction if anyone asked them -- that's been my experience in the industry.

    Quote from Matthew Fuller

    On the teach pendant, just make the blasted keyboard come up automatically instead of having to cursor down to Options/Keyboard then F5. I know we're building on old software, but why not save people some time...

    Maybe have this as an option... But I think I would strangle the software engineer involved if the touch keyboard came up every time I tried to edit a register name etc...

Advertising from our partners