The Modbus mappings in IA's driver are a crutch that even the author that driver recommends against using. Just make manual OPC Item Paths in your OPC tags.
You're suggesting I ditch the modbus layer via the Gateway configurator entirely and directly connect my [PROJ] layer to the OPCUA tags that would be held in there now? I can do that, but it doesn't solve my [HMI] layer referencing problem.
I suspect you are actually suggesting that I connect the OPCUA tags all the way into the guts of my UDTs, which I think I can only do via scripting, and would be a nice solution if I had a "final product" that I was multiplying.
Does your product have repeating patterns at various layers of your structure? If it does, make UDTs that take device name and memory area offsets to point at the right block of registers. Then your scripts, at worst, can make UDT instances with parameters to fit your PLC model.
Really, go look at the examples in the Spreadsheet Import Tool.
I looked at your tool, it does seem very useful for something like this. That said, I already have 90% of the apparent functionality in our MBUS -> PROJ layer mapping script (I just need to add UDT instantiation and swap the PROJ->HMI layer to be OPC->HMI) and so I think what I am going to do is beef that up to generate UDT instances in the same manner. I do an intermediate data modeling layer where I have handled all the basic tag types and a "generic" UDT type and I will just have to add a configuration map for connecting our device templates to UDT types that I will define manually. In the process of looking at your tool I realized a sneaky way to (just this once) fix my current project to point to a new project with some system.tag.getconfiguration calls and some careful text replacement.
Basically as you've suggested I'll have to move everything dynamic to the configuration process and make development have more overhead going forward in exchange for scalable deployability. Thank you as usual for the sounding board and the advice.
@Kevin.Herron if you want more people to viably use Ignition on R&D projects, I highly recommend considering a more dynamic memory layer than the way the tag system currently works. Happy to meet and describe our use case in more detail if it would be helpful.
I have a client that uses that Spreadsheet Import Tool as their source of truth for fast deployment and/or redeployment of big systems. Spreadsheets are very bureaucrat and egg-head friendly. Having something like that would free you to build UDTs and corresponding UI fragments for the researchers to tie together.
Lets say I have a CSV with columns {address}, {nickname}, {description}, {extra_info} and I export that from my PLC whenever I need to update my configuration. Does your tool support importing a primary source of truth for augmentation?
If each line of the CSV represents a tag, you would do the following:
- load the CSV into Excel,
- insert a "DummyIterator" column for column A, filled with integers to the same number of rows as the CSV. (The integers would not need to have any meaning, and could be all ones.)
- and add an operations block of columns to the right. At a minimum, a TagInstancePath column, a TagPropKey column, and a TagPropValue column.
- The cells in the TagPropValue column would use string substitutions using parenthesized column names from your CSV.
If each line of the CSV represents a UDT, you would handle it in similar fashion, but with the UDT action columns.
If your CSVs always have the same columns, the operations block could be copy and pasted from a template.
Ok I may come back to this. I'm going to take a pass first at just upgrading the mapping we are already using but if that becomes unfeasible I will thin it down to just map into what will be a good import document for this tool.