Welcome to EtherNet/IP Driver for Communication to Allen Bradley ControlLogix PLCs

[BlueCheese]

cruz,

You may need to give more details about what you are doing between the good case and the error case. Are you simply stopping and restarting it? What does you code look like?

The PLC error you are seeing seems like it would likely be becase the assemblies it is referencing do not exist. This would be expected behavior if you stop the VI (which removes the assemblies). If you start the VI up again the PLC should immediately reconnect and clear the error. Do any of the VIs return errors when it starts up a second time?

From the details given, I don't know if I can spot what the problem would be...

Eric

[cruz]

Hi Eric,

 I am simply stopping and restarting it and any VI return errors.

The PLC don't reconnect and clear the erro!!! I need to run first the VI, if I put to run first the PLC I have the same error.

Cam I clear the error?

[BlueCheese]

cruz,

So you only see errors on the PLC side? When you restart the LabVIEW code it starts up multiple times without errors, correct?

It sounds like you may have some configuration issue on the ControlLogix side. You might want to examine all your PLC's settings and see if there is some setting to control how often reconnection attempts happen. On my ControlLogix it attempts reconnecting every few seconds and so it will reconnect immediately whenever the LabVIEW code is restarted. This is the behavior I expect.

If you still cannot determine why the PLC is not trying to reconnect you may need to call Rockwell's support and see if they have any ideas.

Hope this helps,

Eric 

[ftsiiii]

I just got my got my updates in the mail for Labview 2009 when will these drivers be able to run under version 9

[BlueCheese]

ftsiiii,

It will work with the current version if you manually copy all the required pieces over to the new 2009 directory. I'll try to get a new installer up soon that supports and installs into 2009 seamlessly.

Eric 

[dtraxler]

I am having some troubles when using the assemblies also. I downloaded the Demo EIP project and set up the PLC (Control Logix L61) as shown in the image, in the zip file. When I first ran the VI, it connected to the PLC, however on the PLC side (RSLogix5k) I saw the timeout errors mentioned by someone else here. Then, it stopped working all together with the error: Code 16#0005 Connection Request Error: Bad Class. Nothing that have tried will fix it. What next?

On the other hand, I have successfully read data from the same PLC using the messaging VI's. That was easy, except I occasionally see timeout errors there too which is what started me on the path I described above. 

The Ethernet/IP library is pretty neat, I already have several places where it fits nicely. And, this is light years ahead of using OPC.

[BlueCheese]

dtraxler,

I'm glad to hear you are finding uses for this library. Please keep the feedback coming!

As for the issues you are seeing, I have a few suggestions. Some other customers have seen timeouts on the messaging VIs occasionally that I believe were tracked down to packet loss on the network caused by speed/duplex mismatches between the PLC and the switch it was connected to. The PLC takes a long time to retransmit lost TCP packets, longer than the 1 second default timeout of the messaging VIs. Try checking that the speed/duplex of the ControlLogix matches what you expect and also matches what your switch reports.

As for timeouts when setup as an adapter, I have a few possibilities. It is important to note that the communication from the adapter (LabVIEW-side) to the PLC is usually sent via multicast UDP packets. You may want to check if you are using some sort of managed switch or routers in between that may not be properly dealing with the multicast traffic. The traffic sent from the PLC to the adapter is usually unicast, so it will likely come through just fine. What is possibly happening is that when the PLC connects it sends a few updates of its output assemblies and then never sees the multicast data coming from the input assemblies on the adapter because they are dropped by the network hardware. After a few seconds it assumes the connection is failed and stops. You may want to try putting the PLC and LabVIEW system on the same simple non-managed switch and see if that works.

Lastly, what hardware are you running LabVIEW on? Is it just a Windows system? If it is running LabVIEW RT it is important to note that the adapter communication will likely not work properly on PharLap-based targets (PXI, CVS, ...) unless you are running LabVIEW 2009 or higher. This is because prior to this version the OS did not support multicast traffic properly. If you are using a vxworks-based target like a CompactRIO or Smart Camera, it will work with any version of LabVIEW we install to.

Let me know if this helps,
Eric 

[dtraxler]

Thanks for the quick reply.

What you described below is very close to what I saw. The VI could update the data in the PLC, and read back the updated data (through a rung in the PLC) a few times, then it stopped working.

I had noticed the posting about the network getting into the way, so I asked our IT guys about what's between the PLC and my laptop (Windows XP, LV 8.5) . Turns out there are a couple of switches including a layer 3 switch along the path and, everything except the PLC's Ethernet card is gigabit. So there are two reasons it may be having trouble. I did try changing the duplex setting on the PLC but it made no difference.

I captured some of the traffic using Wireshark and have attached that as CIP.zip  The PLC is x.x.x.21 and the laptop is x.x.x.104. Maybe this will help.

David

[BlueCheese]

Hi David,

Your attached capture was pretty interesting and may have yielded a clue. It appears that the Forward Open from the PLC to the LabVIEW system never succeeds in your trace. I was expecting to see this succeed and see UDP multicast being sent from the PC and then being dropped by the network.

However, I noticed on your trace that there were a bunch of Multiple Service requests being sent from your PC to the PLC. Since we don't currently have any Multiple Service Request functionality exposed in our LabVIEW interface, I am assuming that you are running another piece of software on the same system using EtherNet/IP (perhaps RSLogix?). I went and checked out a system with RSLogix5000 open and connected to a PLC and noticed that the RSLinx.exe process was listening on TCP socket 44818, which is one of the ports the EtherNet/IP protocol uses for accepting connections from remote systems. What I imagine is happening is that your PLC is instead talking to Rockwell's driver rather than our software and of course their driver doesn't know about the assemblies that you have created in LabVIEW. You can verify this is the case by doing a "netstat -a -b" from the console of that system. If this is the case, you will likely have to close whichever Rockwell software is open (or run it from a different PC). Unfortunately there is no way that two applications can typically listen on the same TCP port without conflicting with each other. This is a downside of protocols which must run on a known fixed-port.

Eric 

[dtraxler]

You found it.

I am (was) running RSLogix5000, which requires RSLinx, which did have port 44818 in use on my laptop. Now I am running Labview on my laptop along with the demo application. When I set a value in the array of DINT's sent to the PLC, I see that same value in the data read from the PLC. (Again from that rung I put in there...)

Is there a way around this? It works, but would be difficult to debug...