I’ve seen “template components” mentioned a couple of times in the forums. Is that feature still in active development? How soon might we see it?
That is one feature I would really like to have before embarking on any sizable Ignition projects.
This should be coming right after vector drawing. It may be in 7.3 or 7.4, its not quite clear yet. Depends on how other development goes for 7.3.
I’ve also seen the multiple references to the pending release, but what I’m more interested in is a preliminary functional spec of the ‘template components.’ To what level willl an “object-oriented” (understanding that it won’t truly be OOP) paradigm be available?
The obvious comparision is Wonderware’s IAS product. Is there an easy way to describe the new components in a comparitive sense?
I’m not intimately familiar with Wonderware’s product, so maybe you can fill in the comparison based upon this description:
The basic idea is that you’ll be able to make “templates” that are basically containers filled with components and such customized and aggregated in useful ways. The templates will be defined outside the scope of any one window. Those templates can then be used as if they were components themselves in windows and in other templates. The top-level container of the template’s dynamic properties will be exposed for property binding.
If you alter a template, it will change in every instance where it is used.
Hope this helps explain the plan. Feel free to let us know how this compares with your other experiences - this is still on the drawing board so now is the time to discuss how it should work.
This could be good or bad depending on the situation at the time of the change.
Option 1: when you make a change, a list of where the template is used is displayed and the user selects which ones get the update.
Option 2: each change gets versioned. After publishing the change, the user can update copies to a selected version. This would allow the user to make changes on an instantiated
copy of the template without worrying about their changes getting overwritten until they are ready.
Option 3: It's past my bedtime and I should stop trying to over engineer things 
Thanks for the response.
The important thing that you mentioned is the ability to propogate changes to previously depolyed instances on the base template.
The other thing that will be important is the ability to inherit from the properties of a template using OOP methodology. Not to the degree of allowing polymorphism, but all least enough to allow for a “car” object to be derived into a “sedan” and a “convertible” without having to rebuild each (classic inheritance).
I response to Robert, this is generally how you avoid the need to “pick” between objects to update. If you’re going to deploy an object (template) that you don’t want to update in the same manner as the current instances, it’s a good indicator that it isn’t truly the same object. A new template that inherits the attributes of the core template is needed.
I have to agree. Not to mention the added complexity with having some sort of “I changed the master, but only some instances get the change” system. This sounds to me like it is violating the KISS principle pretty badly.
Now, what I would like is for you to be able to click on a deployed instance of a master template and “detach” it, which would basically copy the contents of that master template into the window at that time, but prevent any further updates from being propagated to that instance.
As far as OOP goes, I’m not sure this would actually even qualify. I don’t think that one template will be able to ‘inherit’ from another. I’m having a hard time conceptualizing what that would look like. You will be able to use composition, of course. So if you have a template for “wheels”, you could use that template inside the “sedan” and “convertible” templates. Can anyone paint me a picture of what inheritance looks like for a visual template?
A virtual diagram? 
Thanks again for the reply.
I hope I’m not insulting anyone’s intelligence with the attached PDF, but this is a diagram of a typical controls structure that provides for a reusable, data-centric SCADA approach and is what I would like to be able to create with your product.
SCADA_OOPStructure.pdf (97 KB)
SSwing11
No insults taken here.
That PDF shows data inheritance followed by composition. The problem with that and Ignition is Ignition is visual based. So there is no picture of a Level sensor to derive the points(attributes) from an analog device.
What you could do it create a primitive (circle maybe?) and add the Analog points to that. Then turn off the visible bit and add another invisible primitive and call it a level sensor.
Then you can create your tank template and add your (invisible) sensors.
This would get you close to what your asking for.
I think Carl and the boys would have to make a number of changes to allow pure data templates.
Right, I think we’re mixing two different concepts here.
I’m talking about the ability to have master component templates. This idea is basically like our existing “Custom Palettes” feature with the [huge] difference that each instance of the template is tied back to the master, so that changes propagate.
What you’re talking about is the ability to define complex datatypes, including inheritance between the datatypes. These two concepts might be related in that you might use a complex datatype to drive a visual template, but they are really separate ideas.
There have been quite a few discussions as of late around here for the need to support more complex data structures (beyond what we currently have: loosely organized collections of scalar values – SQLTags). No serious movement on that front yet however.
But I’m not really talking about two different things. The ability for an object to encapsulate another and then be derived into a child object is not a separate issue, its simply sub-classing.
What I’ve descirbed (and drawn) for you is the core of the Wonderware ArchestrA platform and it is why large companies pay stupid amounts of money for the license fees. Its also a completely SQL backed construct where the inheritence is managed lia relational links.
I was guessing that because your underlying core development language forces OOP principles (unless I’m wrong and this isn’t Java backed), and because your tag structure seems to be a largely relational construct, that it would be a natural (please don’t read that as ‘simple’) evolution.
I like the nature of your open source paradigm and would love to use this as the core of a series of projects (> $1M) that in our stream this year, but I’m having difficulty reconciling the lack of an object based technology.
I’m still not understanding what OOP means for a visual template.
Your diagram is very straightforward, but only deals with fields (variables). Inheritance is quite simple if the “objects” that we are dealing with were just made up of fields, and perhaps methods. Then they’d model standard OOP paradigms available in so many programming languages, such as Java as you mentioned. Your diagram has really no bearing on the concept of master templates as I’m describing them. Your diagram is a data model diagram.
But we’re not dealing with traditional “Objects” here. We’re dealing with visual templates which are really just containers that hold a bunch of visual components, which may in turn be sub-containers. Each component has 1) properties 2) bounds (width,height,location) 3) event scripts 4) bindings on its properties.
Reconciling all of these things against OOP seems confusing at best.
Imagine a template. Its got some shapes, maybe a button on it. Some variables, whatever. Say its a valve
What, exactly, would a “subclass” of that template look like? It would inherit everything, I assume. It could add stuff, I suppose. Would it be able to “override” things? What would that even mean in this case? Could it re-arrange the components it inherited?
I don’t have answers for these questions, but I’m not asking them rhetorically either. I’m just trying to point out that the question isn’t as obvious as you’re framing it to be.
I still think that we’re talking about two separate concepts: data modeling (inheritance + composition) and template components (master template + instances, composition, but no inheritance)
Were we speaking in terms of the .Net framework, I would say that the shape and its animations would be just another class contained within the parent (or container) object because they are simply instantiated from the System.Drawing namespace.
I presume that in Ignition the underlying code is manipulating the Java.swing namespace in much the same manner. Given that, the shape is a class and subject to being a subclass of the “composite” object. In .Net we build properties such that they manipulate the drawn object just as an HMI animation would. Again, the property is a construct of the class and, in turn, the object. The scripting aspect would need to be managed in a different manner (I haven’t fully processed how WW accomplishes this, other than to assume that the script is referenced at runtime from a string field in the DB – I may be completely wrong in this assumption).
What I know is that the design time IDE for ArchestrA is essentially a RDBMS tool. That DB instance (the Galaxy) is then “deployed” to a runtime environment, which essentially creates an “instance” that is bound to the control level (or other DB) data source. This DB has the ability to contain vector based graphics as objects (classes), in what I can only assume are BLOB datatypes. These objects (known as ArchestrA graphics) are fully imbued with animations and the underlying ArchestrA object has a full scripting library associated.
I’m certain that there are levels of complexity between the InTouch runtime and a deployed Java applet that would need to be sorted out. I guess my poioint is that this is feasible…
Of course I understand how this would work in .Net or Java (yes, we use Swing), but that really has nothing to do with this discussion. Our users are not programming components by hand. If they want to do this - they are more than welcome to use the Ignition SDK and program up their own components (yes, using full OOP principles) in Java.
Honestly, I’ve heard mostly negative things about ArchestrA/Galaxy (you may be the 1st exception) so I think they may have overcomplicated things for themselves. You may disagree, but I certainly don’t hold it up as an ideal to aspire to.
If we were starting from scratch I could envision a system like you’re describing. But I want to take our existing design systems that we currently have and turn it into a master template system.
Imagine dropping a container on a window. You add some dynamic properties, drop some controls into it, configure some property bindings. I want to take this existing design paradigm that our users are already familiar with and take it to a master template system. I believe that this system would be very intuitive and extremely useful. It does not, however, lend itself to inheritance. Have you spent much time using Ignition? It sounds like you might be arguing your point on speculation. I think if you spent some time configuring some windows you might see what I’m getting at.
At a later phase we’ll tackle defining complex data models as an addition to the SQLTags system - at this time we’ll re-approach the inheritance issue, as data modeling naturally lends itself towards inheritance.
You’re spot-on; I haven’t configured ANY ignition apps. But I have used nearly every HMI product to hit the market in the last decade and as a general rule, they don’t differ much. There are two engineers in our company that have been through your training and hold your product in high regard. I certainly don’t disagree because I would have no basis for that opinion; however, I remeber a conversation, that could have just as well been the one that we are having, with a Citect engineer five years ago. After a significant amount of my time invested in the product, I found it to be lacking when compared against the claims (web deployed, extensible, etc…)
In regards to the ArchestrA platform, it is, unquestionably, the most powerful SCADA tool on the planet when put into the hands of a engineer that understands what it can do and “gets” the big picture of SCADA in a manufacturing environment. Having said that, there is no plausible way to justify it’s price.
Maybe what I need to do is, as you suggest, get into the meat and potatoes of ignition and then pull out your SDK and see if I can get it to do what I’d like it to. Please, understand that I am not, in any way, shape or form, being critical of your product; I don’t yet have the tribal knowledge necessary.
Fwiw, I've used them all too, and I think they are all overpriced and lacking as well. I would rather just write a GUI from scratch than use WonderWare or WinCC or anything like that (just had the pleasure of modifying a WinCC project yesterday- oh, the joy). And let's not even talk about the idiotic licensing models based on clients and tag counts.
But then I tried Ignition, and never looked back. It does everything, and I mean everything, that I want it to do. I'm doing some very large and complex projects with it, and it handles ful blown real-time animation, reporting, socket communications to any device, whatever I've come up with. And the support? Even when I annoyed the IA guys when trying to do something they didn't anticipate, we made it happen in short order. The support in itself is worth twice the cost of the license, not to mention that the users on this board are a wealth of information.
Don't worry about offending us - we've got pretty thick skin after so many years of trying to explain to experienced engineers such as yourself why we made a SCADA package that is different in a market where all the other products are alike. (and the corollary - why they should spend some time doing some re-learning about how to do HMI/SCADA projects!)
In any case - discussions like this are certainly welcome, as we like to solicit input before we design a new part of the system. In this case I think we should continue this discussion after you get some more experience so you understand what I'm talking about.
Sswing’s diagram is a classic Archestra model. The part that isn’t translating in your discussion is that the Wonderware Archestra model uses the term “template” to refer to an object that is primarily a data structure. One can build a custom template as the diagram shows but one can also add vector-based graphics to the template. So you have one template that includes both data (field attributes that get linked to PLC data points) and pretty graphics. In the archestra system, you can deploy instances of these templates and then you can customize the child instances by adding elements to them. Certain (but not all) changes made to the parent template will be deployed to the child instances.
Anyway, the templates being considered for Ignition sound more like Wonderware’s Smart Symbols - strictly graphic entities that can be re-used between screens and will propagate changes made to the master template.
Cheers.
I would hope it would also include the data mappings that drive those graphic entities. (relative mapping of course).
Having said that, I'm looking at developing an application that would create data points (SQLTags) every time I instantiate a template. (Have to learn Java and the SDK first me thinks)