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 🙂