Hello, I would like to add a device and also configure its modbus addresses from a csv file along with it through a script. Is there a way to do this?
https://docs.inductiveautomation.com/display/DOC79/system.device The documentation does not show a function to do so but I was hoping there was a way.
There is currently no scripting function to load a Modbus Address Map, if that is what you have in mind.
If you’d like, you can put in a feature request here: ideas.inductiveautomation.com/fo … -and-ideas
Alternatively, you could build a script to add the device, read the CSV file, and add the tags using the system.tag.addTag function (docs.inductiveautomation.com/di … tag.addTag)
For Unity based processors (Schneider Electric M340, 580, Premium, etc), as a work around to this issue I made an excel file that I could drop the information from a database export in Unity and then in adjacent columns have it build the information for a csv file import into Ignition.
To do this I first added some sample tags to Ignition and confirmed that I had all the data reporting correctly for the data types I’d be using then I exported those handful of tags from Ignition into its CSV format. I found the couple of places there it cares about data type and did one giant nest IF statement on the Cell… though in hindsight a Vlookup would have been a LOT easier. Took the results from that and put it back in a csv file and imported it back into ignition.
It sounds complicated, but once I had the file set up it takes me just a minute to do the export from Unity and then import it into Ignition.
The only down side is that a CSV file has NO way to add alarms and it sure would be nice if you could add at least one digital alarm on a CSV import (please?)
The best place for feature requests is ideas.inductiveautomation.com/
It looks like someone has already put one in (ideas.inductiveautomation.com/fo … alarm-info), so you can sign in and upvote it, as well as add any relevant comments.
I posted the same idea a long time before but seems like anyone need it because i have no votes. I thought Ignition would do something from then to now but they don’t. I share you the link. https://inductiveautomation.canny.io/ignition-features-and-ideas/p/add-a-function-to-load-modbus-address-map-to-modbus-device
If you found some way to do it i would be so grateful if you share the idea.
This has always been a royal pain with modbus devices. Unfortunately, we have resorted to external tools to gather exported data from our PLC devices and transform the tags into the proper format for Ignition (actually, we have been doing this for years with other SCADA/HMI systems). The problem you run into is that every software development tool is different for PLC’s, and getting the data out is different each time. The other problem you run into with modbus PLC’s is that data structures are created typically from naming conventions, and if the company doesn’t have this, you are just stuck in a manual mode to get what you need.
Outside of PLC’s, many modbus devices have very structured and defined registers, and we have been creating UDT’s with the modbus address defined in the UDT with the device as a variable we pass on the UDT instance. This then just requires adding the device in the gateway configuration and Viola, you have all your registers with a single change. PLC’s are difficult, as this has not had any standard configuration and PLC registers aren’t always contiguous depending on data types created. The thought has come to mind, however, to figure out a way to achieve this by mapping the existing address space to achieve the same results, but requires a large time commitment to implement.
What we should be doing is pushing vendors to add OPC-UA/MQTT services to their platform to make this even easier. For those Schneider guys out there running the M580 platform, I’ve heard rumblings of them making a card you can install in the ethernet backplane that has OFS embedded and thus the tags (unlocated as well) would be just as easy as connecting to the OPC-UA server. I attempted to get OFS working independently (only works with Schneider PLC’s), but could never get the OPC-UA interface working right.