NI Labs Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Welcome to EtherNet/IP Industrial Protocol Support

Welcome to the NI Labs EtherNet/IP Industrial Protocol Support project. This thread is intended to foster discussion about the project, so please post your questions, comments, suggestions and bug reports and I'll be happy to respond.

This library allows direct communication between NI systems running LabVIEW and various PLCs and other devices using the EtherNet/IP industrial communications protocol. You can find out more details about the types of communications supported from this page here: http://decibel.ni.com/content/docs/DOC-4065

One of the goals of this release on NI Labs is to get a better idea of what features are in most demand to add support for. We'd love to get feedback regarding need for additional data types, additional PLC addressing support, etc.

Note: Previously this discussion thread was on another discussion forum that is no longer available for new posts. You can access all the old messages here: http://forums.ni.com/ni/board/message?board.id=nilabs&thread.id=167 .

Eric G

National Instruments

0 Kudos
Message 1 of 125
(99,219 Views)

This was by far my most pleasurable experience with an NI driver.  I can't say how easy it was for me to communicate to a Allen-Bradley 1747-L552 5/05 CPU in Windows XP and my RT ETS box.  Job well done Eric! I just wish the Modbus TCP stuff was like this driver.

Here's my feature suggestion.  I have use for the client side of I/O data (i.e. Labview taking the role of the PLC).  Is this called I/O client communication (Class 1)?  I'm not up on all the CIP  terminology.

0 Kudos
Message 2 of 125
(19,296 Views)

dwisti wrote:

Here's my feature suggestion.  I have use for the client side of I/O data (i.e. Labview taking the role of the PLC).  Is this called I/O client communication (Class 1)?  I'm not up on all the CIP  terminology.

Hi David,

We do currently support I/O communication, but in the "adapter" role rather than the "scanner." This means that we can produce and consume I/O data, but cannot initiate the connection. The scanner's role is traditionally done by the PLC and the modules serve as adapters.


We've had some requests for scanner capability, but this is potentially a big task and I'm not so sure there are a whole lot of good use cases. What this would allow would be using 3rd-party I/O modules directly from an NI controller rather than a PLC. However, without all the shared infrastructure between the module vendors and the PLC such as the module vendors having plugins into RSLogix that know about all the capabilities of the modules, such access would be rather primitive and basic. I don't think the experience of using one of those modules would compare at all to using a module with native LabVIEW support (from NI or a 3rd party).

Would you be able to share more details about your use case so we can have a better idea of what your needs might be?

Thanks,

Eric

0 Kudos
Message 3 of 125
(19,296 Views)

I just wanted to let everyone know that version 1.0.5 was just posted. This new release adds some highly requested features. We now have SLC500 read/write/masked write into Bit register files. Additionally, a Raw type was added for SLC500 so that customers can write to types that are not currently supported.

As always, please let me know if you have any more questions or feedback!

Eric

0 Kudos
Message 4 of 125
(19,288 Views)

Hi Eric,

I also know very little about Ethernet IP communications/protocols, but you asked David for additonal examples/details so I thought I would jump on in.  If you recall the Numatics G3 interface guestion from "goLV", this a good example of the need for a Class 1 "scanner" role LabVIEW interface.  My client also purchased a set of G3 valve manifolds for his process but according to the Numatics application engineer, the manifold only supports Class 1 "adapter" (IO Data) implicit communications.  However my client's control system is based on four cRIOs with four 9144s...no PLCs. Therefore I obviously could use a LabVIEW/LabVIEW RT Class 1 scanner role Ethernet IP interface.  It's kind of difficult to go back to the client and tell them that they will have to purchase a PLC so that LabVIEW can communicate with the Numatics G3. 

I have attached one page from the Numatics Ethernet IP manual to give you an idea what the Numatics "adapter" configuration requires from the PLC and therefore what I am assuming would be required by the LabVIEW scanner role.

My hunch is that you are going to receive more requests for a LabVIEW "scanner" mode interface to communicate to third party remote I/O devices as time goes on.  This will simply be driven by the success of the LabVIEW RT/cRIO combination in replacing legacy ladder logic/PLC control systems.  That is the PLCs are being replaced not the remote I/O devices.  I guess for now I need to inform my client that a direct LabVIEW interface doesn't exist for the Numatics G3.  Would this be correct?

I do want to sincerely thank you for getting this far with the interface,

Tom

P.S.  Would it be possible to use the low level TCP/UDP sub VIs provided with LabVIEW to write a simple Ethernet IP interface to the G3?

0 Kudos
Message 5 of 125
(19,296 Views)

tca2 wrote:

Hi Eric,

I also know very little about Ethernet IP communications/protocols, but you asked David for additonal examples/details so I thought I would jump on in.  If you recall the Numatics G3 interface guestion from "goLV", this a good example of the need for a Class 1 "scanner" role LabVIEW interface.  My client also purchased a set of G3 valve manifolds for his process but according to the Numatics application engineer, the manifold only supports Class 1 "adapter" (IO Data) implicit communications.  However my client's control system is based on four cRIOs with four 9144s...no PLCs. Therefore I obviously could use a LabVIEW/LabVIEW RT Class 1 scanner role Ethernet IP interface.  It's kind of difficult to go back to the client and tell them that they will have to purchase a PLC so that LabVIEW can communicate with the Numatics G3. 

I have attached one page from the Numatics Ethernet IP manual to give you an idea what the Numatics "adapter" configuration requires from the PLC and therefore what I am assuming would be required by the LabVIEW scanner role.

My hunch is that you are going to receive more requests for a LabVIEW "scanner" mode interface to communicate to third party remote I/O devices as time goes on.  This will simply be driven by the success of the LabVIEW RT/cRIO combination in replacing legacy ladder logic/PLC control systems.  That is the PLCs are being replaced not the remote I/O devices.  I guess for now I need to inform my client that a direct LabVIEW interface doesn't exist for the Numatics G3.  Would this be correct?

Hi Tom,

You are correct that the current implementation does not support the "scanner" functionality and it appears that the Numatics G3 module does not support explicit messaging access to the assembly data. However, have you considered other ways of accessing the data on the Numatics G3? Some quick research appears to indicate that this module might support Modbus/TCP as well, which LabVIEW has drivers written for as well...

As for requests to add this scanner functionality, I appreciate your feedback. This is something we are still considering and weighing with other items. Out of curiosity, is there some reason these particular modules must be used? Is there not a suitable alternative that has interfaces more friendly to LabVIEW already?

tca2 wrote:

P.S.  Would it be possible to use the low level TCP/UDP sub VIs provided with LabVIEW to write a simple Ethernet IP interface to the G3?

Yes of course. EtherNet/IP is based on UDP and TCP and so you could conceivably write something yourself to talk to that module. Rockwell even has some documents that can give you a brief overview of how you can do it: http://www.rockwellautomation.com/enabled/pdf/ioclogix1_0.pdf . However, keep in mind that there are other specs you might need to understand it (some which require purchase from the ODVA). Also, keep in mind it is quite a big step from having some code that works with a single device in a single case and code that fully adheres to the whole specification and is fully tested with other implementations and compliance tests.

Eric