Transaction Groups with Multiple Arrays

Ignition
1

Just looking for the best route to store data from several different arrays using a transaction group.

TagA - String[200] - ReadONly
TagB - String[200] - ReadOnly
TagA and TagB - Concatenate into one String ( I do this with a Run Always Expression) and store this combined String into the table.
TagD- DINT[200]
TagE- DINT[200]
TagF- FLOAT[200]

Also I have a Triggered expression - Doing a SQL SELECT from another table and storing that value into this table.

The Trigger is a Run Always Expression - and Looks at the TagA[xx] OR TagB[xx] for a data change to inserts the data into the table.

So the only way I can see to do this is to use 200 Transaction groups. Hoping someone out there has another idea.

2

I would say a block transaction is what you’re looking for.

The main difference from the standard group is that the data is stored in a tall format instead of wide. A block_id and row_id column are added to further index the entries.

3

Looked at that before. But they need to be individual inserts.

I only want it to insert when TagA[1] and TagB[1] data change - to insert all of the [1] elements from the individual arrays and So on when TagA[2] and TagB[2] - insert all the [2] elements.

The block will insert all 200 elements.

4

I think this may be one of those occasions where this is easier to do in a Gateway Event Script, probably in a timer. This gives you the ability to loop and it would be easy to write a function that’s run the appropriate amount of times, checking your trigger points, reading data from another table and writing out to your database when required.

5

I was thinking a buffer space and using indirect addressing. I’ve done PLC driven ring buffers in this manner.

EDIT: Where are the arrays? Are they in a PLC? In a dataset? DB Table?
…
Sorry… starting to sound like my kids! At least I didn’t add “Where? WHERE?” :laughing:

6

The arrays are in the PLC

I am doing the Ignition work only - so I don’t have access to change the PLC code.

7

Okay last question of the day. What version of Ignition? Then I’ll leave you alone and cogitate on this for a while.

8

I am using 7.8-RC1 - because the end result is to create a report using the new reporting module from this data.

also - not “great” at python scripting yet:)

thanks for your help.

9

Just popping back through here to apologize. Didn’t forget you, just got slammed with a bunch of stuff here at work. Hate it when work gets in the way of fun! Hoping to find some time today to get back at it.

10

Thanks - I figured out something. Basically made a memory UDT in Ignition and wrote a data change gateway script that read the indirect arrays through a pointer and does a tag read and a tag write to my ignition UDT - that way I can use 1 transaction group.

Seems to be working fine - what it is nice is there was a pointer already in the PLC - so it is fast enough to be logging all the data so far.

11

So after some testing - the pointer in the PLC can increment pretty fast. So my code it not catching all of the data. Below is the code I am using.

#This will read the current pointer from the PLC and store it in the script variable.
pointer = system.tag.read(“Indexer”).value
#This will collect the array tags and use the above pointer and reads those values into the variable values.
tags = [“TagA_%i” % (pointer), “TagB_%i” % (pointer), “TagC_%i” % (pointer), “TagD_%i” % (pointer), “TagE_%i” % (pointer)]
values = system.tag.readAll(tags)

#This will read in the UDT memory tag created in the tags folder.
udttags = [“MemoryUDT/TagA”, “MemoryUDT/TagB”, “MemoryUDT/TagC”, “MemoryUDT/TagD”, “MemoryUDT/TagE”]
#This will write the values from the above array tags into the memory UDT tag.
system.tag.writeAll(udttags,values)
#This sets a report trigger memory tag to be used for the transaction group
system.tag.write(“EventTrigger”,1)

“EventTrigger” is then used in the Transaction group to store the values from the MemoryUDT to the database. This works well it is just steps 1-5 happen really quick, and the gateway script might just not be fast enough to catch the change map the UDT store the data and move on to the next pointer.

I have been trying to create a counter of some sort and use my own pointer in Ignition with no avail. Just seeing if anyone has any input on a way around this issue.