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

[BlueCheese]

AJ,

1) Before this add-on, OPC was the only way to accomplish this communication. This software allows the cRIO (or other LabVIEW-based system) to talk directly to the PLC without any OPC server.

2) This should be no problem... there are some limitations inherent in the protocol that limit the total size of a single request, so you might run into limits accessing the array as a single request (I'm don't know off-hand the exact limit, and of course it will vary based on the type of integers you are accessing (SINT, INT, DINT). However, if it is too large you can split your request into two and have them in parallel on your block diagram and they should get serviced in parallel.

3) In general, the messaging requests have a fixed cost of time to be serviced, regardless of size. Usually this is anywhere from 7-12ms depending on platform and settings. So it seems that even if you do both the read and write sequentially you'd be well under your 500ms goal.

Finally, the latest versions of this add-on have an additional ability to allow you to use a LabVIEW system as remote I/O in a ControlLogix system. You can then add in blocks of registers as an EtherNet/IP module into RSLogix5000 and have it use I/O data exchange to update input/output assemblies at intervals as low as 1ms. This approach is quite different from the explicit messaging since the configuration needs to be configured ahead of time in ControlLogix, but might make more sense if the LabVIEW system is serving as a slave to a larger PLC system.

Hope this helps, and please let us know about any feedback you have!

Thanks, 

Eric 

Message Edited by BlueCheese on 05-15-2009 11:16 AM

[AJJ]

Perfect -- thanks for the quick response!

Are there any licenses costs associated with this driver or is it a free add-in?

Thanks,

AJ

[BlueCheese]

AJ,

Currently as it is distributed as an NI Labs project it is distributed for free with no other requirements but a licensed copy of LabVIEW. However, it is *possible* in the future that it may become part of some other toolkit or module in future versions of LabVIEW.

Also, I edited my previous post after you responded with some additional info about interacting with ControlLogix, so check it out.

Eric 

[AJJ]

Thanks very much.  Our system needs to process 50 kHz data so I think that we'll need the CompactRIO to be a bit "smarter" than simple remote I/O, but it's good to know that option is available.

Thanks,

AJ

[BlueCheese]

AJ,

Its not just simply giving access to the I/O on the cRIO. Its just in called I/O in Rockwell's terminology. You create Input and Output assemblies on the LabVIEW side and then read/write to those blocks of memory in your LabVIEW code and the PLC can read/write to them on its side using ladder logic. The data transfer then happens asynchronously in the background as opposed to the explicit on-demand exchange if you use the messaging VIs.

Eric 

[mjo]

I Have a 1456-CVS that i would like to integrate with a ControlLogix 1756-L64. I have added the generic ethernet module as per the help file, but  I get an error in the Control Logix side of things that states (Code 16#0315) Connection Request error:Invalid segment type. ? can you run me through this set up again, (perhaps real slow for the simpler of us out here in LabVIEW world)

also do you have any example code of how to use the i/o assembly vi's. Help files are good, but examples are better. and results are the best 😉

Cheers

Martin

[BlueCheese]

Hi Martin,

I provided an adapter example/demo in the following post that should give you a good idea of how it looks on the LabVIEW side and the RSLogix5000 side:

http://forums.ni.com/ni/board/message?board.id=nilabs&message.id=279#M279

Unfortunately the bad news is that the CVS will not currently support the Class 1 Adapter communication as of the current version of LabVIEW RT (8.6.1) because multicast UDP traffic is not yet fully supported in LabVIEW Real-Time on PharLap-based systems (PXI, CVS, ...). The PLC decides if it wants the I/O device to use multcast and as far as I know the ControlLogix will always request multicast. On some newer PXI controllers there are some workarounds with additional drivers that can enable it to work, but not for the CVS's network interface. An future version of LabVIEW will likely add full multicast support to all targets and then Class 1 Adapter communication should work on all LabVIEW RT targets.

In the meantime, the explicit messaging VIs for reading and writing to Lgix tags does work properly without multicast support so you may be able to use that to get communication. You could create a input and output arrays of data on the PLC and then read/write them in a timed-loop on the LabVIEW side.

Hope this helps,

Eric 

[BlueCheese]

Hi all,

I wanted to take some time to solicit some feedback regarding additional features that you feel might be lacking or could be improved. We've been slowly adding to the feature set to add some requested capabilities (Class 1 Adapter, SLC 500 messaging) but I wanted to see if anyone had any more features they need for their projects.

A few items I think may be useful (but would like feedback on) are:

• Generic CIP Read/Write Attribute support
• Allow being a target of explicit messaging

Would these features enable more use cases? (if so, please describe...). What other ideas do you have?

Eric 

[JF3M]

I re-enforce the vote for Generic CIP Read/Write Attribute support as I believe that would help me communicate from LabView directly to my Ethernet/IP servo drive without having a PLC.  It may possibly help Labview talk to other EIP enabled devices in case they aren't setup for being looked at as I/O.

I am thinking that allowing the driver to be a target of an explicit message wouldn't help me because I don't think my drive (and probably many/most devices) can't originate a message to send to LabView.  My line of thinking is that LabView would constantly poll the drive and push and pull info to and from it as it needed (speed setpoints, speed feedback, and some others in my case).

I'll throw in a vote for string arrays, even though I'm not using them, because it appears from first look at the driver that it supports all data types, but a person would come to find out there is one that isn't supported (directly that is, but there are workarounds).

Hopefully performance won't take any noticeable hit with this or any future upgrades.

Thanks.

[Hanschke]

I've not been success connecting labview as remote I/O on a Controllogix PLC.   I configured a generic ethernet card in the PLC and loaded the Demo VI example on a laptop as per earlier posts in the forum.

When I run the Demo VI on my laptop, RSLinx immediately sees a NI labview Device in RSWho but shows it with a yellow question mark and as an unrecognized device.  The generic ethernet card continually attempts to connect and shows a module fault of 16#0204.  When I stop the Demo VI then the NI LabView Device in RSWho gets a red X through it.  It appears the Controllogix PLC sees the Demo VI but is unable to connect to it.

As an aside I was successful in reading and writing data using the Ethernet/IP messaging VI's.

Ed