Posts by pdl

    Fydo Dido,


    Where did you get your current copy of RoboGuide?


    What type of license do you currently have for RoboGuide? You can check this out easily by opening the Fanuc License Manager from the start menu.


    If you have the correct license and are in the United States, you just need to download the latest version of RoboGuide from myportal.fanucamerica.com and run the installer (as admin). Part way through the installation, it will ask you what versions of Fanuc controllers that you want to install; just select version 7.5.


    You can install as many additional versions that you want, going back to V5.3, as long as you have the correct license.

    Your old and new code is the same, the only difference is that the "old" one was made with I/O comments enabled from the function menu.

    Can you post a picture of your encoder setup?


    From the sounds of it, you may not be able to detect your problem. If you can't detect it, you can't monitor it to pay an alarm

    Range, Rack, Slot, and Start are all covered in the forum already, you'll have to search. Just remember that Fanuc does not use zero-based numbering, so all indexes start at 1. I've attached a Fanuc rack number reference for future use.


    Your mapping for DO[101] - DO[108] is correct.


    You need to supply the outputs with 24vdc. You can supply this from pins 49/50, but I would highly recommend using an external 24vdc power supply.


    +24vdc needs to be supplied to "DOSRC1" pins 31/32

    0vdc needs to be connected to "0V" pins pins 17/18/29/30 if using an external supply


    Phoenix Contact makes an I/O breakout board which can come in handy. I would try to get one outside of Fanuc, they're pricey. The Fanuc p/n is A05B-2650-J071.


    Fanuc document B-83525EN is your friend when dealing with Mate controllers.

    From your explanations, it turns out that it is good idea, to have one or two points into the program, formatted in joints, in order to unwind the wrist of the robot.

    I think you are still confusing joint position representation and a joint move type.


    Code
    :J PR[1] 100% FINE;

    The above code is a JOINT MOVE to PR[1]. PR[1] could also be P[1], it doesn't matter.


    Code
    :L PR[1] 2000 mm/sec FINE;

    The above code is a LINEAR MOVE to PR[1]. Again, PR[1] could be P[1].


    Both of the above lines of code will move the robot to the same destination. However, the second line of code will move the robot's tool center point along a straight line from the starting position to the destination.


    While the robot's TCP may be in the same place at the end of either move instruction, the big difference is that a Joint move will take into account the turn numbers in the configuration, a linear move will ignore them.

    You are seeing specular reflection.


    If you have the process cycle time for another step, you can try to reduce the reflections with something like this. That is what the professionals use when making high accuracy scans on reflective surfaces.


    If you don't mind using something a little less professional, this stuff works just as well. It smells good too :winking_face:

    If you go to the digital input and then press F4 for "detail" you will see this screen:



    From this screen, just highlight the polarity setting, then use F4/F5 to toggle between normal and inverse.


    I don't believe it requires a power cycle, but if it doesn't immediately work, just cycle power.

    I'm not sure I'd go that far. I've had too many situations where I needed T2 in order to debug a system.


    That said, T2 scares me, and the situations where I've needed it are a fairly small % of the total. Striking the balance is a thorny issue. I can't really disagree with the majority of end users who buy controllers with the T2 option eliminated.


    I will say, the great majority of the hazardous incidents I've seen with T2 arose from people forgetting they were in T2 (usually jogging and touching-up points), and hitting "run" while expecting T1 speed. That's why I really like what KUKA did with T2 in KSS 8: Switching to T2 automatically reduces the override to 10%, creates a message that has to be manually acknowledged, and (most importantly) blocks jogging -- T2 can only perform program playback. This handily eliminates 90% of the risk I've seen in T2 over the years.

    I don't think that many cells need it, but I'll be damned if I ever have to dry run a cell with a 45m RTU without T2.


    That being said, I would prefer to have to use my T2 jumper instead of a key switch. Unfortunately, the connector for the key-switch can be a bear to get to when mounted in a remote box, so sometimes I need to install the switch.


    T2 freaks me out and MUST be respected. Modern Fanuc robots will automatically drop the override to 3% when switching into T2 mode, or whenever the dead-man is released. This may not be quite as good as having to acknowledge something with an explicit key press, but it's almost as good when SHFT_OV_ENB is set to false.


    I hate the idea of option number 2, it would force me to lock myself into a cell instead of operating with the gates open.

Advertising from our partners