Conditional unbundle by name

[NC_]

Hi there,

I'm working on an application for controlling a set of actuators and reading/saving data from a series of sensors. Based on the helpful advice from other folks in this forum, I'm building off the Continuous Measurement & Logging example, which is built off the Queued Message Handler template.

I'm using a "Data" queue (like in the example), and currently that queue is using a custom datatype that has both the Actuator states and also the Sensor data. So as new sensor data is read, this data queue is updated, or as a trigger updates the desired actuator value, this data queue is updated.

In one of the handler loops (for data display), I'm waiting for a notification and then unbundling the datatype by name and updating what's seen on screen.

I'm running in to an issue where the data coming out of the queue doesn't have all the elements set - for example when an actuation command is added to the dataqueue, when I unbundle Sensors.Temp1, there is null or blank data because the actuation loop didn't add any state to these elements. This then changes the data displayed on screen.

One solution would be to have separate queues for sensor data and actuator commands/state. I can do this, but it's already getting to be a pretty complicated set up for me to try and hand over to anyone else.

Is there another solution that allows me to only "unbundle by name if there is data"? Or I guess alternatively I could check every element for some null value, and only update the screen for non-null data. I have ~20 sensors, so I'd rather do something more generic than that if possible.

Thanks,

Tom

Example unbundling by name from an element of the data queue

Example of custom data type

[altenbach]

We can't help much with pictures, so please attach your VI for more specific advice.

Maybe you should only update the notifier once all elements are available? Or you could set it up so it sends the previous value for elements that have not been updated. There are many solutions (sender end or receiver end), but we probably need to know a little more than what we can deduce by staring at a truncated picture.

[Kevin_Price]

A common usage of the QMH pattern is for the Queue datatype to be a cluster (typedef'ed of course!) containing a string "message" and a variant "payload".   (Some prefer a typedef'ed enum instead of a string, but the general idea is the same.)

Upon dequeue, you unbundle the string message and feed it into a Case Structure selector.   Inside each message's specific case, you convert the variant into the datatype known to be appropriate for that particular message.

Then you can send an "Actuator State" message with a payload that's just the state info or you can send a "Sensor Data" message with a payload that gives updated sensor values.  The same queue can receive either one, and the specific message cases contain the code to handle each.

-Kevin P