LabVIEW Developer Days 2018

The LabVIEW Developer Days (DevDays) in Nürnberg form the one NI event that’s taking place on our home soil – sort of. So, obviously, we never miss the chance to meet up with the local LabVIEW community and our NI contacts. A perfect opportunity to stay in touch and keep relationships alive!

Lorenz Casper kicking off LabVIEW Developer Days 2018
Lorenz Casper kicking off LabVIEW Developer Days 2018

Lorenz Casper and Andreas Gareis did a great job leading through the whole day, hosting the event and giving various presentations. Martina Fürmetz had taken great care of all things organising, and Florian Ottl, who happens to be our sales contact, tended to customers throughout the day. We are very grateful for NI staging the dev days, and for honouring it by sending four people to Nürnberg. A big thank you to NI and to Martina, Lorenz, Andreas and Florian!

Presentation on “DQMH in practice”

Manu and I had the chance to give a presentation on Delacor’s DQMH (Delacor Queued Message Handler). We have been working with DQMH for quite some time now, and we use it for most of our projects. Our customer HAGE was generous to allow us to show the generic parts of a real-life project: A DQMH-based Monitoring & Control system running on NI Linux Real-Time. We could also give a little insight into how the system is used at the end-customers’ production lines. Thank you very much, HAGE!

Real-Life project example at the LabVIEW Developer Days 2018
A CompactRIO-9030 using a NI-9472 Digital Output c-series module to trigger a Wenglor MLSL-132 2D profile sensor. The KUNBUS Profinet-IO module is missing in the picture.

Architecture

The following diagram, taken from our presentation, shows the basic functionality of the software: Data is acquired from different sources and displayed or processed in parallel in different locations.

You can see a historically grown main.vi on top, an FPGA function block at the bottom, and various DQMH modules and how they communicate with each other. The Profinet module (PNIO) acquires data via Profinet-IO from a Siemens SINUMERIK. The geometry sensor module (GEO) acquires data via ethernet from a geometry sensor. Both modules broadcast their data into the world. This data is displayed in the main.vi‘s UI. It is also written to disk in the logging module (LOGGER). Finally, it is used to calculate specific statistical values (GEOCALC) which are then also displayed in the main.vi.

Furthermore, we added symbols for the broadcasts (the “wifi” symbol) and those listening for broadcasts (the “ear” symbol).

Architectural overview of the real-life project software
Architectural overview of the real-life project software

Source Code

We also showed source code to illustrate how we work with DQMH. The logging module served as an example of how to register for other modules’ broadcasts efficiently.

Register for broadcast events dynamically
Register for broadcast events dynamically

The geometry sensor module implements a helper loop to actively acquire data from the sensor.

Actively acquire data from a helper loop.
Actively acquire data from within a helper loop.

If you’re interested, you can download the presentation slides here:

DevDays DQMH (PDF, german, 4.4 MB)

DevDays DQMH (PDF, english, 4.3 MB)

LabVIEW Developer Days 2018: Round-up

Coming back to the event itself, it was nice to see how our networking efforts start to pay off. We ran into a few people we already knew from past Dev Days or from our WUELUG usergroup meetings. Besides, we had conversations with some of our customers. To top it off, we made new contacts.

We managed to enjoy ourselves and at the same time get some networking done – what more can you ask from an event?

3 thoughts on “LabVIEW Developer Days 2018

  1. I see you are using DQMH with a cRIO. I have a project that were looking at using a cRIO, but not sure how well DQMH framework will deploy on RT. Have you ran into any problems while going this route?

    I saw that only cloneable modules are supported on RT. That doesn’t seem like too big of a deal though.

    1. Ryan, there’s a bug in LabVIEW that affects the “Control Value:Set” invoke node. This very invoke node is used when starting the module, to hand information to the main.vi (prepopulate controls) before actually running it. This bug only occurs on Linux Real-Time when Embedded UI is enabled and you’re running your application as startup.lvexe (in the run-time environment). Our workaround is to make Singleton modules reentrant, too. As we only start and stop those modules in one place within our application, this does not really affect our application design.

      You can read more in the NI Forums here or here.

Leave a Reply

Your email address will not be published. Required fields are marked *