Intermittent IMSTP over Ethernet connection

    We have three nearly identical Fanuc P100 robots each with a R30-iA controller connected to an Omron PLC. One was added after the original installation. We are getting communication errors on the newest robot, approximately 6 times daily. The Net Config for all three looks identical (other than the address mapping and IP address, of course)


    We have been having the SRVO-037 IMSTP input Group 1 alarm. (UOPs are mapped to Ethernet Rack 89)
    We are also seeing PRIO-230 Ethernet/IP adapter error 1 and PRIO-231 Ethernet/IP adapter Idle.


    We replaced the Ethernet cable from the robot to the hub in the main cabinet, still have same issue, we then changed from port 7 on the hub to port 8 same issues.


    There are three robots on this line all communicating over Ethernet to the one PLC and we are not seeing these issues on the others; this leads me to believe there is a problem with the Ethernet controller itself or with the configuration.


    Status to date:
    • Three robots in cell only robot 3 exhibits faults (this is the used Robot)
    • Faults 4-5 times a shift
    • Discussed issue with FANUC – they suggested Ethernet issues
    • Replaced cable – no impact
    • Upgraded cable Cat 6 helped for a bit then issue returned
    • Facility is climate controlled


    Rob talked to a TSE at Fanuc. Our conclusions and suggestions:


    The PRIO-230 errors point to a loss of Ethernet comms; problems with cable or hardware. They mean that the adapter is idle – not receiving comms from PLC. Somewhere we are losing connection.
    Re-map the IMSTP to an internal memory bit that we know will not change.
    Check EtherNet cable for extra length – never coil excess cable
    Ensure cable is not run alongside HV cables or near VFD.


    Fanuc was adamant that it is “an Ethernet problem”. Another idea is to connect with software such as WireShark and see what is going on with the network traffic, or a network analyser to check for noise, etc., but we have no-one in the area experienced with those.


    We are at a loss as to what else to try, other than try swapping the Ethernet card within a good controller to the suspect controller. So far we have not had an opportunity to do this.


    Any suggestions will be most welcome.

    Edited once, last by RoTaTech ().

    I have seen switches set up using DHCP cause this problem (usually a MUCH larger network of devices though, based on your description). We had a similar problem once. We would randomly drop connection, and anytime someone powered down a piece of equipment on the network, it would take out a few PLC and robot connections as well. We ended up setting static IP's on the switch (you need a managed switch). Each port was exclusive to a specific piece of hardware then. This completely eliminated the issue. The biggest drawback was that you HAD to make sure you plugged everything in to the appropriate port.

    Addendum to first post: UOPs are mapped to rack 89 Ethernet.
    Fabian - thanks for your suggestion. There is a heartbeat but it is of no use in this situation: the UOP IMSTP is getting dropped.
    Bagged - it is an industrial un-managed switch, with nothing on it but the PLC and three robots. All four devices have static IPs.


    If I can figure out how to insert an image here, I will post a screen-shot of the network configuration: I added img /img and tried to paste my clipboard image, but it is not showing . . .

    Edited once, last by RoTaTech ().

    The devices have static IP's, which I would expect, but if it is an un-managed switch, the switch is going to be DHCP. Again, with such few devices, I wouldn't expect this to be a problem, but it is a possibility.


    What are you using for Ethernet cable, per pdl's question? Is it shielded? Cat5 or Cat6? Cat6 is recommended.




    Quote from RoTaTech


    Addendum to first post: UOPs are mapped to rack 89 Ethernet.
    Fabian - thanks for your suggestion. There is a heartbeat but it is of no use in this situation: the UOP IMSTP is getting dropped.
    Bagged - it is an industrial un-managed switch, with nothing on it but the PLC and three robots. All four devices have static IPs.


    If I can figure out how to insert an image here, I will post a screen-shot of the network configuration: I added img /img and tried to paste my clipboard image, but it is not showing . . .

    Hi
    When you hit reply, at the left bottom, dont you see Attach


    With the heartbeat you can check in the network goes down, it's all in the PLC side
    The PLC can monitor if at the same time, another device loses connection, etc,etc. It won't solve the problem but at least yo might see wich end is wrong. Maybe your robot is fine

    Cat 5 ethernet cable is minimum, did you connect ethernet cable shield inside the controler? if no try with connecting shield
    Be sure the factory network is not on the same line than your Ethernet IP
    Second ethernet port on main board have best priority for communication, use this port if possible

    I have had the same problems with unmanaged switches in the past - systems where multiple PLCs were connected where the Ethernet/IP and TCP connections would drop. I replaced the two switches with one Dlink for home and it all worked perfectly. That's the first thing I would try.


    I would also consult the documentation for your PLC. Is it using a ETN21 card, or a built-in RJ45? What model of PLC do you have?


    The suggestion of using Wireshark is great - you simply have to plug your computer to that network and let Wireshark monitor your ethernet adapter. You'll see the list of connections and you can examine each packet sent from an IP to another - there you can see if the PLC, for example, is sending the command to end the connection.

    Edited once, last by vmec ().

    I've solved this with delaying IMSTP or HOLD signal a bit in BG logic. IMSTP must be OFF for 60 ms (or at least 5 cycles) before robot actually reads this signal.


    It worked for me on multiple projects.

    Regarding the Ethernet cable - yes, the customer has changed out the Cat-5 for Cat 6. None of the three robots have shielded cable. I am not on site, so am only relaying what he has told me.


    Yes, it was (and is) originally plugged in to the second port, same as the other two robots.


    The PLC is an Omron CJ2M-CPU31 using its CJ2M-EIP21 built-in port.

    I will advise him to swap the switch - that is well within his capacity.


    re. the suggestion about adding time delay to the PLC IMSTP output: It has nought but an Always On condition in the rung, so there is no delay to be added. Good idea thought - if I have any other projects with a controlled IMSTP I shall keep that in mind.


    I offer thanks for the ideas.

    Edited once, last by RoTaTech ().

    We use S/FTP cables and industrial unmanaged ethernet switch. Communication network is separated from company's and we have usually 4-5 devices connected.


    But still I have problems with IMSTP or HOLD signal.
    That's why I delay it on robot side ...

    Quote from dha


    We use S/FTP cables and industrial unmanaged ethernet switch. Communication network is separated from company's and we have usually 4-5 devices connected.


    But still I have problems with IMSTP or HOLD signal.
    That's why I delay it on robot side ...


    Curious on how you delay it on the Robot Side?

    I map UOP for HOLD signal to a flag.
    I'm checking actual HOLD DI signal from PLC in GB logic.
    If it goes off, I'm counting register value and every cycle I check if it is still OFF.
    If it is still off after 5 cycles, I set flag for UOP HOLD to OFF, else it is ON.

    Quote from dha


    I map UOP for HOLD signal to a flag.
    I'm checking actual HOLD DI signal from PLC in GB logic.
    If it goes off, I'm counting register value and every cycle I check if it is still OFF.
    If it is still off after 5 cycles, I set flag for UOP HOLD to OFF, else it is ON.


    Thanks,


    So you are using the robot to control to keep the HOLD and IMSTP signal high instead of the PLC. You added a buffer to ensure that the signal is loss.

    I'm going to make an assumption--namely, that you are communicating Ethernet/IP? I had exactly this problem a while back, and found that the problem was in the Omron configuration, I had the input connection set to Multicast (which is default). I changed it to point-to-point and the problem went away.

Advertising from our partners