RSLinx Loses Connection when OPC Server Enable

One of our machines is acting up and we cannot figure out where the issue lies.

Our server running RSLinx has a hundred or so PLC's connected by Ethernet driver. One of our machines appears to be functional from everything we can tell.

Configure drivers and let RSLinx find the PLC. Configure the topic and link to the PLC. Set up OPC Test Client and add data points everything is ok. Enable the topic on our OPC Client and we stay connected about 30 seconds then get a red X in RSLinx. If I disable in the OPC client the PLC will come back.

The other thing is if I manually delete all data blocks within the database and recreate them, the controller will stay online. If we reboot our server then the controller will get a red X through it.

Anyone have any ideas? We've been racking our brains with this. Luckily this is just a secondary machine but we would like to switch to it.

Have you test that your comm is solid between opc server and your plc ??

If you wanted to really dig deep into it, you can run a WireShark packet capture, filter it to the IP Address of your PLC, then look at the requests and responses. You may find long delays or missing responses.

I have no good reason to say this,
but I wonder if you are sharing that PLC Ethernet address with something else

widelto said:

Have you test that your comm is solid between opc server and your plc ??

Click to expand...

I believe? it is. From our server to the PLC we have <1ms response time when I ping. Unless you're asking something else.

Archie said:

If you wanted to really dig deep into it, you can run a WireShark packet capture, filter it to the IP Address of your PLC, then look at the requests and responses. You may find long delays or missing responses.

Click to expand...

Will try.

Gil47 said:

I have no good reason to say this,
but I wonder if you are sharing that PLC Ethernet address with something else

Click to expand...

I don't think so but we also have about 130 IP addresses talking to the server. I will try a different one I know we aren't using. This is a machine we've had installed for 6 or 7 years that has gone offline. The only changes we've made have been updating the gateway of all controllers from a .1 to .2.

Archie said:

If you wanted to really dig deep into it, you can run a WireShark packet capture, filter it to the IP Address of your PLC, then look at the requests and responses. You may find long delays or missing responses.

Click to expand...

I've run wireshark on my controller and while interesting, I have no clue what I'm looking at.

In the filter box at the top enter ip.addr==192.168.0.1 (substituting for the IP address of the PLC giving problems)

Now look through the packets and you will be able to see from the source and destination columns, request packets from the PC and response packets. Look for requests with no corresponding response or a long delay of maybe several seconds or more. You may also see some retransmits.

I attached a snippet of the wireshark output.

The .32 is the machine we're having trouble with
The .30 is the machine that is working fine (exact same machine, setup, program, everything)

When I look at the output in the info column to me I would think neither is working. At about the 10second mark is where I enable .32 on the OPC server. .30 was enabled the whole time.

We have wonderware HMI connected to both of these machines, yesterday we were tinkering around and actually had both machines online with OPC server enabled. The HMI had been disconnected so when we plugged the HMI back in it kicked the .32 machine out of RSLinx. Unplugged the HMI and it came back. Same thing happened if we hopped on a programming laptop and went online with the code to make edits, it would kick it off RSLinx on the server.

This is all baffling since we have the exact same machine running fine. Maybe a bad switch?

I'm not really able to tell what is completely happening without the Wireshark file. The Wireshark file allow you to view it in Wireshark and it formats the packets to be able see what belongs where.

Hmm looks like the capture files are too large to upload to here. I will need to figure out something else.

willsee said:

Hmm looks like the capture files are too large to upload to here. I will need to figure out something else.

Click to expand...

Have you tried zipping it?

Stu....

Yeah. 3MB for 20 seconds of capture time when zipped.

So I believe we found our issue.

Where are troubled machine is located we have two additional machines. We connect over fiber to these machines. Saturday morning I received a phone call that we were no longer communicating with any of the machines. Started digging into it, swapped out a fiber media converter, and lo and behold our troubled machine came back online.

It's been up and running for a couple of days down with no issues while testing it. So looks like that converter was flaking out then finally crapped out.