I'm working on a solution to automatically create Vision windows in Ignition by generating the necessary JSON and resource files (like resource.json and resource.vwin). I'm placing these into the correct project folder structure, but when I open the project in the Designer, the windows show up as COM objects instead of proper Vision windows.
I suspect the issue might be related to the lastModificationSignature field in the resource.json file. From what I can tell, Ignition uses this to validate the integrity of the resource, and if it's missing or incorrect, the Designer doesn't recognize the file properly.
yea lol ive spent a lot longer on it already than i anticipated. Do you have any incite on how the windows are created? I am currently experimenting with a work around where i create a project with 1 window and copy the window modifying resource.json. Also using SHA-256 to generate the "lastModificationSignature": attribute.
lastModificationSignature is not used as a signal of whether or not to load a resource; it's only used to know whether the 'source' of the last change was Ignition or some external actor. It's also possible to precalculate to make "valid" modifications externally, but again, all that does is let Ignition know that the "actor" on the modification is accurate/correct.
If you're pushing resources to disk, you'll have to wait five minutes [1] for them to actually be picked up by the project system, or issue a call to system.project.requestScan.
As @Leor_Fishman noted - manually creating window files, even if you set the resource encoding to XML (essentially a prerequisite for this) is not an easy endeavour, and I've already given him much of this same advice.
Whatever you are actually trying to do may be better served by:
Some existing capability in the software you're not taking full advantage of
If it's the same window, but with different "parameters", for lack of a better term, consider using templates and indirect bindings (extra hint for free).
Yea i am just trying to iterate through the json from the tag browser and create blank windows based on the tag browser structure. I hoped to do more once i figured out how to create the window but ill worry about that if/when i get there.
Right now my goal is just to make some blank windows. ive automated some of the initial stuff we do with tags and thought i could create and name the windows i need too. But where i expect to see my screens i see an empty folder instead
the number of windows is dynamic. Its dependent on my tags. I have a .net solution that is taking care of my tags and im trying to also get it to create the windows i need based on the tag browser. i have the folder and file structure setup. after reading PGriffith response i think i need to make some changes to the .bin file or generate one some how. figuring out how to serialize this file will hopefully solve my problem. however that is not a small task and probably why i should abandoned this, but want to atleast give it a shot.
Generating a valid .bin file outside of Ignition is going to be more-or-less impossible; I wouldn't even try.
Generating a valid .xml file is going to be nearly impossible, though not actually.
If you insist on going down this road, you must change the project property to store your windows as XML I linked above.
I can't really say this firmly enough though - it really seems like you're attached to "this is what I want to do" rather than "this is what I need to do". Do you actually need to dynamically lgenerate windows, or can you create templates for each UDT/machine/line/process/etc that simply accept tag paths as strings?
Put another way - in your plan to make a bunch of dynamic windows (when?), what is the thing that you want to programmatically duplicate and insert into each window? And, again, are you sure it's not something you can do entirely within the tools in the software?
Sorry im not trying to come off as dismissive to your advice. Its mostly just something i WANT to attempt. Not a need. I am not sure if there are tools that will do this already. Templates will be used after i can figure out how to generate the initial empty windows. My work flow will look like this export tags > export needed resources > fill in tags with information from an excel sheet (done) > create blank windows based on the tags > add images from image management based on tags > add templates > add tagpaths into templates. We repeat a lot of the same process over and over in our windows. However the objects used in the process are slightly different. This initial work is repetitive and kind of trivial but has enough differentiation to not be copy pasted. So with our naming convention i am hoping to automate it. I also am not picky on how i generate the window. I am no longer taking the .bin approach. I am looking into the XML or other potential solutions.
@chris_walsworth, would you be able to have you process generate data in the form of python code that a WindowOpened script could use to generate the configuration for a template canvas? Might have the window call a project script, which may be easier to update external to Ignition Designer.
I think this will be risky because its common for operators to do quite a bit of navigation because of the size of our lines. Im concerned having to dynamically load each window could cause problems.
I would expect it to be much less data transfer (for a canvas config dataset) than to move window design resources. Your concern is backwards. Having too many windows should concern you.
While we have other windows, there is 1 window per position. And 1 for each lockout. I am not sure how many is too many. I have also been asked to avoid scripting if possible so that employees of our client can make additions and troubleshoot when needed.
Are there parameterizable tag paths that go with each position and/or lockout? If so, add a dataset memory tag at those points that contain the template canvas dataset needed to drive the appearance of that window.
You'd have one window that takes a tag path parameter. You would indirect bind to connect the chosen memory tag to the template canvas. Super fast.
(Avoiding scripting is wise in Ignition, as it is less performant than most other ways to customize Ignition, but there are things that just cannot be done without scripts. Your clients will have to get over it.)
Maybe? Will this work with components that arent tag driven? ie navigational buttons? I am not familiar with this functionality but its my understanding it is error prone when navigating windows in succession. I have concerns about operators breaking it.
