Hello All, I am still beginner with ignition and have a question. Could we create screens (windows) by code ?
For example if I want to create a screen with 1000 object could I generate it by some code or I have to draw them one by one and create dynamics connecting it with tags and extra.
I don’t believe there is a way to edit completely out of the designer, but you could use some things to do what you’re looking for. There are template canvases and template repeaters, which are objects that show as many templates as you can fit and load into it, with their own parameters, etc. You can manipulate these with Python at the push of a button, or when the window loads, something like that. Its pretty flexible.
If Ignition screens were configurable through XML or JSON , then perhaps it would have been possible to configure projects programetically or thru a text editor rather than interactively. Of course its a trade off between visual WYSIWYG editors v/s command line text editing. Some people prefer graphical UI some command oriented UI for interaction with an application. Perhaps future versions of Ignitions may support this feature.
Ignition screens are editable with XML. It’s just rather cryptic. Hold the shift key down while right-clicking on the window in the designer, and there’ll be two extra menu entries for copying XML to/from the clipboard.
It’s easiest to follow if there are no bindings on the window – the XML encoding method processes the window’s interaction controller before its root container, so component references show up in the bindings before they show up in the container hierarchy. It would be nicer if that were changed.
Just an added bit of clarification to those who might be enticed by this–the XML will contain code for things like expression bindings, but deeper inspection reveals that the “computed” bindings are elsewhere (above, I think) in the XML. If you change the text of an expression and dump that back in, you’ll see the updated text in the designer, but the previous expression logic will still be active. The act of submitting the edit dialog [in the designer] of an expression binding is what computes and then produces the more cryptic binding XML nodes that are used in runtime. Basically, be careful if you use this feature.
Indeed. But it is relatively safe to produce many unbound components in a container hierarchy with PHP or some other convenient way to replicate blocks of XML.
An expression binding's XML is comprehensible with some help from the SDK.
In Designer, you can Copy (Control-C) any object.
Paste in Notepad, you can see the XML code for the object.
Conversely, if you create suitable XML code (in Notepad or wherever), you can Paste it into Designer.
I was able to write a program that parsed the graphic files from a legacy HMI, and put all the object definitions into a database. From the database I converted to Ignition XML, and copied this XML to the clipboard. Then I simply Pasted to the Designer window. Using Control-I to paste instead of Control-V respects the defined location of the objects, instead of pasting where you click.
Pasting more than about 1000 objects at a time didn’t work well, so a complex screen required several passes.
So far I have got most static objects to translate reasonably well. I have numeric displays working, but other animation gets more complex in my case, because the amination paradigms are completely different between Ignition and my legacy HMI.
So the answer is yes and no. Yes you can take object definitions from something other than Designer, but you still need to paste into Designer to finally create the objects in a window.
Indeed, and in the same format as for the entire window's XML. Unfortunately, there are Ignition versions and combinations of java versions where pasting the XML back into the designer is broken. Wherever the hidden context menu items are available, they work reliably.
That is really good solution and could work even with huge number of objects (as my case). But it didn’t work with me in past action to the screen ! I don’t know why.
That is amazing tips because I want to do the same as you did.
Creating static objects thru XML is understandable, however I wonder how Ignition stores the tag binding data configured for dynamic objects in the XML!