Measurement file not getting every data hit, presumably due to not processing data fast enough

[Harrison_Greene]

Hello all,

Thanks to previous help, I have code that starts recording once a threshold is detected, and it records at one million samples per second for ~7 milliseconds every time a "hit" is detected. I've been testing it by tapping my sensor 10 times and then plotting the data in MATLAB, and I've discovered that all 10 "hits" are registered perfectly when I space them out, but, if I tap 10 times rapidly, only 5 hits are detected.

This is a major problem, as I need the program to be able to register multiple 7 millisecond "hits" in a row for my application's purpose. Would anyone know how I can achieve this? I have messed around with channel wires to create two while loops for asynchronous processing, but not with much luck. For reference, I'm using an NI 9775 card and AE sensor.

Also, I would like to set the reference trigger to a window so that I could set the trigger for exceeding my threshold in the positive or the negative, but I keep getting error 89137, if anyone knows how to fix that.

Thank you all so much,

Harrison

[LVNinja]

I can't open your code ( i have version2020). But you could use one loop to acquire all data into a buffer and a second to verify the conditions (of the threshold and save it after the fact), this way you will not miss the event. 

[Harrison_Greene]

Hello!

I edited my original post, and I believe the code should be saved for 2017. Let me know if it works.

I came across enqueueing several times in my research, and I definitely would like to give it a try. I have used channel wires a few times but I'm not sure if they serve the same function. I'll give the queue a shot.

Thank you!

-Harrison

[Harrison_Greene]

To be completely honest, I am not sure at all what I'm doing with these queues. Is this correct? I couldn't really figure out how to get the element data type fed into the Obtain Queue VI. I was able to get data using this setup, however, but it still suffers the same way and I only get 5 taps on my sensor show up when I tap it 10 times rapidly.

[mcduff]

Need to go to a meeting, but why not use the built in logging features of DAQmx. A lot the DAQmx examples show how to use it. Data would be saved in TDMS. You could convert that later to text if wanted. Matlab probably has a library for reading TDMS files.

If you use the built in logging then no queues, channel wires, etc. Simple.

[Harrison_Greene]

I also have to leave soon and will be back Monday, but I tried giving this a shot, and, although I am unfamiliar with reading tdms files in matlab, just opening the file in excel seems to show that only a few of the hits are still being picked up. I am definitely down to look more into this later, though. Thank you!

[LVNinja]

it's worth trying this solution and see if all events are captured. If not it may be getting close to the limit, how far are the event when doing 10 ? 

[mcduff]

I don't think file saving/data acquisition is the problem.

You are stopping and restarting a task in loop. That does not occur instantaneously. You can try committing the task before the loop and the start sequence, that may help but not sure. The start and stop take time; if you need everything then go to continuous acquisition and some post processing of the data.

[Kevin_Price]

Like mcduff said, the main problem is that you *need* to do continuous sampling.  Then the other things (TDMS logging, queues, channels) can also be helpful but the crucial first step is to acquire continuously.

Otherwise, every time you stop and start the task is like closing your eyes for a moment before opening them again.  You won't see anything going on during the time your eyes are closed!  Now granted, that time is pretty short, but you also have a very short time (7000 sample @ 1MHz = 7 msec) with your eyes open.  The fact that you only "see" about 1/2 your events tells you that your eyes closed time is roughly similar to your eyes open time.  As a first experiment, try capturing  70000 samples each iteration, while still in finite sampling mode.   You will likely catch nearly all your events because your eyes-closed time will be a much smaller %age.

That's just a quick experiment though.   The real solution is to incorporate continuous sampling so your eyes are *always* open.   So set up continuous sampling and TDMS logging, start the task before entering the loop, make NO DAQmx calls inside the loop, just let things run continuously until you click the Stop button, then stop & clear the task after the loop.  Look at the file in Excel and you'll see that you caught *every* tap event.   (Note: it's good practice to add a short delay in the loop so as not to waste CPU iterating a million times faster than human button click speed.  A 50-100 msec delay will still feel instantaneous to a user.   An even better practice would use an Event Structure to react to the Stop button instead of repeatedly polling it.)

Attached are my trivial mods to illustrate, after stealing the example mcduff posted earlier.

-Kevin P

[JÞB]

Kevin is mostly correct! But even he didn't point out the worst programming error.  (Its not often that I can catch him on a DAQmx triggering issue.)  You using a finite samples task ( which WOULD WORK OK IF YOU DID IT RIGHT!) But you are completely ignoring the DAQmx Task State transition flow and essentially duplicating the inferior performance of a DAQ Assistant.  When you enter your While Loop the Task is in the Verified State.  That means when you call DAQmx Start Task the system Resources must get an exclusive lock (Verified to Reserved transition,) then the Hardware needs to get ready (Reserved to Committed,) and after the hardware is ready the Task starts taking readings and waiting for a trigger to form a record.  Finally you call DAQmx Stop Task.vi and,  since the last explicit transition was to the Verified State, the Hardware spins down, the exclusive locks are released and the Task is returned to Verified.  That takes a lot of time!!!

To properly configure a looping finite triggered AI Task:

• Create the Task
• Configure Scale, Range, and Timing.
• Configure Trigger
• Configure DAQmx Logging (Log when Read mode)
• Use DAQmx Control Task.vi to Commit the Task
• Enter your While Loop
• Use DAQmx Read.vi; Auto start will be your friend and automagically move the Task State to Running, waiting for trigger. After the trigger is seen the record (pretrigger samples, included) will be Read and Logged to your TDMS File. Then the Task state will transition back to the Commited State for the next iteration.  Locks intact and hardware powered up.
• You might want to handle / ignore any Timeout errors that will occur when no trigger is seen before the tmo value.
• After the Loop Exits, Use either: DAQmx Control Task.vi to Unreserve the Task Resources for other uses or, DAQmx Clear Task.vi.
• Pass Error Out or use a Simple Error Handler.vi.