Address Allen Bradley tag structure as an Integer

Ignition
1

I have a question regarding addressing Allen-Bradley tag data structure. Our PLC programmers have setup a series of boolean tags in a data structure in the PLC (a 1756-L81E, accessed though the Ignition Logix driver). The picture below shows the structure:

image
image525×706 20.9 KB

I am easily able to address the individual boolean statuses in the structure. A sample OPC item path would be ns=1;s=[PLC1_LTA]HMIC_MDR_1[105].Jam . However, I would rather not (at this time) create a tag for each boolean status. Instead, I would like to address the entire structure as a long value and use bit logic to obtain the individual boolean statuses.

This is what I did for our Siemens PLCs and it worked very well. It was worthwhile because it cut way down on the number of tags that had to be created for the project and tags can’t be easily configured just by path and name for Siemens S7-1500 PLCs. Also, it looked like having 30 - 50 thousand boolean tags might impact the system worse than having something like a thousand integer (often long) tags. A better way might be to read the structure directly into a UDT if that can be done.

At any rate, my code that I am porting from existing projects that use Siemens PLCs expect the data to be in an integer format. I thought that I could change the path to point to just the structure name (ns=1;s=[PLC1_LTA]HMIC_MDR_1[105] for the example above) and change the tag datatype from boolean to long or integer, but so far, I get a Configuration Error for the tag when I try this for any integer data type that I tried (long and integer).

Does anyone know if it is possible to force this structure into an integer by simple addressing?

My current plan is to create a UDT that matches the structure in the PLC and map the statuses to their boolean counterparts in the UDT. Then I can write a script to convert the booleans to the integer that my current code expects. Later (time permitting), I will probably change the code to work with the booleans in the UDT directly rather than converting the booleans to integers and then parsing the integers back to booleans to set the statuses on screens.

Can anyone address the efficiency (in terms of network communications loads, load on the Ignition server, and load on the PLC) when trying to read a smaller number of "wider tags (I mean, reading a single 32 bit long tag compared to reading 32 individual boolean tags. When the boolean tags are setup as UDTs, is that read somehow more efficient in terms of network and machine load compared to reading the individual boolean tags.

Finally (or maybe this should be first), is there anywhere I can learn more about these issues? I have searched the Ignition forum, the user manual, and checked over the IU videos and haven’t seen much addressing these issues. I will continue to review the IU videos related to tag addressing for UDTs to see what I can learn there.

Thank you for any information or sugestions that anyone can offer.

2

Ignition's driver will read them all together in a single request. Standard optimization as long as they are subscribed at the same pace. True of everything in the PLC's UDT, and its arrays of UDTs. Just make all the tags, and let Ignition's driver optimize them. The optimization doesn't care if you have UDTs on the Ignition side, but it sure makes tag creation easier.

Note: optmization will be poor if the UDTs and/or arrays are sparsely used. Unused gaps in the allocated bytes of the tags may require extra messages.

2 Likes
3

You should look into Igntion UDT's you can bind the OPC Path to UDT Parameters which should make addressing much simpler.

https://docs.inductiveautomation.com/display/DOC81/UDT+Parameters

1 Like
4

OK, thank you. I am currently adding all the boolean tags to the UDT structure and will convert them to an integer so that they should immediately work with my existing code. Once that is done, I will start converting my screens to use the Boolean values. I think that will simplify the code, but it may be a lot of work to do the conversion. At least it is a one time task (per DCM type) and it should make the code easier to maintain. I am happy that I should not have to worry about the efficiency of the tags. I think I was not aware of UDTs when I set the code up initially, that’s why I went with the Integers in the Siemens version (plus the fact that we used integer tags when working with Steeplechase in the previous version of the code before we started using Siemens PLCs).

5

Except for the !@##$%^&! price of the software, Rockwell’s technology spoils us users. You have my condolences for having to ever use Siemens.

5 Likes
6

Yeah, we have some Siemens supporters and some AB supporters on our team, so this is an ongoing discussion. Regardless, it’s harder to find Siemen’s programmers than AB programmers here in the U.S. Despite that, I will be supporting Ignition projects running on both going forward, so I will have to come up with UDTs that can work with either or maintain two libraries of UDT definitions (with hopefully very minor variations). I will have to setup my UDT paramaters to cover up the differences I gues, maybe with a flag to indicate whether the PLC is Siemens or AB.

7

Thanks for confirming my decision to refuse any Siemens jobs.

1 Like
8

Expect this. You can minimize the corresponding misery by never using UDT parameters in your windows/templates/pages/views. Indirect tag binding is very forgiving of "duck-typed" folders of tags, whether various UDT instances or true folders of individual tags or a combination.

Also, I believe Siemens DB access through the native driver is similarly optimized by DB, regardless what types you read.

9

Let me clarify, Phil means UDTType data type parameters; he's not referring to referencing UDT Instance parameters (e.g. folder/Motor 01/Parameters.DeviceName)

I still have no idea how to test a template that's using UDTType parameters as you can't link the template itself to a UDT instance. The Core and Gold certs had me utterly confused when I did them when looking at the way they'd done their templates. I actually suggested replacing them with tagpaths and indirect tag references in my answers :laughing:

3 Likes
10

Correct. Tags is not in this list:

11

Create a tag in the PLC to be a Integer or double integer and parallel the programmed output bit with another output bit from the newly created tag. Then, bitwise, the new tag will represent all of the boolean tags in your example. So the new tag might be Double Integer (DINT) HMIC_MDR_1_105.Status, bit 0 = Comm, bit 1 = Full, bit 2 = Alarm, bit 3 = jam, … and you can bring it all in one tag that way. It’s easy for us because here, we are the PLC and SCADA programmers so we present the data the way we want to use it.