I am considering taking the leap and beginning to work with Ignition. One of the things I want to do before I develop the first application for my company is work on some standards. I want to create some standard objects that can be used over and over. Does Ignition offer the ability to be able to create objects and classes, to be able to work with instances of them? I’m hoping to be able to just change the master object and have the change reflected wherever that object is used. Is this possible?
That is not possible. Ignition does not support component inheretence. It’s a noted feature request that isn’t on the near term roadmap.
There are a lot of powerful features that promote reusability. The key idea being externalizing your properties in a database so you can reuse the objects, changing the data rather than the objects themselves - which may or may not have lots of customization. Custom Palettes allow you to cookie cutter objects. You can use Styles (Video) to change sets of properties, binding, and scripting to accomplish fairly complex property changes - especially if you store properties in your SQL database instead of individual objects. You can also programatically create Java2D objects with the paintable canvas component.
Nathan is mostly right - the paintable canvas component is the closest thing you’re going to get right now.
However - component inheritance or what we’re going to be calling “template components” is on the near-to-medium-term list and should be available within 6 months.
You can create a new palette and save a component (or container with components in it) as it is with all bindings attached. You just need to right-click one of the palette tabs and select “New Custom Palette”. The only drawback to this method is that there is no way to update a ‘master’ and have all the instances change.
I was hinting at the fact that he can have internal bindings that point to a single property, as well as scripts that call functions from the central library. This mitigates the need for mass changes in a well planned project, but doesn’t truly satisfy OPs question as Carl’s “template components” will.
Out of curiosity - do you guys have many real world occurrences in Ignition when you need to do the same change(s) to lots of components? Of those, cases where deleting and re-creating from a palette takes much time? It seems to me that mass duplication is usually taken care of with parameter passing (popup windows or selectable objects), so in effect you end up modifying the object in one place. Don’t get me wrong - I’m as interested in this feature as the next guy. It’s the one notable feature that Wonderware has been touting for a few years that other vendors don’t support. I’m curious how useful their implementation is.
Thanks for the feedback, guys. If I end up choosing Ignition, I’ll make sure to try and make use of the features you’ve mentioned.
You make a good point about the value of inheritance. In the past, I’ve worked on a system that had over 1500 screens. There were many cases where inheritance would have been super helpful. But what would have been way more helpful is if the initial developer had reduced the number of screens by about 1450 and just passed parameters to some template-type screens.
Maybe it's due to the industries I work in, but every project I've ever done would greatly benefit from component inheritence. For instance, if I designed a GUI for a plant that had 32 conveyors and 9 trimmers, I would want the same GUI to work if they installed two more conveyors and another trimmer, and I wouldn't want to have a bunch of "ghost" components in the background that suddenly appeared when the new conveyor were added to the database. I would want my code to create the new buttons, labels, and containers on the fly. The same would hold if a change was maded to one of the components- it should just take effect everywhere.
That said, it is certainly possible to create a very "inheritence-like" feel in Ignition, and my screens are very dynamic. It's very easy in python to create classes and instances of objects in the code, and although I can't create something like a button on the fly, like you said I can parameterize a table or list dynamically that becomes "clickable". And then, the paint component does the rest when it comes to displaying machine feedback and animation (I don't use any images at all aside from button icons). In fact, I just added a new machine to my database, and all of the screens just automagically started working without making any changes to the GUI at all. It is certainly doable within the current framework, but you have to think a little differently than you would in a VB framework.
Cool - good to know. It's coming!
[quote=“nathan”]
OIt’s the one notable feature that Wonderware has been touting for a few years that other vendors don’t support. I’m curious how useful their implementation is.[/quote]
one thing that wonderware has that makes changing tags in objects very easy is the ability to hit ctrl+E which pops up a window that lists all tags used in the selected area. you also have the option to replace text, so if I have a alarm button that I want to duplicate, instead of having to go in and change all of the tags manually I can just hit ctrl e and replace whatever I want very easily from one window.
If ignition has a function like this, Im not aware of it but it would be extremely useful. This is different than what yall are talking about but it is a feature that I use alot in wonderware that I really miss when moving into the ignition development environment.
I also would like to see what Jeff wants in the first post. An example we would use it for…
We have a time clock window that employees use to punch in ( Basic Time Clock ). As further projects are made that have this time clock I would like any change to the Master to roll down to all projects also.