I want to change the OpcItemPath of a large number of tags based on a gateway event script (the specific application is for a redundant Modbus connection).
I would rather not have to list every single tag in my gateway event script - it would be cumbersome for a large number of tags, and is prone to human error (me forgetting to add a tag to the script).
Instead, I would like the script write to a single string tag, and then for the UDT to use that string tag - either when defining the UDT, or have the UDT refer to a parameter which I configure to use that string tag when I create the instance.
Is this possible? Or is there a better way to do this?
I'm using Ignition 8.1.28.
Close. Have the script write to to UDT instance parameters (they cannot be bound to regular tags).
Thanks for the reply @pturmel - however that is the solution I described in the 2nd paragraph that I don’t want to do.
Having to list every single tag to change in a script would be unwieldy and error prone (there are hundreds of tags). I’m looking for a solution where the hundreds of tags reference a common string tag for the beginning section of their OpcItemPath, and then the script only has to update that one string tag.
I'm not sure you're understanding his suggestion.
Lose the String tag. Put your hundreds of tags in a UDT. Parametrize the UDT, reference that parameter in your OPC Item Paths.
Your script now just edits the UDT to change the param as necessary. Once (per UDT).
Well, you can't. Writing to UDT instance parameters to propagate into many tags within those instances is the closest you will get.
1 Like
Can you explain your redundancy setup? Is it that you have multiple connections and want to use a specific connection?
Couldn't something like this be done with system.tag.configure if there is some organization like they are in specific folders? I would probably go the UDT route though.
1 Like
Ahh… you’re right, I didn’t understand the proposed solution.
I hadn’t appreciated that you can write to the parameters in the UDT - I thought you could only write to the parameters in the UDT instances.
I think that is the solution I was looking for.
Thanks @pturmel and @Kevin.Herron for the help - I’ll try it tonight and report back.
Thanks - I think it was the terminology that caught me out here. Rather than the script writing to the parameters of EVERY UDT instance, it can just write to the parameters of the UDT. That should work - I’ll give it a go, and report back.
A bit about my redundancy setup - the PLCs I’m communicating to have redundant modbus communication cards. Each comms card has its own IP address, but in the back end the 2 cards are reading and writing to the same PLC memory points.
Some other SCADA systems I’ve used have support for this built in - when setting up the comms driver, you can tick the box for redundancy, and add the second IP address. The SCADA system then gracefully fails over between the primary and secondary channels based on channel health. At a tag level, this is transparent.
Given this isn’t supported out of the box in Ignition, I’m trying to manually create it. I have simply setup 2 modbus drivers, and then at a UDT level I’m parametrising which driver to use. Lastly, I’m having a gateway script monitor the health of the modbus drivers and adjust the UDTs to change between the 2 drivers as required. This should affect hundreds of tags at once.
There's a better way to do what you want very easily. I'm on my phone, I'll write more later unless someone beats me to it, basically you point your tags to a master connection and then change the connections via a script, the tags don't change at all.
Hmmm. Sounds like a neat feature I should add to my Advanced Modbus driver. What brand of PLC has this dual path capability?
1 Like
Other people have done this by just using one device and system.device.setDeviceHostname.
https://docs.inductiveautomation.com/display/DOC81/system.device.setDeviceHostname
2 Likes
Kevin beat me to it, here's a brief description on what to do. Your connection names can obviously be whatever you want.
- For communication between primary and secondary devices with different addresses/hostnames, create 3 device connections
- Device connection “A”
- Device connection “B”
- Device connection “Master”
- Connections “A” and “B” will only be used for reference to the diagnostics to determine a device connection
- Tags used throughout the project will reference the “Master” connection
- A Gateway Timer Script will run at a specific delay and will determine the correct hostname for the “Master” based on the connection for “A” and “B” and the pre-determined primary and secondary definitions (typically “A” is the primary and “B” is the secondary)
- If a connection to “A” is good, then use the hostname for “A”
- If a connection to “A” is not good and the connection to “B” is good, then use the hostname for “B”
- If neither connection to “A” nor “B” is good, then leave the hostname as-is
- Can have a delay to swap back to “A”
The PLCs I will be communicating with that have dual-redundant Modbus comms are Schneider Triconex and Honeywell Safety Manager SC.
Thanks for the solution - interesting that it results in having 3 active modbus connections to the PLC rather than 2. Given there would be no traffic to the A and B connections, I imagine this wouldn't add much additional load to the PLC. Are the device connections A and B still able to monitor the diagnostic health if there are no tags actively using them?
A quick update to say that both options worked:
- system.device.setDeviceHostname to change the targetted hostname/IP for device connection "Master" (as recommended by Kevin.Herron and jlandwerlen above)
- script writing the device name to a UDT parameter, which is inherited by all of the instance tags, with the UDT opcItemPath referencing the {parameterName} (as recommended by pturmel above).
Thank you to all for your help.
1 Like
@pturmel yes I agree, redundant Modbus comms would be a neat feature for your Advanced Modbus driver!
I have built a gateway script to basically do what is explained above i.e. to write to the 'Master' device based on the active connection status using the code system.device.setDeviceHostname as Kevin mentioned. The code did change the active device hostname and IP address to the active device as per intended, but the device connection status on the 'Master' toggles between 'connected' and 'disconnected' and doesn't connect. Is it because Ignition SCADA cannot have two MODBUS-TCP device connections with same ip address ? or the cause of the issue is something else?
You definitely can have 2 modbus devices in ignition that connect to the same IP address - it worked for me - so I don’t believe that is your issue.
It could be the PLC you’re connecting to doesn’t support 2 concurrent modbus connections?
That would be easy enough to test using a modbus master simulator like qmodbus.