Multi-Loop Data Acquisition

[jeanlucpicard]

Hello,

I have tried adopting a multi-loop data acquisition program with queue control, however it doesn't work the way it should. (Or at least the way I think it should) Could you please help me ironing it out? I've seen some vis on the internet with queue-control and tried adopting them.

My program should work in this way: after doing the settings, I start the data acquisition (one analog output and 2-4 analog inputs), however I only want to save the acquired data when I click a record button. (Then this saved data would go on for further analysis). While doing the further analysis, the acquisition can be paused. However, when I click record I'd like to have a functionality to instantly restart recording and discard the data previously recorded.

MainProgram vi is the app itself, with some settings done by event handlers (now limited only to a signal file selection and channel settings). Then the data acquisition can be started by clicking the Start Acq button.

And here come my problems: first sometimes the queue starts, sometimes it doesn't (or at least it doesn't start the data acquisition). And the main point: I set the sample rate, yet it is acquired at a much-much slower rate (my signal has a period time of 4 seconds, yet it needs at least 20 seconds to get near finishing). And the strangest: sometimes, mostly after some time (about 1-2 min) it hangs and does nothing with the daq (yet labview seems responsive, just my program hangs somewhere).

So now only the controlled acquisition is in the problem and first I don't care about forwarding the data for analysis and saving. (That seems to be the smaller problem).

What am I doing wrong? Thanks for your help. 

I attach all the files.  (MainProgram is the app itself, MY.SIGNAL is the signal file I want to output.) I use a USB-6211 device. (at work a physical one, at home a simulated one).

[crossrulz]

I don't see anybody Enqueuing into your StartAcq queue.  Which means you will just be sitting there forever waiting to a command.  Therefore no data will be acquired.

Also, you really should not be using an event structure to time your loop.  In fact, there is really no reason to limit your loop with a wait.  The continuous acquisition of the DAQ will do that job for you.

[jeanlucpicard]

The event handler of the button "StartAcq" does enqueue INIT_ACQ into the queue. (and IMO it starts the loop)

[jeanlucpicard]

(I just ran out of edit time)

In the meanwhile I tried removing the Timeout event handler from the AI_Read loop, but my problems still persist. I have a much-much slower input than 256 Hz (somewhere around 25 or lower) and it just freezes after 1-1,5 minutes for reasons I do not know. (the program responds, just the acquisition doesn't work). Or if I click the StopAcq button, sometimes I can restart the acquisition, sometimes I can't (it seems that one of my queues do not take the Init_acq message right for some reason). 

What can be the cause of these problems? (I tried creating this program without a queue-controlled state machine and it seemed to work fine. I thought it would improve it as it started acquisition immediately and I had to stop/restart vi for new settings to take effect)

[JÞB]

Hold it!  I will appologize if this comes out a bit harsh but I want you to re-think!

You are actually using a timeout case to enqueue a "Wait" command to other loops?  WTFWYT?

Now that you face-palmed yourself,  That's actually not bad code style! You have some talent for this LabVIEW thingy.  Take a peek at the "Contineous Data acquisition and Logging" Project template (Really, your code is not that far off that design pattern) and pick up the few pointers you missed.

Nice work!  Now go and  "get'r'done"

[jeanlucpicard]

Hey,

thanks for spotting my dumb error 🙂

I removed these timeouts and now the acquisition runs at fine speed. However I still have a problem: I receive some warnings and errors: I receive a warning of a buffer mixing while a regeneration causing new and old data to mix (usually after like 15 seconds) and I receive a 50103 error soon after I stop and then restart the data acquisition with the StartAcq button. (yet, the acquisition still goes on).

Could you look at my file what do I still miss?

(actually I took the NI examples for continuous acq and logging and tried messing them up 😄 )

Thank you,

[JÞB · Accepted solution]

Not directly related to your errors but, (and here I'm not trying to pick on you but......   With an alias like yours I assume you have some sence of humor)

Really????  a single frame event structure with only a timeout case (set to 1mSec) with a Dequeue element in it  How do you think the code would work by simply removing the event structure entirely

Spoiler

Gosh Jeff,  Let me see....Uhmmm maybe the dequeue element would just wait for an element to be enqueued to the queue I'm dequeueing from without needing to wait the whole millisecond for the event structure to timeout first....  Yeah....like that  I REALLY hope you do have a sense on humor-  If not accept my appologies.

This is the source of your errors

You are waiting and waiting and waiting to generate the same darned waveform over and over and over again just to enqueue it to the DAQmx write.

Take a trip through the example finder again "Current - Continuous Output.vi"  will demo how to set up a DAQmx task that regenerates a single waveform over and over agian until something else stops the task.  This will involve a fairly large re-write of your existing code but, the great news is you will learn something from the examples and DAQmx Help file. 

[jeanlucpicard]

Don't worry, you don't have to apologize, it really looks like a funny concept now in a written form and helped to get the absurdity of it 🙂

In the meanwhile I reworked my file and it seems to be working normally now. (To be sure I turned it repeatedly on and off and then left it running for almost an hour and it created no warnings and errors now.) I took a look at the examples again and tried reworking the output loop by it.

Actually I started LabView like two months ago (with a task given to re-design our existing measurement system to LabView), so I definitely miss a lot of fundamental knowledge, however, I am trying to educate myself on the problems I need to solve.

[JÞB]

Rubber Ducking your code can really help. especially when you are new to the language.

"If no events happen fire a timeout and remind all the loops that are waiting for a command that they should wait for a command"  would probably cause the little duck to look at you rather quizically.  Glad to have helped.