We have several projects where the ignition app has been at some level very cookie-cutter and standardized. There are lots of differences from site to site. They're all unique, but they all use the same elementary "building blocks". In fact, our gateways are set up with a "master" project that holds all of the common resources and a site specific project that inherits the master project and adds all of the resources unique to that site.
We've started auto-generating PLC code, and now that we've been approved to use 8.3, I've been tasked with leading the charge on dovetailing the ignition app generation as well. I'm still mulling over the design requirements, but so far, I want to automate as much as possible. This includes:
Device connections (we have several per site, and they're unique)
Tag groups
Tags
Site specific Views
So far the main issue I've run into is generating JSON files and injecting them into the ignition data folder. I think I can do that fairly safely with tags, tag groups, and views...but what about device connections? I know that device connections can be generated internally with scripting, but I'd rather not have multiple steps and different strategies for project creation. I was looking at the JSON files for device connections and I noticed there's a resource.JSON file in each device connection folder that appears to have some auto-generated content in it like creation date and some other things.
Among my questions is do I need to generate that resource.json file or can I generate the main device definition file only?
Is it possible to generate the files I need externally or should I use internal scripting with perhaps a generated "project setup" file as input data?
Appreciate the context of your comment, but I’m trying to erase spreadsheets from all of my workflows given how easy it is to make a purpose built tool these days. Say goodbye to spreadsheet errors and appalling microslop software.
Meh. Lots of engineers get training in finance, if not an actual MBA, and you can't pry spreadsheets out of their fingers. That's why I made my import tool tolerate so many different structures of source spreadsheets.
A well-organized spreadsheet is a really effective tool for a single source of truth, while carrying meta data that is not relevant to Ignition. Purpose built tools struggle with that.
I do not have experience with this specific problem, so take this with a grain of salt.
I have spent time via scripting manipulating the files. Typically, resource.json contains a reference to the page(s) with relevant information, so it would not need to be generated assuming it already exists. You would need to ensure resource.json has a reference to the page you are manipulating though.
You can generate these files externally, though it may be easier to do so via internal scripting.
Use LibreOffice if you don't want the Microslop. The best part is nearly all people, including junior engineers and non-engineers, use spreadsheets. But yes I've run into resistance with software engineers loathing the idea of a spreadsheet. The main downside I saw to using it was lack of compatibility with source control. Maybe a JSON variant could be in the future, but it wouldn't be as simple and straightforward as the spreadsheet.
Regarding site-specific views, custom string properties can be very useful when you use them to create relationships to viewPaths (or tagPaths). You can even drive an entire UI using this method. It keeps projects flexible to adapt from site to site, device to device, without scripting. It's also helpful you can drive these viewPaths via a default for the property in the UDT, but override them for any given instance via the Spreadsheet Import Tool.
Another benefit of the spreadsheet is that you can usually adapt a tab of your deployment spreadsheet for a given system directly based on source data from somewhere else in your system or from tables in engineering drawings. I've done it with tracker systems on large-scale solar plants where tens of thousands of rows, including supporting attributes, are generated by a vendor. Then add some processing columns to the right in the deployment spreadsheet and let 'er rip. Something didn't work or new data arrives during commissioning? Copy and paste the latest table and run it again. So easy.
I don't know if this is at all relevant, but I read "views" and "automation" so...
I'm looking at a large project at the moment with a tonne of pages in the existing scada which we're planning to move over to Ignition. Almost 1100 pages of varying complexity, mostly p&ids. Some are very complex.
So I've been looking into ways to bring the exorbitant hours down just in view creation alone. The existing pages are defined in text files and so I've been able to read these and get the positions and sizes of all of the components, as well as work out what components have tags associated with them. I stored this in excel for a reference. I used this to then create the view files in perspective and populate them with the device symbol view templates and tag them, as well as place pipework on the screen automatically. It's definitely not perfect and will need some manual intervention, but it's a really good start. I've also been able to identify some mistakes made in tagging in the original pages.
I should note that if you use LibreOffice instead of microslop, you can take advantage of their "flat" file formats. These combine all of the separate XML files that are normallly stuffed into a Zip wrapper, and write it unzipped. File extensions .fodt, .fods, et cetera. When the file options in Libreoffice are also set to save "pretty" XML, the result is relatively diff-able. This is the format I use in my 3rd party modules that have PDF documentation. (And my build can generate a new PDF, with embedded version details, without opening a GUI.)
I had previously attempted, to moderate success, using a what I called a compiler view that dynamically rendered View Canvas and SVG layers with the canvas items and SVG items bound to document tag structures. So any tagPath could be indirected to the compiler view, and as long as the tagPath had children SVG and Canvas tags with conforming structures, it could compile a diagram of any sort. Yes, it achieved our goal of extracting specific diagram-level configuration out of our productized Ignition project stack, but it was a version control and compatibility nightmare.
Having a configured, application-specific view JSON inside the tag provider would allow the productized project stack to remain consistent but be much easier to deploy and troubleshoot.
It’s been a pretty stable component, I’d love to hear your feedback. One of the big advantages of the JSON View component is dynamic bindings.
The biggest issue at the moment is that the view.json schema, while valid JSON, can contain keys that are not allowed in the Property Tree.
See this thread:
If you’re loading the view definition from a script/binding, you can get the Property Tree to take the values. If you’re editing it by hand though it will reject the writes.