Indirect Tag Bindings in Transaction Groups

Is it possible to bind indirectly to OPC/SQLTag items in a transaction group? I am envisioning something like this:

Say I have a group that is DB to OPC. I want to map some columns from a row in a table to a handful of tags. I’d like the tags to write to be determined by another column in the table. So my group would map from DB Col1, Col2, and Col3 to Tags/{EquipmentName}/Download/SetPoint1, 2, etc where EquipmentName was another column in the table I am selecting from.

Does this make sense? Is there any way to do this? I know I can dynamically set an expression on a SQLTag definition to get it’s value from an OPC item, but the write back to OPC option wants a hardcoded path. I suppose if that field was able to have parameters, it would work too.

If not, I think it would be a good feature to add to the system.



I can’t think of any way to do this right now. It’s traditionally done with a group per machine, but that doesn’t mean it’s not a good feature request.


We’ve done that before by using the system.tag.writeToTagSynchronous() function. Since this is a jython function, you need to call it from a runScript.

If I remember correctly, the expression item was something like this:

runScript(“system.tag.writeToTagSynchronous(’[Provider]Tags/”+{EquipmentName}+"/Download/Setpoint1’, ‘"+{DB Col 1}+"’)")

For each item you wanted to write, you would just set up a separate action item with this line (switching out the DB Col 1 for DB Col 2, of course).

Alternatively, you could set up a jython function that would take your arguments:

runScript(“’”+{EquipmentName}+"’, ‘"+{DB Col 1}+"’, ‘"+{DB Col 2}+"’, ‘"+{DB Col 3}+"’)")

Then your could take those four variables and call system.tag.writeToTagSynchronous three times.

Note: Don’t use system.tag.writeToTag(). We had problems doing it that way in the past, since it invokes a new thread, and your thread pool isn’t huge.

Colby, Kevin,

Thanks for the feedback. I had thought about doing it with scripting, and it would definitely take care of this type of behavior. The problem is, this project is running on the SQL Bridge only, so I don’t have access to all the scripting in the Vision module. Basically, these projects will download setpoints to many devices, and we want to try and use one generic group to perform all the downloading per area, so we don’t have to define a new transaction group every time a new device is added to an area of a plant. There are multiple plants with multiple areas doing this, and plans to continually expand devices being downloaded to, so it would save us a lot of long term maintenance. The notion of one set of PLC tags to download to along with a device ID for the PLC to figure out mappings is not an option for reasons I can’t go into here. I think indirect tag bindings either in transaction groups or SQLTags in general would allow us a more flexible system.