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

[BlueCheese]

Hi David,

So if I understand you correctly, you had a rung on the PLC that was essentially doing a loop-back of data? And everything is working now when RSLogix is closed?

Unfortunately, there is likely no easy way to run both unless you can figure out a way to disable the Rockwell driver from attaching to that port. It shouldn't need to listen on that port unless it is expecting to be the target of communication, which I don't think you would ever do. Generally RSLogix just communicates with the PLCs using explicit messaging, which would not require it to listen on that port.

You could possibly use VMware on the machine and have the two "systems" isolated that way.

A more complex way would be to add multiple IP addresses to your system (either with multiple NICs if you use DHCP, or just manually add multiple IPs if doing static IP addressing) and then somehow force the Rockwell software to bind only to a specific IP address instead of all of them (I have no idea if this is possible in their software). Then you can create the EtherNet/IP session in LabVIEW with a special qualifier added to the session name ("sessionName:LocalIP=192.168.1.1")  to indicate a single local IP address to bind to, where you would bind a different address from the one Rockwell is using. I'm guessing you won't want to go down this route...

Or you could just get a LabVIEW RT system and have that be the one talking to the PLC... 

Eric

[dtraxler]

Eric,

I have one more clue and a comment,

After my last posting I discovered two things. One is the remarks about the network getting in the way of Ethernet/IP are correct. I moved the PLC, and connected it to the switch where my laptop is connected, and everything works fine.

My second discovery was made by going through this procedure:

Reboot laptop, RSLinx starts automatically.

Start RSLogix5000.

Start Labview, open demo project.

Start demo VI, notice in RSLogix5000 that there are communication errors between the PLC and Labview. See that data is not updated on VI's front panel.

Shutdown RSLogix500.

Shutdown RSLinx.

Notice that VI is now communicating with PC as remote I/O, which is indicated by data now updated on VI's front panel. 

Wait... long enough where RSLinx has exited.

Re-start RSLinx

Re-start RSLogix5000

See that data is still updated on VI's front panel, also observe this in RSLogix5000 by monitoring the tags. The VI is working as advertised. No communications errors seen in RSLogix5000.

I think that when RSLinx exited, it relinquished port 44818 which gave the demo VI access to this TCP/IP port.

I also think that when I re-started RSLinx, it claimed another TCP/IP port aside from 44818, since 44818 was still in use.

The one variation I did not do, was shutting down the VI before re-starting RSLinx, to see if RSLinx would reclaim port 44818, since at that point the port is not in use.

All of that leads to a question which is, could the Ethernet/IP library use a similar technique to the one RSLinx seems to be using? That is, search for an open port when connecting to the PLC?

I have attached two screenshots taken from SysInternals TCP View. "Before.jpg" shows the TCP/IP connections in use after rebooting the laptop. "After.jpg" shows the TCP/IP connections after restarting RSLinx and RSLogix5000.

Thanks Again,

David

[BlueCheese]

David,

Unfortunately it doesn't quite work that way. Keep in mind that for the Adapter/Implicit communication, it is the PLC that makes the connection to LabVIEW, not the other way around. When we make outgoing connections from LabVIEW, we of course use any available port and this will not conflict with any other software. However, when the PLC connects to LabVIEW, the destination port it must connect to is fixed at 44818 due to how the protocol is defined. Thus, only a single application can listen for connections from the PLC.

The reason it seems to be working with both applications when you simply change the order that they get started comes back to a point I made earlier that I did not know why RSLinx needs to listen for remote connections. RSLogix5000 I believe only initiates explicit messages to the PLC when you use it; it is never the target of messages or other communication from the PLC. Thus, when it cannot grab the 44818 port it does not actually affect the functionality of RSLogix5000 (that I know of). You already observed similar behavior on the LabVIEW side as well. When RSLinx was bound to the 44818 port, the Adapter/Implicit communication to LabVIEW did not work but the Explcit Messaging initiated from LabVIEW to the PLC did work. It works for the same reason RSLogix5000 continues to work when LabVIEW is bound to that port.

The way this type of issue is handled in newer protocols is to use some mechanism to advertise a service by a known name that then can be resolved to an arbitrary port number dynamically. If you are curious you may want to check out some of the RFCs behind Zeroconf as an example. We use something as well with NI products called the NI Service Locator to let NI services run on arbitrary ports rather than fixed ones. However, the EtherNet/IP protocol follows most legacy protocols in that they reside on fixed, "well-known" ports, leading to the limitations with multiple applications like you are seeing.

Eric

[dtraxler]

Eric,

Yes, I overlooked the obvious and that is who is calling who.

In my case, it could be RSLinx is listening for connections because its the Gateway version and can be used for remote access to the PLC from another PC.

(PC -> PC running RS Gateway -> PLC)

Thanks,

David

[ABNewbie]

I'm trying to communicate with a Micrologix 1400.  I can get the Integer and the Floats to read, but I also need to read a Long Integer and Binary bit files.  Can I use the Ethernet/IP Get Attribute single.VI to get these values?  The Ethernet/IP Tag Read.VI seems to be only for compact logix systems or is there a way to use this with the ML 1400?

[BlueCheese]

Hi AB,

Unfortunately we only currently have the Integer and Float data types supported for the SLC500-type messages. We are looking to support a few more soon though.

I don't think you can use the Get Attribute Single because the PCCC object that we communicate with uses a special PCCC service code, not the Get/Set Attribute Single service codes. You could certainly check Rcokwell's support documents and see if the PCCC object might support that service code (and how the mapping works), but I am doubtful it will work.

In the meantime you could just replicate the data you need into the Integer and Float register files...

Eric

[WPTMan]

Thanks Eric,

I figured it out by using the integer bit values intead of the binary bit values and everything work great.  Thanks!

AB

[Drouilhet]

Can the Ethernet/IP driver be used to set up a new IO Server in DSC?  How would one do that?

[Charlie Silver]

Does anyone have experience measuring ethernet/ip cycle time between Fieldpoint 2220 and Logix5550 (or a similar setup)? 

I'm finding that a complete read/write sequence (using Tag Read and Tag Write) takes ~500 ms.  I'm testing this with a DINT tag.  Each individual read or write operation takes ~200-300 ms.  This seems awfully slow.  Has anyone else measured this?

I had been hoping that ethernet/ip would be quicker than RS232, but it seems too slow for my purposes.  Any suggestions would be appreciated.

Charlie

[BlueCheese]

Hi Charlie,

If you look back in the thread you'll see some benchmarks myself and others have posted. In general, I'd expect the 5-10ms range to be what it should take. To try to figure out what may be wrong I'd first suggest trying it from your Windows system and see if you see similar results. I have not seen delays this long on similar vxWorks targets of the same speed as the cFP 2220 so this may be something unique to your setup. Is the cFP doing anything else CPU intensive at the same time?

Also, you can use a network sniffer program like Wireshark to see the timing of the request and response on the wire. If this shows the delay to be entirely in the time between the request going out and the PLC responding, you may want to examine if there is something you can change on the PLC side to service the request faster. Also, I have seen issues in the past with Rockwell's Ethernet modules having incorrect speed/duplex settings and that causing lost/corrupted packets and retransmission delays.

Lastly, these messaging requests follow a request/response style and thus they can be overlapped and run in parallel to cut down on the latency of doing multiple requests. If you have multiple items or your read and writes are not dependent on each other you might me able to save time doing these in parallel.

Hope this helps,

Eric