EtherNet/IP Driver

[blawson]

I want to use EIP to communicate with an Ethernet/IP to DeviceNet bridge (no PLC) to get data from and push settings to some I/O devices using explicit messaging.  Does this add-on use unconnected or connected messaging for that? I think my data rate needs are high enough that I have to have connected messaging.

Posting here because http://forums.ni.com/ni/board/message?board.id=nilabs&thread.id=167 is now locked up!

-Barrett

[BlueCheese]

blawson wrote:

I want to use EIP to communicate with an Ethernet/IP to DeviceNet bridge (no PLC) to get data from and push settings to some I/O devices using explicit messaging.  Does this add-on use unconnected or connected messaging for that? I think my data rate needs are high enough that I have to have connected messaging.

Posting here because http://forums.ni.com/ni/board/message?board.id=nilabs&thread.id=167 is now locked up!

-Barrett

Hi Barrett,

That thread being locked caught me by surprise too. The admins put a message in the top-level forum but nobody usually sees it because the links point directly to single threads. All discussions will be moved to this new forum and I new message thread will be created shortly.

To answer your question, we support a variety of explicit messaging types as well as implicit I/O communications. I'd guess that the bridge you are using works using explicit messages. The messages themselves are sent over connected messaging (TCP on EtherNet) that remain active over multiple requests. Typical round-trip request and processing times for these messages (to say a ControlLogix PLC) usually are around 5ms. This delay can vary depending on host, device, and network.

Eric

[VTX1800]

Hello Eric,

This is Ted.  I have been working on other projects and just got back to this.

We exchanged a few emails back in December regarding addressing program tags with the Ethernet/IP driver.

If you remember, the final answer you gave was:

______________________________________

From my understanding, "program tags" are like local variables in a C program. They are restricted to be accessed only from the scope they are declared in, which in this case is a particular program. As far as I know there is no way to access these local variables via the EtherNet/IP interface of the ControlLogix. If you declare them as "controller tags" then they are like globals in C and can be accessed from other programs on the PLC and externally from the PLC, such as via EtherNet/IP.

If you want to access data in local variables from outside of their limited scope, perhaps their scope should not be declared as local to their program. If you are working around existing code, my best guess is that you would have to mirror that data somehow. I'd suggest adding a rung in your ladder logic to mirror whichever variables you need into a controller tag or a data assembly on your LabVIEW system. From a simple experiment I don't think RSLogix5000 lets you simply alias program tags into controller tags (and this would defeat the purpose of limiting their scope in the first place...).

As far as accessing UDTs, hopefully my links above will provide enough details on how to do this, providing you are accessing tags that are set to the right scope.

Eric

______________________________________

Long story short ... I persevered and found a way to address the program tags.

The Ethernet/IP driver is more capable than you imagined.

As it turned out there is a structure the PLC uses to address the program tags.

To address the program tags you simply have to point to the program name in the tag name with the following structure:

Program:<program name>.<tag name>

For a UDT tag in a program the structure is extended:

Program:<program name>.<UDT name>.<UDT element>

Evidently, the word "Program:" in the tag name tells the PLC that the tag is in a program and where the program is by the name that follows.

cheers,

Ted

[VTX1800]

Eric,

Have you extended the Ethernet/IP driver to other PLCs?

Siemens or Telemecanique?

regards,

Ted

[BlueCheese]

VTX1800 wrote:

Long story short ... I persevered and found a way to address the program tags.

The Ethernet/IP driver is more capable than you imagined.

As it turned out there is a structure the PLC uses to address the program tags.

To address the program tags you simply have to point to the program name in the tag name with the following structure:

Program:<program name>.<tag name>

For a UDT tag in a program the structure is extended:

Program:<program name>.<UDT name>.<UDT element>

Evidently, the word "Program:" in the tag name tells the PLC that the tag is in a program and where the program is by the name that follows.

cheers,

Ted

Hi Ted,

Thanks for the information. Those tags names go pretty much directly to the PLC with very little parsing on our end, so it is really up to the PLC in terms of how they decide to interpret them. I've never seen that program syntax documented anywhere by Rockwell or anyone else. Did you just try it or did you read it from some document someplace? We'll try to add that to the documentation for the next release.

Thanks again,
Eric

[BlueCheese]

VTX1800 wrote:

Eric,

Have you extended the Ethernet/IP driver to other PLCs?

Siemens or Telemecanique?

regards,

Ted

Ted,

I am not familiar with what types of communications those PLCs support. With the Read/Write Attribute Single commands you can read/write to just about any device that supports supports explicit messaging. If you have any link to a manual, that might help...

Eric

[VTX1800]

Eric,

To be honest I searched the Internet to find a document that described the Rockwell controller and program tag addressing structure.

Rockwell was not forthcoming with documentation.

I did find some insight in a document from SoftwareToolbox.com titled

"Using the TOP Server InTouch Tag Wizard with ControlLogix’s Tags"

THe document was found at the following URL:

http://docs.softwaretoolbox.com/Documents/TOPServer/Wonderware/Using%20InTouch%20Tag%20Import%20Wiza...

I gleaned some format structure from the text and tried it with the NI Labs objects to read and write to both the controller and program tags.

I also had program tags that used UDT data types and I figured out how to extend the formatting to include the UDT name and individual element tag name.

Hope this helps the user community.

Glad to contribute,

Ted

[RichardJennings]

What is the current license for the EtherNet/IP driver? Previously we were only allowed to use it for internal use only. We have a commercial product to deliver.

Thanks,

Richard

[BlueCheese]

Hi Richard,

I'm not sure if I can adequately answer this question... Currently this project is distributed with the standard NI Labs license agreement we get from the lawyers. I believe you are correct that there is some sort of text inside it that states somewhat to the effect of disallowing commercial distribution. I checked and some NI Labs projects are currently licensed under different terms, so it might be possible to have some changes implemented. I can say that I don't think the intention is to prevent customers from using NI Labs projects freely, but more for liability reasons.

I'll discuss this with some other people and see if we can figure out some options.

Eric

[nonecure]

I'm using 2 sub vi's that are running in parallel, that both have EthernetIP CIP Get and Set Attributes in them to talk to 2 different devices.  This works fine until i stop the application, then sometimes i get an error.  I think the Close Session.vi might be closing the port while the 2nd sub vi is completing.  If i remove the Close Session.vi's from both subs, then I don't get any errors and everything works fine.

Do I need to use the Close Session.vi?