Welcome to EtherNet/IP Industrial Protocol Support

[aliasThree]

I found the previous forum for this toolkit to be closed to new posts, so NI tech support helped me find this one.  I have a particular problem using the toolkit's tag read VI that I'm hoping I can get some insight into here, though I did find brief mention of it in the earlier forum devoted to support of this toolkit.

This is the text I posted to the Industrial Communications area before I was directed here (thank-you, Sara Lewandroski | Applications Engineer | National Instruments):

I get an error when trying to read a tag name:

R23.Seg[71]

Seg is a boolean array of 128 elements.  I am trying to read bit 71 with this tag using the boolean instance of the tag read subVI.  The PLC address is producing error-free results reading other tags, and I am not wiring the "# of elements" input.

This is the error:

-251723760

Ethernet/IP Industrial Protocol:  (Hex 0xF0FF0010) CIP Error--Extended status may be available.

Can anyone explain to me how these subVIs work?  Could I try using the Dint instance of the tag read subVI (with tag "R23.Seg"), expecting to find this array's 128 bits packed into 4 Dints?  Could this error be caused by the driver choking on the size of the boolean array?  I'm in the process of trying to get the PLC code to verify the tag name.  I haven't found much about this particular error except a mention in another thread; but even there the concensus was split between bad address and bad tag name.  NI tech support isn't very familiar with this toolkit, and I haven't been able to contact the toolkit's author(s).

Any help would be appreciated.

As soon as the PLC guy gets into the office I'll be able to determine without a doubt the validity of the tag name.  But if that goes alright, and the tag name is good, what else could cause this error--given that the program this tag read instance is running in contains many other instances of this VI using the same PLC address string and throwing no error?  It gets me wondering if the toolkit's underlying code might be doing some kind of data type conversions that might balk at the 128-bit boolean array (there's got to be some kind of integer translation going on to even have a "boolean array" at all, right?).  Or should I be reading DINTs instead of BOOLs?  Any insight would be appreciated.

[aliasThree]

We've verified the validity of the tag name.  Please help with understanding the nature of the error.  Unfortunately, I do not have the PLC to work directly with as it is in use on a factory floor in another state; but an advanced operator on site does have access to a "debug" screen of the application where I've put a variety of indicators to help troubleshoot this (and other) issue(s).  So I can quickly send new code to a person on site and have them try possible solutions--I just need a little help in understanding what I'm dealing with.  Does it make sense to call out "R23.Seg", reading 4 elements with a DINT instance of the tag read VI, and parsing the result bit-wise to get bit 71 (element 2, bit 8)?  Will the underlying memory structures and driver code support such gymnastics?  I don't want to try the on site person's patience with pure guesswork.

Please throw me a bone, BlueCheese...

[BlueCheese]

aliasThree wrote:

I get an error when trying to read a tag name:

R23.Seg[71]

Seg is a boolean array of 128 elements.  I am trying to read bit 71 with this tag using the boolean instance of the tag read subVI.  The PLC address is producing error-free results reading other tags, and I am not wiring the "# of elements" input.

This is the error:

-251723760

Ethernet/IP Industrial Protocol:  (Hex 0xF0FF0010) CIP Error--Extended status may be available.

Can anyone explain to me how these subVIs work?  Could I try using the Dint instance of the tag read subVI (with tag "R23.Seg"), expecting to find this array's 128 bits packed into 4 Dints?  Could this error be caused by the driver choking on the size of the boolean array?  I'm in the process of trying to get the PLC code to verify the tag name.  I haven't found much about this particular error except a mention in another thread; but even there the concensus was split between bad address and bad tag name.  NI tech support isn't very familiar with this toolkit, and I haven't been able to contact the toolkit's author(s).

BOOL Arrays on ControlLogix are very funny. In some ways they behave like DINTs and others as BOOLs. The first thing to understand is that all accesses to arrays of BOOLs are aligned on 32-bit boundaries. If you do a read of a single element of an array of 32 BOOLs you will currently get 32 BOOLs back (the current API does not try to hide this). On a write you would need to write 32 BOOLs at a time.

While the API appears to translate the "Number Of Elements" into a count of 32-bit-sized elements, it appears that the same is not done on the indexer as well. This means that the indexer when reading arrays is going to refer to the index of 32-bit-sized BIT_ARRAY elements. Thus, to read "R23.Seg[71]" you would actually be reading starting at the 64th BOOL (since it must be aligned on a 32-bit boundary) and since the indexer is based on that, you would address it as R23.Seg[2] and then access the 7th BOOL in that array to get to the particular bit you want.

Hope this helps,

Eric

[aliasThree]

Thank-you very much, Eric!  This is exactly the kind of info I was hoping for.  Just to make sure I have this straight:

1. I leave the "number of elements" input to the tag read VI (BOOL instance) unwired (it should default to "1");

2. Change the tag name itself to "R23.Seg[2]" to access the third set of 32 bits in the 128-bit BOOL array;

3. The tag read VI's output will be a 32-bit BOOL array (bits 64 - 95, inclusive, of the PLC's 128-bit BOOL array);

