PLC tag size validation.

309 views
Skip to first unread message

Daniil Dolmatov

unread,
Dec 30, 2020, 2:58:11 AM12/30/20
to libplctag

Hi, Kyle!
If we try to write a value into a tag outside of the tag data bounds we will receive PLCTAG_ERR_OUT_OF_BOUNDS error.
There is another case: we registered array with 10 elements on PLC device and then call plc_tag_create for lesser number of elements  (e.g. elem_count=5).  In this case sizes of  tag from PLC device and tag which we created are mismatched.
It seems that we need to compare "real" PLC tag size with our expected tag's size that we created through libplctag (for example, in case of miss-configuration of service that uses the library).
Is there any opportunity to retrieve size of a tag which registered on PLC device? Or is this approach wrong?
Best regards,
Daniil.

Kyle

unread,
Dec 30, 2020, 11:24:16 AM12/30/20
to libplctag
Hi Daniil,

Thanks for reaching out.

You can get the actual size of the  tag in the PLC in only two cases:
  1. List out all the tags in a Control/Compact Logix system using the approach in list_tags.c.  Then select your tag and create a tag handle to it with the correct size.
  2. Use an Omron PLC.   These return the entire tag regardless of what you set the elem_count to.  Internally the code forces elem_count to 1.
Unfortunately, neither of these methods are portable.   Neither work on Modbus PLCs.  You cannot list tags on a Micro800 series PLC.   You can figure out all the data files in PCCC-based PLCs but I have not implemented those protocol features and it is more like listing tags (i.e. all at once, not one tag at a time).

There may be a way to get a tag's size in elements from a Rockwell PLC individually, but I have never found anything documented or even hinted anywhere.  It would make a lot of sense to have such a feature, but if it exists, Rockwell is not making it easy to find.

In the future I will be adding some features for *Logix tag listing to make this more complete.   If there is sufficient demand, I will look at listing out data files for PCCC PLCs like PLC-5 and MicroLogix.

Most kinds of PLCs do not have any standard way for you to determine what tags are defined.   Some have proprietary ways of finding that information.

Best,
Kyle

Daniil Dolmatov

unread,
Jan 20, 2021, 9:57:01 AM1/20/21
to libplctag
Thank you for reply!
I tried to retrieve PLC tags  from the device as it is in list_tags.c and it worked fine except one case. In case of using PLC tag with User Defined Type (struct) I get instance id, type, element length without its structure info.
I tried to add  struct name to tag name attribute ("name=<program_name>.<struct_name>. @tags") and I found in setup_tag_listing that tag name is expected to be "@tags" or "PROGRAM:<program_name>.@tags". I changed separator in str_split to ".@"  and did some other changes according to this approach but it didn't help and I got 0x04 error ("The path segment identifier or the segment syntax was not understood by the target device.").
Is this approach wrong?
Is there any possible to get this info i.e. get list of struct's members ?

среда, 30 декабря 2020 г. в 19:24:16 UTC+3, Kyle:

Kyle

unread,
Jan 21, 2021, 4:59:43 AM1/21/21
to libplctag
Hi,

As far as I know, that won't work.   There are documented ways to get the UDT information, but it is not the same as getting the tag names and types.   Look for document 1756-PM020F-EN-P and look through chapter 2.   It explains how to get tag listings and how to get the UDTs.   The method that is described (which does not including how to get program tags!) shows the different CIP commands needed.

I have receive several Wireshark captures of other programs doing tag listings and getting UDT definitions and they all seem to do the same as the document says.   At this point, I do not think that there is another way to get the UDT data.  

I am working on a new set of core logic for the library using an event driven approach and completely refactored layering.   This is starting to work fairly well for PLC-5 reads and I hope to extend it rapidly to include all the current protocols supported by the existing core.   It should enable me to create a new PLC type, "raw CIP", that will let me experiment directly with getting UDTs.

Best,
Kyle
Reply all
Reply to author
Forward
0 new messages