Welcome to EtherNet/IP Industrial Protocol Support

[BlueCheese]

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

[dwisti]

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.

[BlueCheese]

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

[BlueCheese]

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

[tca2]

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?

[BlueCheese]

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

[dwisti]

I can't help but to respond to this comment:

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.

ODVA stands for "Open" DeviceNet Vendors Association.  But what is so "open" about having to pay for the spec?

[BlueCheese]

dwisti wrote:

ODVA stands for "Open" DeviceNet Vensors Association.  But what is so "open" about having to pay for the spec?

Ha, I understand your grief... of course licensing of the spec if up to the ODVA, not NI...

However, I am familiar with other technical standards and it is pretty clear why they usually have some sort of fee and license agreement associated with them:

- Administration costs associated with the standard. Member companies within the committee put a lot of time/money within their own R&D to develop the standards, but typically there is other overhead associated with making the standard successful that requires some administrative overhead. Typically the fees for acquiring the standard documents pay for this overhead.

- License agreements are usually there to protect the companies who put their time/money into developing the standard. One such reason is to prevent people from trying to patent IP that is part of the standard.

Eric

[dwisti]

Sorry for the rant here...

Yes but Rockwell touts CIP as open.  Even  though they try to hide all the specs away from anyone just wanting to  write a simple driver.  CIP would be a great technology if it was truly  open.  But because its pseudo-open, its stuck in a Rockwell only group  never to see the light of the rest of the automation world.  Thanks to Modicon we at least have Modbus.  And Thanks to NI we have some Labview Ethernet I/P drivers that the community doesn't have to write on their own.

[tca2]

Eric,

Often times, the reason why particular modules "must' be used is because the customer was "sold" a certain product before he or she actually knew if the product what going to meet all of their requirements for it.  No one wants to be told (or to do the telling) later on that what they bought won't work for their application.  In this particular case the customer was "sold" on the Numatics with Ethernet IP interface components and it was only until much later in his project was he "sold" LabVIEW and cRIOs by the NI (as opposed to being sold PLCs and ladder logic by Allen Bradley rep).  This was very good for NI, you and me.  However unfortunately it is usually not until sometime after the NI products show up that customer realizes that either he does not have the time or the talent (or both) to actually do the LabVIEW development work and then looks for somebody like me (in the process of becoming an Alliance Member---used LabVIEW since 3.0---734X/735X motion dude---possibly guru level) to do the programming or in this case the complete control system design.  But as you can see it is already too late.  So in the process of putting together a quote for the project, I did my homework (or in this case I thought I did) and first see if NI /LabVIEW supports Ethernet/IP communication before submitting my proposal.  I read in the "Ethernet/IP Driver for Industial Communication" document the following line: "This allows communcation and data sharing with a very wide range of PLCs and Ethernet/IP devices in use today" and think to myself: Cool...NI once again has got my back...we're in.  Speed up the film to the present as all of the above started last October and that brings us to my first post on the subject.

Don't worry all is good thanks to your rapid response and support.  I called the customer, explained the situation and we are either going to drive the valves directly using some cRIO digital output modules or replace the Numatics Ethernet IP node with a Modbus TCP one.  I'm out some money if the customer decides to go the direct drive route, but that's just part of doing business.

By-the-way, my question regarding using the TCP/IP and UDP sub VIs was for the most part a rhetorial one. Thank you for the excellent answer.  I suspect David is similar to me: the amount of money we make is directly proportional and intrinically tied to how fast we can get a system programmed and up and running.  In other words...we eat what we kill.

I thought about changing the thread title but in many respects my reply still fits...Welcome to Ethernet/IP Industrial Protocol Support!

Regards,

Tom