I am working on a project where I have several conditions from other plc's on other tag providers and using these conditions for a separate plc, lets call it plant plc. I have setup the plant plc tags in Ignition. What is the best way to turn those boolean tags on and off from other scada tags? Is it to create a reference tag to access other scada plc tags and then have a tag script which turns on the plant plc tags? Is there another way?
A Gateway Tag Change event script that is monitoring all the tags you want to watch to determine what to turn on in the plant PLC is probably going to be the best way to go.
What is preventing you from getting these PLC's to talk to each other directly instead of through ignition?
1 Like
There are several vendors with this project and a few of them are not letting the SCADA side have much access to the plc's.
Relying on a gateway script for this type of control is not good practice. This should be integrated as much as possible into the plc programs with peer to peer messaging that utilizes heartbeat monitoring.
You did not specify the plc OEM but if it were say Control Logix I would define a datatype that all your vendors can import and utilize produced consumed tags which update implicitly. Otherwise you would have to setup the explicit messaging and connection monitoring manually.
If you must go the gateway script route I would define a seperate project to run this script(s) in that will be unaffected by project edits and saves.
3 Likes
Depending on what the tags are doing, and how much latency the application can handle, a few approaches may be better suited.
1. Reference Tags - If the tags are truly 1 to 1 (as it seems to me from your OP), then Reference tags are probably the best approach. They will have the most clear setup and probably the least amount of latency available from just a standard Ignition install.
- Gateway Tag Change Event - If the tags are not 1 to 1, and/or the application will not be sensitive to a longer latency (100s of ms + scan class time ). This is the best script based approach in a standard Ignition install.
3. Expression Tags - If the tags are not 1 to 1 but can easily be combined into a single boolean value, then this is probably the best approach. Again this will have a clear setup and won't be accompanied by a heavier than scan class latency.
-
Tag Value Change Scripts - Most likely the worst solution, though technically possible. There are caveats to using this approach that would rule it out for me personally, particularly if there are many of these tags, and the application is mid to large scale.
-
Another Option - If you are able and/or the client is willing to, then I believe that you could use Phil's Automation Professionals' EtherNet/IP Communication Suite V2 Module. It has some optimizations that may allow this to be done as nearly to a PLC as possible.
Of course as stated the best option for this is to do some type of peer-to-peer messaging.
If the application is sensitive to more than low latency or has anything to do with safety, then I would be refusing to do it any way but through the PLC's.
EDIT: Turns out I should read the manual a bit closer. Neither Reference Tags, nor Expression tags, actually write values back to a different device.
1 Like
Actually, thinking about this, a Gateway Timer Script which utilizes system.opc.readValues() and system.opc.writeValues() may be able to achieve a lower latency since it wouldn't be dependent upon scan classes.
If I understand your desire correctly, no Ignition tag type will do what you want. Only scripting will transfer data from a tag pointing at one device to a tag pointing somewhere else (to produce a write).
Ignition v7.9 and prior had a feature on Expression tags that would write the result of each execution to a desired OPC server/item path combination. That was deleted for v8, and upgrades replace that function with a "legacy" tag value change event script that performs that operation.
So you could try a bunch of tag change value events that call system.opc.writeValue() or .writeValues(), but those are synchronous operations that are inappropriate in tag value change events in any non-trivial quantity. Consider a gateway tag change event subscribing to all of the necessary tags. If write traffic is high, you will want to batch by target device, so the OPC drivers have an opportunity to optimize. The use of a ConcurrentLinkedQueue and a timer event (to pace the write batches) would be appropriate. See this topic:
I see. We are only talking about six to seven tags so its not many at all. Think we may go the gateway tag change event script route.
Seems like we are running 8.1.26 and the writeValues works for 8.1.27 and higher
Pretty sure that function has been around for some time, as it is in both the 7.9 and 8.0 manuals. You sure you didn't have a typo? It's pretty easy to do "system.tag.writeValues()" which isn't correct. I do it all the time.
1 Like
I am getting a write fail when I run it on the script console. The quality of the tag value is good so not sure why its not working.
Because you need a full OPC path
Try:
server = 'Ignition OPC UA Server'
path = 'ns=1;s=[PlantPLC_PLC01]Cond_Furnace_Door_Open'
returnQuality = system.opc.writeValue(server, path, False)
if returnQuality.good:
print 'Write success'
else:
print 'Write failed'
1 Like
Don't use the string "false" for a boolean. Just use python's False boolean constant.
1 Like
Yeah, typo, thanks, corrected code.
Make sure that the server is actually named Ignition OPC UA Server, mine is the default and is Ignition OPC-UA Server
I tried similar code on my system, and it worked as expected, so there must be some typo somewhere causing it to not work.
Is [PlantPLC_PLC01]Cond_Furnace_Door_Open really a PLC device and tag name, or is it an Ignition tag provider and Ignition tag name?
I thought the same thing, the OpcItemPath is shown in the screen shot, so I believe that is the correct path.
PlantPLC_PLC01 is the actual PLC device and Cond_Furnace_Door_Open is the actual tag name within the plc
Is there any chance the PLC has that tag's external access as ReadOnly ?