This is a wide open question as I am not even sure where to start. I’m not looking for an explicit solution, but just guidance with what approach to take.
Suppose I had a list of tags in an Ignition project (Tag1, Tag2, Tag3 etc), and library of controls (Ctrl1, Ctrl2, Ctrl3 etc), how would I go about programmatically creating a Perspective co-ordinate view from a list of information (possibly in a DB) like:
Control1 is Instance of Ctrl1, with Tag1, at (x1,y1)
Control2 is Instance of Ctrl1, with Tag2, at (x2,y2)
Control3 is Instance of Ctrl3, with Tag1 and Tag2, at (x3,y3)
...
Bonus points for how to create the view in the first place.
I’m guessing that I need to access some sort of API within Ignition, but I don’t know if there is an internal or external API to do this.
Do you need to do this once, or dynamically/frequently?
In the former case, I would create a script to just manually create the view.json representation and push it to disk myself.
In the latter case, I would reconsider the requirements figure out which way I wanted to tread into unsupported territory. You certainly can create resources yourself and simply dump them on disk programmatically, though they won’t be picked up until the next 5 minute scan (unless you change that frequency).
I’m looking to automagically create a bunch of views based on a list of I/O from each new project that I encounter. So the process would be something like:
Export I/O list from PLC
Tag I/O with Control Type, Parameter on control, View name, and position in View
Automagically generate Views
Import Views into Ignition project
Profit!
So not a once off process, but also not an every 5 second process either.
This is actually something that my team and I have considered for plant PAx like implementations that don’t use all of the functionality of Plant PAx. To limit the complexity of the end project by removing complicated and performance slowing bindings just used for initial configuration.
You would essentially be “compiling” your own views for the project into more simplified “hard coded” views.
One pro is that I believe less technical end users would have an easier time understanding what’s happening on screens. However it does make “updates” potentially require a “recompilation” of those views, depending on the change.
“Compiling” is an apt description. I’m just looking to take a lot of manual work out of creating views that sort of need to be the same for each project, but have slightly different layouts and also different tag names in the PLC.
I think there’s an interesting meta-feature here for “power users”, but I don’t know exactly how it would work. You’d need some kind of intermediate layer between your pre-compile representations (presumably, what you’d want to actually save as resources) and the actually “compiled” regular view configs that Perspective would need. I don’t readily see how it could actually be implemented, though…
It’s definitely a power user feature. But the key thing is being able to construct and inject/import a view into a project. The rest is just ancillary bits and pieces
For comparison, I’ve previously written programs that built up text versions of CIMPLICITY screens and then manually imported them into teh project.
One aspect of what we are looking at is actually to the level of removing components from views at “compile time”, not just hardcoding certain parameters to remove bindings.
No reason to have a hidden label for something that will never exist on this project, just to cover for future projects that don’t affect the one you’re working on. That’s essentially some of the problem we are trying to work through.
Maybe I’ll make a tiny module that adds a system.util.designerContext() in the designer, from which you could pivot to the project system and create your resources manually…
I took a brief look at the SDK documentation and it looks like what I would want is a module that:
Adds a menu item to the Perspective Design surface
Allows the user to select an import file that contains the data
Allows the user to select a base location for the view(s) that will be created
Sucks in the data, validates it against existing tags and library objects, creates the view resources and then inserts them into the View tree.
Easy Peasy! The only issue is that I have no idea how to do that! (But I have previously built one of the example modules a looong time ago, so the process doesn’t scare me)
This will just be my next step in learning ignition!
figure out which way I wanted to tread into unsupported territory. You certainly can create resources yourself and simply dump them on disk programmatically, though they won’t be picked up until the next 5 minute scan (unless you change that frequency).