Error handling with channels

[stephen.segal]

I'm developing a new application that needs to acquire, analyze, present, and log data continuously from a DAQ. It will eventually have to control other instruments too. The various new project documents indicate that channeled message handlers are preferred for new application development in LV2022, so I'm trying to give it a shot. I've decided to use 'examples\Channels\Measure And Log\' as my template. It appears to be generally similar to the "traditional" queue-based Continuous Measurement and Logging sample project, but uses channels instead of queues. Great!

It didn't take me long to realize that this example doesn't incorporate error handling. Nor do the basic channel training examples.

It does look there's a sketch of a possible error architecture in the Channel Message Handler template.

Question for those more experienced with the CMH design pattern -- is the method used in the CMH temp workable? Am I missing some obvious documentation somewhere on best practices when dealing with errors in a CMH?

[Bob_Schor]

I use Channels a lot.  I may have even invented the term "Channel Message Handler".  I haven't looked at the "Measure and Log" example, but I'll check it out.

My way of creating a CMH is simpler than the example that ships with LabVIEW (which I saw for the first time a few months ago -- I find my version easier to understand (naturally!).  I'll try to look at the Example code you mentioned and follow up here tomorrow.

Bob Schor

P.S. -- I seem to have posted a demo somewhere on the Forums on 13 Nov 2022 that shows a simple BS-style CMH with a BS-style Error Handler.  I can't find the post, so I'll attach it, again, here ...

[dsb@NI]

You have to decide how to handle the errors. In Bob's example, an error results in writing 'Exit' to the State Msgr channel. Some developers use the channel endpoints with an abort input and you can stop your code on error via that mechanism. In other error strategies, you might inform the user of the error and wait for them to fix it. This might be common in a configuration dialog. What error strategy are you implementing?

[stephen.segal · Accepted solution]

I've come up with a strategy that I think works tolerably well. I'll describe it and then mark this as 'solved'.

The channel measure and log example includes a VI called "AI Module" which simulates an analog input DAQ. Anyone wanting to use the template for a measurement task needs to replace this VI with something that communicates with a real DAQ. "AI Module" actually has a limited ability to return one specific error condition, though it doesn't use normal LabVIEW error methods to do it. If the simulated waveform settings are beyond a certain amplitude, then the channel that exports the waveform data stream is stopped. The receiver of this channel "AcquirerWithAI" has code that processes the stopping of that channel by sending a status message "Overrange" to the main application's status stream channel, which triggers stopping all loops and closing the program.

In my replacement for "AI Module", I've got 'normal' LabVIEW error handling being passed between the VIs that set up and control acquisition from my DAQ. I've updated the channel that exports waveform data to carry both the data and the contents of the error wire, and I've set that channel to stop in case of an error on the wire. I've also updated "AcquirerWithAI" -- instead of hard-coding the status message "overrange" to the app's status stream in case of the channel stopping, it uses the contents of the error from the data stream. The error message is simply extracted using "Simple Error Handler" and passed on to the main app's status stream. I've left all the other functionality that stops loops and the program in place.

This has worked quite well for me -- It just took a little while to get comfortable with channels.