Continuous measurements and data logging using DAQmx with QMH

[paulrobinson]

Hi Everybody,

        This is the topic i want to discuss about continuous measurement using daqmx with QMH, previously i created a numerous topic on continous measurement and data logging so that i could learn more about different architectures to write a program. Now i want to discuss about the QMH architectural design patterns to draw a new idea on that, here i will start with new vi based on QMH,

with start, stop and cancel button to start and stop the measurement and to stop the vi but when i start the button i get a data values but when i press stop it was not stopping practically, i need to know what are the things i missed here and what are the things i need to keep in mind?

Thanks in advance for your valuable reply,

regards,

Paul

[mcduff]

Don't have LabVIEW here, but for simplicity, I suggest that you look at the DAQmx continuous acquisition example with events, search under the examples menu. It is a clean simple interface that is easily extensible.

mcduff

[Bob_Schor]

OK, you need to learn some Fundamentals (here presented in no particular order).

• Keep your VI compact so you can "see everything".  Try to program with straight wires, small structures, minimal white space, don't "Show as Icons".  I used the Cleanup Tool (the "Broom") and compacted things to get this:
• Learn how to use Value Change Events with Latch When Released switches (like Start).  You should put the Switch inside its Event (see above) so that you read it (and reset it!) when you push it (and Change it).  Data Flow!  Notice "Start" is not an Icon, is "small and compact" on the Block Diagram.
• Write yourself (use Word, pencil+paper, Notepad, whatever you like) a scenario of what you want to happen when various Controls are pushed.  Here are some relevant questions:
  • What happens before any button is pushed?
  • What happens when Start is pushed?  Does it matter when Start is pushed?
  • What is the difference between Cancel and Stop?
  • Do you really need three buttons?
• Using sub-VIs is often a good idea, as it encapsulates and isolates details you don't need to see right now.  However, in this simple task, it might be simpler if the lower loop actually did what you want to do, i.e. if the Init state, the Acquire State, etc. was right there.  Think about it.
• You probably do not need to pass references into your sub-VIs.  Instead of passing a reference to the data you want to output into the sub-VI and having it pass the data out by putting it into the reference, have the sub-VI directly pass the data as an output and wire it to the data indicator directly.  Much clearer, more direct, easier to test/debug/understand.
• Apropos the last two points, you should probably use Cancel directly, not a reference.  And it is not clear (to me) what you intend for Cancel to do.  A "State description" (in words, not code) would help.
• Your second loop seems to be a State Machine calling a State Machine, overly confusing and tricky to debug.  Collapsing these concentric loops into one (after writing the description of what they do) will certainly simplify and may correct your code.

 Bob Schor

[paulrobinson]

Hi Bob_schor,

  Sorry for asking same question again and i really want to know about QMH, now i attached a new vi using QMH with just start,stop and exit, but the program is not working in the way i needed, if i press start button, the one button dialogue box appears only one time and if i press again the start button it was not working, what am i missing here? i don't need a idea but i want to know, what i did wrong here and what changes do i need to make it work?

regards,

paul

[Bob_Schor]

I'm happy to help, but my crystal ball is on the fritz, so I can't see the VI you forgot to attach.

Bob "no underscore" Schor

[paulrobinson]

Hi Bob schor,

    Thanks for the reply and sorry for the underscore 🙂

     I again attached you the vi.

Regards,

paul 

[Kevin_Price]

Adding to Bob's excellent suggestions, and referring to your msg #1 code:

1. Your DAQmx code is reading a 1D array of buffered data.  If you want buffered data you should be making a call to DAQmx Timing.vi to set during config.  You should also add an action that calls DAQmx Start explicitly.

   Or, if you only want a single sample of AI at a time, never mind the DAQmx Timing and select the 1Chan 1Samp version of DAQmx Read.  It's still a good idea to call DAQmx Start explicitly.

2. It appears you want to use "Acquire Data.vi" as an Action Engine by calling it repeatedly with different actions from your top level loop.  In that case, you shouldn't have it loop from action to action internally.  Let the calling code decide when to direct the action.   

   The first thing to do is simply hardcode a TRUE to the while loop stop terminal in "Acquire Data.vi".   Then have the "Read data" action return data on an output terminal.  Also remove the delay timer.  You're not gonna loop internally any more.

3.  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. 

   The simplest thing to do is not the best, but it can at least get you started.  Have the "Read data" message case queue up another "Read data" message for its QMH loop.  Also have the event case for "Start" queue up both a "Start" message and an initial "Read data" message.

   Here's a reason this isn't ideal: if the event loop sends a "Stop" message while the QMH loop is in the midst of reading acq data, you'll add another "Read data" message to the queue which will be *behind* the "Stop".  You'll try to read data one more time *after* stopping the task.

   There are many discussions about the dangers of a QMH that feeds messages to itself.  Be wary.

-Kevin P

[Kevin_Price]

Your latest code works better after 2 simple things:

1. Your wrapper function for Dequeue should have its "VI properties" for Execution changed to be reentrant with preallocated clones.  That'll allow the loops to operate independently.  (I'd change the Enqueue wrapper too.)

2. Change the mechanical action for your GUI buttons to "latch when released".  Right click on each button to bring up the submenu.

-Kevin P

[Bob_Schor]

---

@paulrobinson wrote:

Hi Bob schor,

    Thanks for the reply and sorry for the underscore 🙂

---

Close, but no cigar -- not only don't I use an underscore in my name, Paul Robinson, but I capitalize the last name, too (see signature) .

So I largely agree with Kevin's comments.  Some of these will be similar, some different.

• The "squareish" Boolean Controls are, by default, "Latch When Released", which makes them ideal candidates for "Do" controls in an Event Loop.  When you put the Control inside its (individual) Event Case, it will "reset" itself when read, thus acting like a Push Button.  That's the rationale for this Mechanical Action.
• It is not clear to me why you are messing around with two Message Queues.  I just don't get it.
• Try to stick with the 4-2-2-4 Connector.  You don't use the Priority Input (and an NI guy with "Queue" in his name convinced me that "Enqueue at Opposite End", a.k.a. Priority Enqueue, can cause problems), so you don't need 5 inputs ... 
• Back when I used Queues (instead of Channel Wires), I didn't like having all of those Queue wires traipsing all over my QMHs.  So I made an Action Engine for the Queue that kept the Queue wire on the inside in a Shift Register (though I brought it out as the upper-right output).  However, as cool an idea as this was (so I thought), it didn't work!  Turned out I'd included the Dequeue operation as one of its Actions, forgetting that in a Queue, the "Dequeue" function is Sacred -- it needs to be treated as "special".  The solution was to keep the Dequeue function "naked", not wrapped in a sub-VI.  So I'd say "lose the Dequeue sub-VI", substitute a unique Dequeue function for each Queue.
• And why two Queues?
• And why is the Cmd Queue sent the Initialize (or, as you spell it, Initialise) message several times?
• Any why is there so much White Space (which bloats the Diagram) and why are the wires not straight?  (Neatness Helps). 

Bob "Picky, picky" Schor