daqmx low sample rate problem

[Muffin]

I am using the DAQmx functions to configure and read my analog channels.  I am having a problem with one of my channels that I want to sample at a very low rate.  Ideally 3 S/sec.  I either only get a portion of my data or none at all.  The read is performed with the "Analog 1D WfmNChan NSamp" function.  I have several channels so I set them all up and start them with the "Start Task" function.  Then I do some stuff while they should be getting data.  Once i'm done, I want to read them all and have a record of what happened.  This is after about 5-10 seconds.  So the flow should be like this:

setup all channels

start data gathering on all channels

Perform test while this data is being gathered (5-10sec)

collect all channels data

stop all tasks

done.

It seems like it is not releasing the data for some reason.

[Dennis_Knutson]

The only thing I can see from your images is that you are using a stacked sequence structure - a very poor architecture. Attach the actual VI after you remove that.

[crossrulz]

1. Change your architecture to use a State Machine.

2. I can't tell anything from you images.  Please attach your actual code.  And don't forget those subVIs as well.  In fact, I recommend just putting your entire project inside of a zip file and posting that.

[Muffin]

Here is the code.  There are two calls to a missing module that performs the "test".  It is irrelevant and can be deleted out to make it run.  The global file holds the sample rates.  I find that under 500 and it starts acting squirrily.

[Muffin]

I have noted one other thing.  I start all three sensor tasks pretty much at the same time and then read them sequentially.  I do them in order and maintain that order from start to read.  Yet everytime I get a different number is data back.  The pressure and accel channels return 8192 bytes back while the temperature channels return 12288.  All sampling at the same rate should they not be equal?

[Bob_Schor]

Oh, boy, where to start?  I'll echo CrossRulz -- change your architecture to a State Machine.  If you make it a Queue-driven State Machine (where you enqueue the next State rather than put it on a Shift Register), you can also use the Producer/Consumer Design Pattern to move the Event Loop out of the State Machine.  Most of your Events basically trigger brief "Do Something" pieces of code, which could be a State.

Get rid of the Sequence Frame.  Make each Frame a State.  Store State Variables in Shift Registers.  Do your very best to not use Local Variables.  Use more sub-VIs to "hide" some of the messy details so we (and you!) can begin to see the Forest for the Trees (i.e. so the overall structure of your Program is more apparent and not lost underneath a mass of wires).

Absolutely get rid of the Stacked Frame!  These things are horrors, with wires running in and out all over the place!  Replace it by multiple (named!) States, or make it a sub-VI inside of which is another State Machine.  If you feel you must use something like a Stacked Frame, I strongly recommend a For loop (counting up the number of frames) inside of which is a Case Statement wired to the For Loop Index ("i") -- this will also "count" down the multiple "frames" (or Case elements), but now you have proper For Loop walls and can place Shift Registers so variables live in a defined (and, I hope, "labelled") place in the Block Diagram.

I'm willing to take a look at Version 2 of this code.  It will probably take you a day or two (or more!) to clean it up ...

Bob Schor