Our release train is traveling at full speed, bringing Ignition 8.0.15 to the station. In 8.0.15, features include the new BACnet driver, a new 64-bit Linux ARM installer, improvements to the gateway web interface and new actions in the Perspective Module. Dive in to learn more about what's in 8.0.15.
You’ll find a couple of new entries on our Downloads page starting with this release. Let’s talk about them.
First, is the new BACnet Driver Module. I teased this module in the 8.0.14 post, and now it’s ready for prime time. The driver, utilizing BACnet over IP, allows an Ignition gateway to interface with other BACnet-capable devices via UDP.
The quick and dirty on the driver involves creating a “Local Device” configuration on your gateway (provided by a spiffy new Gateway Config page), which more or less registers your gateway’s presence as a BACnet-friendly device, allowing it to interact with remote devices using the protocol. From there, you create a “Remote Device” on Ignition’s OPC UA server, which works the same as our other device configurations. After that, you can start browsing for points in the remote device.
When using the driver, some properties are modeled as structures, which ends up being represented as JSON in our tags system. So an ideal way to extract points out of the raw JSON would be to create a UDT and use expression tags in conjunction with the jsonGet() function. We do have some documentation to get you started, as well as some IU videos if you want to see the workflow.
64-Bit Linux ARM Installers
Under the ARM Installers section of the Downloads page, you’ll see that we added a new installer, specifically for 64-bit Linux systems running on ARM hardware. Not too much to say here as it works just like our 32-bit variant, but worth noting the option is available now.
New Gateway Pages
Next up, the gateway’s web interface received some love in 8.0.15.
Gateway Network Diagnostics Pages
The pages (Gateway > Status > Connections > Gateway Network) already had a bunch of useful information, but we saw some opportunities to polish the pages, with the intent of making troubleshooting Gateway Network issues a bit easier.
For example, we used to list outgoing queues, but on their own they could seem a bit cryptic.
So, we renamed the queues to better demonstrate what they represent, as well as add some new columns that provide even more details about what’s going on.
You’ll notice a lot of similar changes on the various Gateway Network status pages. I’d list all of the changes here, but there have been a lot, so I’ll spare you the large list and instead invite you to take a look the next time you get your hands on an 8.0.15 gateway with some active Gateway Network connections.
OPC UA Server - Diagnostics
Before 8.0.15, gateways could show client subscription information from any configured OPC UA servers on a gateway, by heading over to the OPC Connections status page, and clicking on the “Subscriptions” button.
While useful, this button really only showed UA client information, so if you were hoping for diagnostic information about the UA server, that button didn’t really help.
In version 8.0.15, we made some changes. First, “Subscriptions” has been relabeled to “Client,” to better represent the underlying information. Second, we added a “Server” button.
Clicking on that takes you to a dedicated server details page. From here you can enable Server diagnostics, which will provide a host of additional details on what the server is doing. I put together a mini video tour to demonstrate the feature, which you’ll find below.
We made the server-diagnostics part something you have to opt into for performance reasons: enabling server diagnostics on a busy server can add a significant amount of system overhead, so we keep it off by default.
I should add that the diagnostics report is available on any UA server configuration, so this feature will work with third-party UA servers (if they support it).
New Perspective Action Options
Perspective Actions gained some new options when placed on certain events. Both options, which you’ll find towards the bottom right of the component action window, have subtle yet exciting implications. Let’s break them down.
First up would be Prevent Default, which allows the action to bypass the normal behavior associated with the parent event, as determined by your web browser. For example, lots of web browsers have a built-in context menu, so right-clicks will bring up the browser’s context menu. It’s fairly likely a lot of you out there don’t want that built-in menu to appear. Prevent Default really shines in that case.
Simply add a benign action to the container’s onContextMenu event, and enable Prevent Default. The next time you or your users right-click on that component in a session, you shouldn’t see the context menu appear any more.
The second option is Stop Propagation. In short, when a component is nested in a container, technically any events on the parent are called whenever the same event on any children components are called. Meaning, if there is a container, and a button placed inside the container, and both have onClick events configured, then both events will trigger when the user clicks on the button.
So you really couldn’t configure actions on a container if nested components were going to use actions on the same events. Stop Propagation was designed specifically to help in these scenarios. When enabled on the nested component, any actions on like events are ignored on parent components.
To demonstrate, I put together the GIF below. Basically, I have two sets of containers, each set has a container inside of a container, which is then inside of yet another container. Each container has a script that changes its own background color on click.
The top set of containers all have their Stop Propagation settings disabled (which is how these events worked prior to 8.0.15), so notice as I click deeper, all parent containers (the outer containers) are triggering their scripts, even when I’m not directly clicking them.
The bottom set of containers all have Stop Propagation enabled, so I’m able to click within a single container and only trigger its onClick event. This has some huge design implications, as it allows you to use the same event for multiple components, without worrying about triggering the same event on the parent container.
So, if you wanted to create your own right-click menu on different components, while providing different menu options based on where the user clicked, then these two properties make this much easier to do.
The Updates Keep Rolling In
To learn more about all of the other changes and updates in 8.0.15, check out the release notes or the Ignition User Manual. As always, we encourage you to tell us what you think and what you’d like to see in upcoming releases. As the release train keeps on pace, keep on the lookout for 8.0.16 as it arrives at a station near you soon.