continuous measurement and logging, LV2014

[Blokk]

In LabView 2012 I examined how the project templates QueuedMessageHandler and the Continuous Measurement and Logging (CML) work. Also, there is quite a long and detailed documentation for the QMS. There is a much shorter documentation for the CML, but the reader is asked to refer to the QMS, since the CML is based on that template project obviously.

I just got LV2014, and I started to examine the Continuous Measurement and Logging (DAQmx) project template inside LabView 2014. There is a change there which is not documented: an additional typedef enum state machine in the MsgHandler loop. But there is no such change in the QMS 2014 version, so this change is not explained in details.

Could you direct me to some docs or podcasts explaining more the funcionality of the new version CML?

Also, when I try to run the Continuous Measurement and Logging (DAQmx) project template, just to see how it works, I see strange behaviour: even if I select "always log" at the triggering section, the force trigger button starts blinking, and two messages starts to iterate in the string indicator: logging and waiting for trigger. But I selected "always log" 🙂 Is this a bug?

I was reading an interesting "debate" from last year too:

http://forums.ni.com/t5/LabVIEW/Buggy-LabVIEW-Templates-amp-Courses/td-p/2298766/highlight/true/page...

I understand that, these templates are only starting points, but I would be very happy for some more documentations to understand how to properly use these templates (I was quite OK with the original templates, but the new ones got more complex due to the state machine).

Thanks for advices!

[Blokk]

I guess my questions may have been too general/under defined? Also it is not my intention to start again an old debate about frameworks, but to learn more. 

In the mainwhile another question came to my mind: i have seen nice ActionEngine examples in the forum, they can be also used inside a lvlib with scope set to private, and call them from VIs (encapsulation, data hiding). I really like this usage, and I wonder, if such encapsulated AEs could be used in frameworks like the QMH or the CML. I mean, to get rid of for example the HW ref cluster wires in the top level vi? 

edit:in the above post, QMS=QMH 🙂

[swirl · Accepted solution]

Hi,

The additional Typedef is necessary to ensure that only one DAQ-Task is started.
Thats because the Mechanical action is set as "Latch when released". So when you press the
Start button and release it, the signal changes from false to true and then it changes from true to false.
That would be two events. At the first event a new Message is created. Now when you take a look at the "Acquisistion Message Loop",
you will see an additional type def too. In this VI the DAQ Task is created and started. The problem now is the second event.
Now another Message is created to start an acquiring process. And if another DAQ-Task is started you would get a problem with LabVIEW and your DAQ Hardware.
But due to the fact that in the Acquisition Loop, the State is set to Acquisition with the first Message, the second Message will not start another DAQ-Task.

In the QMH there is no need for this, because you don't start an DAQ Task.


About the two indicators while logging, force trigger is set to false. So the programm is logging
and force trigger is disabled. After the logging process, the indicator is shortly set to Wait on trigger
because like said before it is disabled. Now Force trigger is true again and it logs again. This process
is repeated and the indicator is switching between these two states.
When you open the "Logging Message Loop" VI you will see that Force trigger is set to false.


Regards,

swirl

[Blokk]

thanks for explanation!