One of our biggest issues with ignition projects is version control. We have over 30 gateways that run similar projects scattered over a large geographical area. There is no practical way to make them all the same project both from logical implementation and physical execution. These projects are composed of standard groups of windows/scripts/templates/tags (lets call them pseudo modules. When updating a project we need to carefully import a new “psuedo” module which is very laborious since we have to manually import a data type folder, tag instance folder, scripts, windows and templates (maybe even named queries). There is no way to do this all in one shot and no easy way to know which “psuedo” module is installed in the project. It would be great to have two things. First, an import export tool that includes tags in the project import/export and a way to specify the set of things to import/export in a file. Second, a way to use GIT to look at the differences between all things… windows/templates/tags/scripts/named queries.
I was wondering if anyone has an approach to using GIT to see granular differences between projects. Git doesn’t work on the tag export xml files because the tags seem to be exported in no consistent order. It doesn’t work on project or gateway backups because they are just a big binary files. Maybe someone has developed a tool to export/import things in a GIT friendly format for version 7.9 ? It would even be useful just to be able to export a project into a GIT friendly format so two projects could be compared by script/window/template/tag. I know that this was a goal for 8.X ,but we cannot afford the change… too much invested in what we have.
This is fundamentally not something that will ever approach a ‘good experience’ in 7.9 (and even in 8.0+, there’s a lot of room for improvement).
Essentially everything about your gateway is stored inside the config.idb file in 7.9 and previous versions - project resources, tag configurations, database connections, and every other piece of gateway config. In addition to being stored inside a SQLite file (a binary blob that doesn’t readily support text-based diffing Git would require), individual project resources are stored as opaque, typically Java-serialized binary data. Specifically for Vision, this is actually triply encoded - windows are stored as not-very-friendly XML, then gzipped, then stored into the config.idb.
Legitimately, it would probably be easier to write a custom module than to try to shoe-horn versioning into a 7.9 system.
Thanks for fast and clear response. I like the idea of a custom module. However, after spending the past 6 months developing in c# and using git for version control it is clear this is a best practice that control system software providers need to incorporate. I like ignition because it is more open than any scada I have used. Git versioning would truly make it stand out from the ocean of proprietary monolithic software packages controls engineers like me must endure. It also would help to bring industrial control system programmers into the mainstream of best computer science best practices. My guess it the newest generation of programmers would be slack jawed if they knew the extent of industrial control systems running on unversioned ladder logic and hmi scripts.
Switch from v7.9 Vision to v8.1 Perspective. Much will be friendly to git. If git-friendliness ever comes to Vision, it won’t happen in v7.9. (EOL is a year away.)
I doubt a git-friendly format for Vision will ever happen.
Part of the reason for the existing format is legacy baggage but another big part is that it’s been optimized all to hell in the name of performance because the speed of de-serialization is directly reflected in how fast your Vision windows load as you navigate around.
Love to upgrade to 8.1… Anyone have a business case for it that could either reduce conversion to 8.X a trivial effort or justify the hundreds of hours to convert and test ? Any tools to make this easier ? My first attempt to upgrade to 8.0 was dismal. Granted it was early days with 8.0 but tags didn’t even work (many nested UDT’s). Plus major training to learn new environment. Have not tried latest 8.x maybe I will be surprised. Is Vision at end of life or just Vision 7.9 ?
Interesting. I've made suggestions on what I thought was a modest change to the XML encoder to make it dramatically more git-friendly, plus some other changes that would make it more human-friendly, too:
Is performance the reason none of these were pursued? I can't image the first item being a performance hit. The named references I described might, though. ):
I’m sorry that your initial upgrade experience was rocky. Ignition 8 has improved greatly from the early days, in particular with regards to UDTs.
As for the “business case”, I mean… this is your thread about how desperately you want better version control compatibility, which was certainly a major design consideration for Ignition 8. Yes, there is room for improvement, but it’s far better than 7.9, even just breaking resources out into files is a huge step forward even if the contents of those files is difficult to work with.
Hahaha, no, it really is. This was part of the “optimized to hell” bit that Kevin was alluding to. If you think about what XML is, it’s just a text-encoding of a certain structure of data. Well, at one point, to glean another ~10% improvement or so in parsing speed, we realized that we could encode the exact same information, but in a binary format, and it would be smaller and thus be parsed faster. It allowed us to use our contextual knowledge of the information being serialized do some too-clever-for-our-own-good things. For example, we can encode a color as a single 4-byte integer rather than as the character encoding of a 4-byte integer, which might be many characters (likely more than 4), which results in smaller encoded size plus obviates the need to then interpret the that string as a number.
When you shift right-click on a window and copy the “XML” to clipboard, we are transcoding the binary encoding back into the normal text encoding for your viewing convenience.
You are right, of course… 8.x would be a great improvement in terms of version control and probably other things I don’t know about yet. In my world it is hard to sell a major upgrade when things are working ok. I really appreciate all the feedback and discussion.
Very informative thread.
I’m the first person in my department using Ignition (v8.1.5) and have been asked to give an informal demo to my colleagues who’ll soon be using it. They’ll certainly ask about version control ability for Vision projects. Can GIT be used Jim initial posted?
Thanking you in advance!
Kind regards,
Ted.
