March 21, 2019, 04:22:50 PM
Robotforum | Industrial Robots Community

 Intermittent IMSTP over Ethernet connection

Author Topic:  Intermittent IMSTP over Ethernet connection  (Read 1558 times)

0 Members and 1 Guest are viewing this topic.

October 10, 2018, 04:20:33 PM
Read 1558 times
Offline

RoTaTech


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.
« Last Edit: October 10, 2018, 07:41:05 PM by RoTaTech »

Today at 04:22:50 PM
Reply #1

Advertisement

Guest

October 10, 2018, 07:00:45 PM
Reply #1
Offline

Fabian Munoz

Administrator
Hi

Do yo have a heartbeat programmed on the robot ?

Something very simple in the background task

do heaartbeatout on
wait for heartbeatin on

the plc will control the timing
somar

October 10, 2018, 07:02:18 PM
Reply #2
Online

bagged2drag


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.   


October 10, 2018, 07:45:02 PM
Reply #3
Offline

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 . . .
« Last Edit: October 10, 2018, 07:53:47 PM by RoTaTech »

October 10, 2018, 08:43:26 PM
Reply #4
Offline

pdl


Are you using a shielded Ethernet cable?

October 10, 2018, 10:40:52 PM
Reply #5
Online

bagged2drag


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.

 



October 11, 2018, 12:04:14 AM
Reply #6
Offline

Fabian Munoz

Administrator
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

Today at 04:22:50 PM
Reply #7

Advertisement

Guest

October 11, 2018, 09:00:46 AM
Reply #7
Offline

pyrioun


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

October 11, 2018, 09:19:03 PM
Reply #8
Offline

vmec


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.
« Last Edit: October 11, 2018, 09:22:05 PM by vmec »

October 14, 2018, 02:33:39 PM
Reply #9
Offline

RobotRon


I have seen this a few times. Typically cable or switch always cured.

October 15, 2018, 12:11:12 PM
Reply #10
Offline

dha


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.

October 15, 2018, 02:11:39 PM
Reply #11
Offline

RoTaTech


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.
« Last Edit: October 15, 2018, 04:34:29 PM by RoTaTech »

October 15, 2018, 02:22:57 PM
Reply #12
Offline

RoTaTech



October 15, 2018, 04:11:25 PM
Reply #13
Offline

pdl


You still haven't let us know if it is a shielded cable...

Today at 04:22:50 PM
Reply #14

Advertisement

Guest

October 15, 2018, 04:19:52 PM
Reply #14
Offline

RoTaTech


re: shielded cable

None of the three robots have shielded Ethernet cable.
« Last Edit: October 15, 2018, 04:35:11 PM by RoTaTech »

October 15, 2018, 04:38:29 PM
Reply #15
Offline

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 ...

October 15, 2018, 04:44:29 PM
Reply #16
Offline

RobotWizard0216



Curious on how you delay it on the Robot Side?

October 15, 2018, 04:49:51 PM
Reply #17
Offline

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.

October 15, 2018, 05:27:04 PM
Reply #18
Offline

RobotWizard0216



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.

October 17, 2018, 05:19:25 PM
Reply #19
Offline

smurrill73


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.

October 20, 2018, 12:18:42 PM
Reply #20
Offline

RoTaTech



Smurrill - Thanks for the tip. I am trying it right now, and I do not see within the Omron where to change that. I know exactly where I would within an A-B, but not Omron ...
« Last Edit: October 20, 2018, 12:47:36 PM by RoTaTech »

Today at 04:22:50 PM
Reply #21

Advertisement

Guest

October 23, 2018, 05:30:07 PM
Reply #21
Offline

smurrill73


It's been a little while since I used Network Configurator, I did my last couple of configurations from Sysmac Studio.

In the last image you attached, are you able to change the multi-cast selection to point-to-point?  That looks like the place to make the change.

October 23, 2018, 06:25:29 PM
Reply #22
Offline

Robo_Eng_13


This is not exactly the issue we had, but we did find out that the robots are basically set up to look at every packet of data on the network even if it is not addressed to that robot. This causes ours to become completely non-responsive, and we ended up having to change an ethernet filtering system variable so that it would only look at traffic addressed to it. I am not sure why this was not the default. This may work in your situation, but not sure.

$ETH_FLTR[4] from 0 to 44818

Cycle power for change to take effect.

November 01, 2018, 07:49:02 PM
Reply #23
Offline

smurrill73


When I was troubleshooting the IMSTP issue I had, Fanuc support had me change that variable as you described.  It had no effect, but it probably is a good idea to change it, especially if your robot will live on a plant IT network.


Share via facebook Share via linkedin Share via pinterest Share via reddit Share via twitter

xx
Ethernet xml connection

Started by ss.sun on KUKA Robot Forum

7 Replies
2566 Views
Last post October 25, 2016, 12:48:32 PM
by ss.sun
xx
OTC Ethernet Connection?

Started by Robotics650 on other Robots

0 Replies
106 Views
Last post March 06, 2019, 10:29:59 PM
by Robotics650
question
Ethernet/IP I/O Connection

Started by Pepe on Fanuc Robot Forum

1 Replies
2989 Views
Last post January 09, 2014, 03:08:25 AM
by Sergei Troizky
xx
Ethernet TCP connection

Started by Vlad222 on Yaskawa Motoman Robot Forum

4 Replies
2316 Views
Last post November 08, 2016, 11:08:05 PM
by Bulo