CMH and Continuous Measurement

[Gael_Br]

Hi,

I get slowly lost in the several idea and possibility to implement an use case.

I would like to ask for your help to better define and discuss "one" architecture, before I start to really implement it.

Use Case:

I am looking at an elegant and practical way to make programs to asynchronously acquire data from several sources, process them and log them.

My goals is to make small scale test stations for different production lines, which could be copy/pasted by different person and adapted to be propagated to other assembly/test stations. All using a similar architecture. This should help with the maintenance, as those setup could survive 20 to 30 years and will be maintained by different persons over the years.

Requirements:

Use the extensive documentation of LabVIEW to help with the maintenance of the system.

Limits the usage of external packages and framework.

Status:

I am in currently building a prototype. It is roughly an assembly based around a stepper motor being tested to check if a given dynamic torque can be reached for given power inputs.

Actual Direction:

The test station hardware is based around a cRio, used as a controller with an embedded GUI.

Regarding the architecture, I am reading here and there the possibilities, and I am going in the direction of those design pattern:

1. Producer/Consumer
2. Channeled Message Handler
3. State Machine

I found almost all my answer around here, and I would like to highlight some of the posts which helped me but also left me with the question of this post :

1. Re: Continuous measurements and data logging using DAQmx with QMH - NI Community
   
   1. Spoiler

      To retrieve data continuously now requires you to make a QMH case for "Read data" which in turn simply calls the action engine with the "Read data" action.  You need to send this message repeatedly.
2. Solved: Re: Difference between QSM and QMH? - NI Community
   
   1. Spoiler

      I'll offer a dissenting opinion on the "QMH should not send itself messages" statement. The Actor framework is basically an advanced QMH (it has a queue of messages that it handles) and Actors send themselves messages all the time.
3. Solved: Re: "Queued Message Handler" loops for asynchronous digital I/O from one piece of hardware -...
   1. Spoiler

      In a QSM, a case and its code define a state.  States are what get queued up.  A QSM will tend to linger within a state (or loop around to the same state repeatedly).
4. Re: Practical use of channel writers? - NI Community
   1. Spoiler

      Yokogawa/Safe Operating Limit

      1. Receives power analyzer configuration from the Control loop
      2. Initializes the power analyzer
      3. Continuously takes measurements and places them into a Stream Channel wire
5. Re: Practical use of channel writers? - NI Community
   1. Spoiler

      Yes, Channel Wires implement a Channel Message Handler (CHM -- I believe I may have been the first to call it that) which makes State Machines quite nice.

Question:

I am making multiple Acquisition Message Loops, one for each "continuous" acquisition.

At the end, I always get something similar to the "Continuous Measurement and Logging" template with its "Acquisition Message Loop.vi" :

Is this not a CMH which write itself its message (i.e. solution to avoid)? Or is the internal case structure (in the state "acquiring" on the screenshot) a QSM (inside a CMH) ? Is the second interpretation better and make this architecture "more acceptable" or is there a better solution?

Any help is appreciated 🙂

[Bob_Schor]

I'm embarrassed to have missed this question when it was first asked -- I believe I am the first to use the term "Channel Message Handler" (CMH) in a talk I gave at NI Week about six years ago.  As it turns out, I wrote a response to a Forum post a year ago in which I included an attachment that discussed a simplified Channel Message Handler, complete with PDF documentation and Project code.  I'm going to attach it here in the hopes that you are still paying attention to your former Post and can find this "late, but helpful".  The code is in LabVIEW 2019 -- let me know if you have questions about it.

Bob Schor

[mcduff]

I don’t like NI’s QMH. I think it adds complexity for no reason.

i do like the JKI State Machine. It is a queued message handler, but the queue is a string in a shift register. A single loop with an event structure and multiple states.

you can use user events to communicate between different JKI SM’s.

[Gael_Br]

Hi Bob and Mcduff,

Thanks for your response. Even late, their are much appreciated 🙂

The project is still in the making and I am improving the concept every month. I will look into your response in my next "deep dive" session.

At the moment I have implemented several (like 6) AML, which allowed me to be very close to the template.

Their are several philosophy driving my project, and the leading one at the moment is the very quick onboarding of "new people".

Like "I have not touched Labview in 15 months and I have to fix the test station of John (which is not here) in 2 day top to keep the production running" sort of quick.

But it can still change 🙂

I will come back to give some feedback!