Hi all, new to Ignition so forgive me if this has already been covered- I did do a search! To that end, I believe a similar (but not quite the same) query was asked in the following thread: Faster way to add multiple opcua devices to the gateway
We have a geographically diverse network of Modbus TCP sites, approx 75-100 in all which have the same Modbus TCP hardware and so have the same register set. As a result, the only difference between them as a device in the OPC-UA server is the name and hostname/IP address.
I have figured out how to script the creation of sites - I read the site + IP address in from a CSV file and use system.device.addDevice (can even delete them too using system.device.removeDevice to clean up my testing mess ). However that still leave the issue of address register mapping which has to be done manually per site, even though all sites are identical. The register mapping is saved in a csv file, from the OPC-UA server once I had entered it, ready for addition to any new site.
So my question is: How do I use the scripting to import the register definitions when I create the new devices?
I have though of a few ways to do this and was wondering if any of the solutions exist (or should I add them to the ideas site).
Is there a function to read in the .csv register mapping definition when I create the site?
Alternatively, a ‘duplicate’ or ‘clone’ function would be really useful (you would have to pass an new name argument of course). This would be ideal in my case as I could simply duplicate/clone the device to a new name, then change the IP address with system.device.setDeviceHostname and all the registers would be copied across. Repeat process for each site- Voila!
As i knew the register ‘tree’ was shown in the OPC-UA Quick browser and also in the designer, I was hoping I could drag-n-drop the tags (again manual, but still somewhat easier) to a new site (told you I was an Ignition newbie). Unfortunately this is not the case. Is this possible anywhere?
Please also note I am working with an Ignition integrator who is building the system for us, they prefer (at least for the mo) that we use defined devices rather than direct modbus UDT tags (which I think I saw one of your training videos about somewhere).
Just FYI, the production system will be running under Ubuntu in/on/under an AWS virtual ‘box’, in the meantime I’m testing/developing on an Ignition install on an old steam-driven Core2duo laptop running CentOS 7 off a multiboot USB stick (but that’s another story! )
The register definitions are optional, intended to allow the user to browse for addresses. You can manually address modbus without any register definitions. If you use UDTs wisely (since you have many identical systems), you won’t actually have to edit each tag.
I understand this could be done in UDTs by direct addressing and this is exactly what I had been thinking too. However, my integrator had specifically asked me to try adding all the sites as devices with addresses. I have not seen exactly what my integrator is up to code-wise as yet (other issues being sorted), but he is setting up his own UDTs to use these device registers and specifically asked me to set up these device registers..
If I may 'read between the lines' of Phil's first line I'll assume Phil means the register definitions aren't meant as a permanent solution so I will have my integrator to have a look at this thread and see if the process can't be changed in our case.
Kevin, I can't find system.tag.edit in the 8.1 manual (system.tag ) ?
If you use them, they're permanent. All they do is give you addresses in a more convenient format. For example, you can setup address mapping so the OPC item paths used in tags match the address names in the PLC. This is probably what your integrator was hoping for, as it makes his job a little easier.
On the other hand, figuring out the correct OPC item path for Modbus addresses without using the mapping option isn't any more complicated than figuring out how to get the mapping setup right. I would setup a UDT with parameters for what varies between devices and then make an instance of it for each device parameterized via system.tag.configure and be done with it rather than setup the mapping.
Yes and yes. Your OPC item paths will look like the examples on the page linked in my previous post–like these:
With the device name (in square brackets) specified as a UDT parameter, that parameter is all that will need to be set on each UDT instance to connect all the tags in the UDT to the associated device.
If browsability is important, you might consider my Advanced Modbus Driver. No mapping needed. Configuration required if not using the default node address, though (1).
Thanks Witman, that's exactly what I thought of doing!
Phil, thanks for the link. I will investigate whether we need it... we may do so when a more complicated device is incorporated. Why didn't you plug it before?
Thanks all for your invaluable help and responses!
Patrick(L-plates on still...need a emoji for that! )
I plug it when the OP is after functionality that the native Ignition Modbus driver lacks. The native driver is part of the base license nowadays, so if you buy mine, you'll have both. My sales pitch has to account for that.
If you think you might need my module in the future, I recommend two practices for the native drivers to ease a future swap:
Use zero-based addressing. My module does not implement one-based addressing.
Do not use mappings. Construct all OPC tags with standard address formats. My module does not implement mappings.
You can also convert the other way: develop with my module using its OPC browsing conveniences, taking care to avoid features not offered by IA's native module. Then switch to IA's driver on deployment. If you actually encounter a need for mine, then deploy without switching.
The overview in my module's user manual describes the differences in more detail.
Hi all, just an update: we’ve recently received our production system and and working though various other issues to get it operational. Thanks for all your replies and advice. Just as you suggested,
The Modbus devices were added without need for the individual registers. I scripted the device additions which only took a few seconds (one issue with that, more later or in a different thread).
A UDT was created with direct addressing, and sites added using it- scripted by me again
Parameters used for various values that could change site-to-site which made it real easy to script up addition of the sites with the appropriate values.
There was one issue with the scripted site additions to the OPC UA which I think may warrant a separate post or thread, if I can’t find one already there…coming shortly!
). However that still leave the issue of address register mapping which has to be done manually per site, even though all sites are identical. The register mapping is saved in a csv file, from the OPC-UA server once I had entered it, ready for addition to any new site.
)
) for your prompt replies!