4. Index the tag read VI's output with a "7", since the 8th bit equates to bit "71" of the PLC's 128-bit BOOL array).

I can imagine how using an index of "71" where a "2" is appropriate, in the tag name, could have invalidated the tag name itself and and caused the "-251723760" error (which, as far as I've been able to determine, indicates something improper about the formulation of the tag name).

I'll implement this new understanding, and expect a resolution to the problem.

Oh, as an aside, I looked around and found and downloaded the latest version of the toolkit and checked the help file, finding that the "Open" and "Close" Session VIs have disappeared (compared to the version I'm using), and "Get" and "Set" Attribute VIs have been added.  Are these attributes to be used in the same way you'd use variant attributes??

Thanks for your help, Eric!

[BlueCheese]

aliasThree wrote:

I'll implement this new understanding, and expect a resolution to the problem.

Oh, as an aside, I looked around and found and downloaded the latest version of the toolkit and checked the help file, finding that the "Open" and "Close" Session VIs have disappeared (compared to the version I'm using), and "Get" and "Set" Attribute VIs have been added.  Are these attributes to be used in the same way you'd use variant attributes??

The Open and Close VIs should be under the Advanced palette of the EtherNet/IP palette. I thought they were always in that location, but maybe they moved... Are you still not able to find them?

The Get/Set Attribute Single VIs are a type of generic CIP message that correspond to reading or writing a single attribute of an object. This is more often used when talking to devices that support EtherNet/IP that are not PLCs. With this type of addressing you need to know the object type, instance, and attribute you wish to read or write.

Eric

[aliasThree]

I just looked at the help file again, and there they are, in the Advanced palette, just like you said!  Sorry about the confusion--I can't even guess at why I missed it.

I am still waiting to hear whether the changes your explanation prompted me to make worked to eliminate the error.  I'm not a PLC guy, so I'm still wondering if it would have worked to specify the tag name only as far as "[", wire a "4" to "number of elements, and read out the four DINTs that comprise the 128-bit BOOL array.

Thanks, again, Eric.  I'll let you know how this turns out.

[Mark88]

Thanks for creating the Ethernet/IP tools.  They are very useful.  I do have one problem though, I recently upgraded to 2010 and the VI's do not load anymore.  What files do I need to copy, and where to in the 2010 version?

Thanks,

Mark

[dwisti]

Looks like Labview 2010 does not automatically type cast the session control to a U64.

[BlueCheese]

Hi Mark,

Hopefully we can have a new installer up soon that has 2010 support. In the meantime, you can re-run the existing installer and manually select to install support to a LV version that you do not actually have installed. This will place all the support files needed into that non-existing LV directory. You can then move these form that folder into your LV2010 folder and it should work. This makes it simple to ensure you have all the files needed.

Dwisti,

The VI is broken because you probably don't have all the refnum support files installed. I tried it on 2010 and it was unbroken. However, I did notice that the Open Session VI was returning an exception on 2010 due to a missing terminal in the DLL call. I'll make sure this gets into the next version.

Eric

[dwisti]

Eric,

You were correct.  I was missing \resource\objmgr\ethernetip.*.  I re-ran the installer and forced a Labview 8.2 install to find the missing files.  Thanks!

David