I am working on a modbus device for the first time (that I recall), and I am struggling on the tag naming.
With 10,000+ tags, and a tag export being formatted as a .json rather than CSV, what is the recommended/suggested method of mass editing tag names?
At the moment it seems like my options are to either hand type/copy+paste thousands of tags, or to write a program to audit my modbus address export and my PLC tag export to cross reference multiple fields and assign the proper names from there.
I can't seem to find a good method of doing this, but this seems incredibly poorly designed to the point I can't believe those are the only two options I have.
For a home project with a few tags I would probably just label them myself, but for any industrial applications this seems absurd.
I've tried doing a data read from file in excel to get it formatted into something that I could write a macro on, but then exporting it out of excel back to json is seeming slightly problematic.
Do you have repeating patterns in the layout of your modbus addresses? If so, use an Ignition UDT, where the UDT has parameters for device name an base holding register address. Within the UDT, define all of the tags for that pattern, using arithmetic to generate the actual modbus address from the base address parameter.
Then you create instances of the UDT to create many tags at a time. With nice repeating naming conventions.
No such luck in any regard. The original programmers of the PLC seemed to actively avoid planning ahead. The modbus addresses, types, and purposes are entirely randomized.
(We have multiple instances of addresses such as: 404426 (int), 404427 (float), 404429 (int), 404430 (float), 404432(uint), 404433(int), etc).
The I/O cards seemed to have even been randomized with 3 outputs to one skid, 3 to the second skid, then 1 to 3rd, 1 to 4th, 1 to 3rd, 1 to 4th, etc).
Can you clarify... do you already have Ignition tags created for all these and you're just trying to edit the tag name or audit them vs a CSV reference list? Or are you trying to figure out how to create all these tags?
I have created all of the tags and confirmed the values are as desired per modbus address.
Now I am trying to edit the ignition tags such that the tag name of the prefix### format becomes the symbolic name of the PLC such as Tank1_Level instead of WTP_Int376
Sounds like a good job to say "Your mess, your problem. Thanks, but no thanks!" to
What do you mean by this?
Renaming the tags will likely be more difficult than just creating the tags again with the same config, in script of course. I have my own tag creation scripts/Excel pair that I use for this. I can read tag json and convert it into an Excel table. I can edit Excel table and convert it back into tag json. It's more work than I would share on here though sorry
Sadly not an option for a new controls company just getting started.
And the original programmers are long gone. We've gotten the project to redo their current SCADA in ignition almost solely off the fact we are willing to help!
The prefix meaning was for the address additions in Ignition, where you enter the prefix and then the start/stop addressing.
The json converting in and out of excel seemed to be the only route, but I just thought that was too inefficient to possibly be the expected method. I'll get that process going once this project is concluded and have it ready for the next.
I'll take this time to encourager the csv export function from 7.X be put back in, I'm not sure why it was removed in favor of the .json, especially given the import sitll allows it. That seems like a much more natural way of doing this.
I did find the .csv import example, so I may try that. I was just used to 7.X (and every other PLC/software) being an export as csv, macro to alter names, import csv.
Yes. It is. For a few tags from an instrument or something, fine. For a large PLC project, Modbus is a poor choice.
This may not be an option in this case, but I typically find it's faster and gives a better end result to reprogram the PLC from scratch (using prebuilt function blocks / AOIs for nearly everything) in cases where the original programmer has left a mess.
Also not an option.
Their current SCADA uses modbus to read the tags and they no longer have editing access to it. I have to get the current one working without altering that one's functionality.
The issue with a csv is that bindings and more complex values like lists of dictionaries (eg alarms) are "hard" to place into a single cell's value. Unless you do just copy the whole value as a json string into those values. This is what I do in my script, and I interpret complex structures the other way as well, but it's not intuitive at all to create those json strings in Excel... At the moment I just have a formula that creates the structure from values in other cells, but for alarms I only handle tags with single alarms attached. Multiple alarms would be a nightmare! Properties like writePermissions are also ugly to create in excel
I'm glad you brought that up, as that's the first reasoning that I've seen to justify not having the .csv.
Makes more sense now, but would still be an excellent feature for new installations.
I'm manually editing this time around, as the excel json import/exporting is new to me and was not all that intuitive from what I saw messing with it briefly.
Once this project concludes I'll research that and have something made to have a prepared response to future installs.
If you have any files or recommended points to look into to assist, that would be lovely.
