I’m trying to get a feel for what’s possible architecture wise with perspective graphics. I’m working on my first Ignition project (Hurrah!) after working in the DCS world for a few years. The DCS HMI I worked with really enabled what I would call an Object Oriented Programming (OOP). I could build a class of elements, say a PCV icon with a bar graph, tag name, etc, out of other class based elements. The symbol for simultation active was a class based element that was used all over the place. If I updated that simulation icon in the class I updated all my graphics. Needless to say that’s super useful IMHO.
As I’m learning my way around Perspective I’m trying to figure out if something like that is possible, and I don’t see how I would do it. Short of learning to build my own components, which based on the Git Repo doesn’t look easy. Am I missing something, or will I just have to learn to do without my precious classes?
Most of us will make our own symbols and other objects with a view, then use the drop config system to make them drag and drop from the UDT that we build them against. Long story short, you can make reusable elements that take a UDT path and parameters to customise it, and then every time you use it as an embedded view, it's an instance of the template view. On top of this, the entire style system is built on CSS which is fully class based, and universally accessible throughout perspective.
Take care though not to nest views too deeply (Max 3 levels) as it will affect page load times and can also cause params to randomly not to load in the deeper levels (this is a bug)
This is the same approach we use, taking UDT tagpaths as parameters.
I recommend starting with basic components like AnalogInputDisplay, DigitalInputDisplay.
Build out something with the elements you might use: Description, tagnames, value, alarm icon, override icon. Use parameters to enable or disable pieces you might not use.
I then embed these elements (AnalogInputDisplay, DigitalInputDisplay) in larger elements like a view representing a motor (with start/stop or speed command/feedback, for instance), disabling the parts I don’t need. The larger element takes that udt parameter and uses relative pathing to derive the paths of other embedded udt’s to pass to the elements.
Like was said, don’t go too many levels deep with embedded objects, but I have no problem with at least 1 level deep.
It's an issue many often run into unfortunately passing parameters too far down and then when the page loads something get passed correctly. In less complex screens it isn't as common of issue but when you have a heavy resource screen like an overview screen with a lot of objects on it and a lot of items embedded it can show up more frequently.
Passing simple values for parameters rather than objects with multiple values inside them helps a lot to reduce the issue.
Shouldn’t be passing objects to a template anyway. Pass the path (string) - which is essentially a simple value - and use indirect bindings. I wonder if this helps alleviate the issue. I also wonder how much it’s hardware dependent.
Yeah, but I've seen projects where they do pass tag paths but it's like formatted like:
key1 (object)
- tagpath
- differentpath
- some other bit we forgot about and needed afterwards
- etc
So then the sub-view unpacks it and still uses the tagpath to load the object but then maybe there is a second object they also need in that view and it gets added as well. Instead of passing multiple paths as key1 it should be flatted to simple values.
That was maybe a poor example to demonstrate, but there are other better examples where you have many params and many of the keys have multiple configuration attached to them, so it’s more logical to group them into their own keys instead of having 15+ keys in the base layer.
If you’re working with a version before Ignition 8.3 you will not have drawing tools inside Ignition Perspective so it is a little more involved to create symbols.
As others have stated, it’s a good idea to make your symbols as an embedded view using indirect bindings off a tagpath that’s passed in as a parameter. I like using UDTs to keep everything consistent across instances of devices. You can animate your drawing natively inside the drawing tools. This is by far the easiest way to build symbol templates in Perspective.
If you’re dealing with a pre-8.3.x version or you want to use a specific drawing of a device; you need to embed SVG drawings into your views. You do this by drag/dropping the SVG onto your screen and selecting the “embed” option from the radio button on the popup that will appear.
Animating it is a little involved. You have to find the element of the SVG that you want to animate and then either add a styles section to it to animate a CSS style class onto it or you have to animate a paint element. There’s a little trial and error with this method because the correct way to animate it varies depending on how the SVG was drawn.
If you use the custom embedded SVG method you should drive all your SVG animations off bindings to custom properties on the SVG instance. The reason is that the designer will collapse the tree to SVG nodes if a state changes on a binding and that makes troubleshooting more awkward.
Also, you should do blink animations with CSS styles; not with state changes of a tag. If your CSS binding isn’t working you may need to delete a “paint” element from your svg because those sometimes override (depends on how it’s drawn). I say this because I have supported SCADA systems that did direct bindings to deep SVG elements using blink animations off a “blink bit” and it’s very hard to figure out what’s going on when a device is in alarm because the SVG tree collapses before you can drill down to the animation binding. If you have all the state conditions bound to custom properties you can see at a glance what is driving the animations and troubleshooting is WAY easier.
To explain the reason for this, it’s purely performance and scalability. Bindings all run in threads running on the gateway. The more bindings you pack in, the more gateway resources are required, and the less scalable the project. CSS on the other hand is processed and rendered by the browser itself, including CSS animations so this takes the load off the gateway
I’m saying the bindings on the SVG nodes would just be property bindings to custom properties on the SVG instance and the custom property bindings on the SVG instance would be indirect bindings from the tagpath that’s passed in. Property bindings are fast. Indirect bindings are also fast. I haven’t seen a significant performance hit with this strategy yet.
I did a test with just shy of 700 instances of a template on a test screen to test a template using this strategy and they animated pretty fast. I’ve never done a SCADA screen that has 700 devices on one screen but I wanted to load test the strategy to make sure I didn’t run into problems after doing hundreds of screens on a sizeable SCADA in perspective.
The SVG for that template instance was 4k in size which impacts screen load time.
I generally agree that it’s good to reduce how many bindings you have on a screen. I think you gain more from supportability in this instance than you lose in performance.
