VI with Express DAQ Assistant's needing help with NI Error -200279

[Rich_Tennant_Tech]

Wrote the attached VI to use on a cDAQ 9174 chassis with two 9211 cards and two 9239 cards. After running for about 5 seconds I'm getting a 200279 buffer error focused in on the assistant that's running the 9239 cards.

Not sure how to work that bug out, I would like to stick with the Express VI's if at all possible.

Thank you.

[Kevin_Price]

All the "voices of experience" around here will keep advising that continued reliance on DAQ Assistants and their Dynamic Data wires is a very limiting choice.

That said, what I see is that you have 2 distinct continuous 1 Hz sample rate tasks, but you're trying to read different #'s of samples from them each iteration (1 and 10).  So you're asking to retrieving 1 second worth of samples from one task buffer and 10 seconds worth from the other.  The loop can only iterate every 10 seconds when the slowest thing inside the loop finishes executing.  So the one task accumulates 9 additional "leftover" samples in its buffer every iteration.  

, 

Eventually those add up enough to make a buffer overflow error -200279, though I'm more than a little surprised it happens after only 5 seconds.

But my rule of thumb is that even if surprised, I'm *never* shocked by any particular undesirable behavior coming out of a DAQ Assistant.  There's just too many unknown details it hides.

You'll be doing yourself a significant favor by learning to use regular DAQmx.

-Kevin P

[Rich_Tennant_Tech]

Yes, you are right in that it's a pretty common theme around here to abandon (or just not use) Express DAQ Assistant.

As a new user, with no one at my facility that uses LabView and having just completed Core 1, I still find Express assistants to be pretty useful, but yes - limiting.  On a side note I did try writing a VI with DAQmx (see attached), but it has several problems (like no date / time stamp) in addition to the same old 200279 error, and do I need a separate DAQmx for each card?

FWIW I'm using a cDAQ 9174 with two 9211 cards (four channels each) and two 9239 cards (four channels each), and saving that into a excel file.

[PsyenceFact]

Hi Rich,

I don't know if you're aware, but if you right-click on a DAQ Assistant you can select "Generate NI-DAQmx Code" and it will be automagically converted in to the equivalent DAQmx functions.  You may find this easier to get your head around than starting from scratch.

PsyenceFact

[RavensFan]

Check the specifications on your cards.

You are trying to set all the cards to 1 Hz, but some cards may have pre-defined sample rates, that you can't arbitrarily pick whatever you want.  I think there is one module that the rate can only go as low as 1.6 kHz, or something like that.

So if you try to set it as 1 Hz, but the card coerces it to 1.6 kHz.  It is collecting 1600 samples every second but you'd only be reading 1.  You will quickly fill up the buffer.

I'm not sure if that is definitely the reason here, but it is worth looking into.  You should be able to read the actual sampling rate via  a DAQmx property node.

[Rich_Tennant_Tech]

PsyenceFact - I totally forgot about that (converting Express to DAQmx), will be giving it a try.

Thanks!

[Kevin_Price]

FWIW, I briefly did that conversion to DAQmx.  What I saw was a code construct that was going to create, run, and clear the task every iteration of the main loop, despite the fact that the DAQ Assistant was set for "continuous sampling".   I would sure hope that the DAQ Assistant doesn't *actually* do that.

Just a little heads up.  I'm not convinced that the conversion is a fully accurate rendition of the DAQ Assistant's actual behavior.  Nor am I sure it isn't.   If it *is* accurate, then the Assistant must be even worse than I thought.

-Kevin P

[Rich_Tennant_Tech]

 RavensFan KNIGHT OF NI

Check the specifications o n your cards.

You are trying to set all the cards to 1 Hz, but some cards may have pre-defined sample rates, that you can't arbitrarily pick whatever you want.  I think there is one module that the rate can only go as low as 1.6 kHz, or something like that.

So if you try to set it as 1 Hz, but the card coerces it to 1.6 kHz.  It is collecting 1600 samples every second but you'd only be reading 1.  You will quickly fill up the buffer.

I'm not sure if that is definitely the reason here, but it is worth looking into.  You should be able to read the actual sampling rate via  a DAQmx property node.

------------------------------------------------

Thanks for pointing that out, as a new user I'm not understanding why the hardware would be set to always run wide open and then crash because of an error with different cards running at different speeds even though it's all NI hardware.  One other hook is that the test that I'm trying to setup will be running for weeks maybe even months "non-stop" so scanning at something faster than 1Hz doesn't have any value.

FYI, previously we've used Graphtec data loggers, and then married the different data types in Excel.  But with the need to run more channels at once and have them aligned as its being measured we've decided to try LabView.

Ok, sorry for the rant, I'll try converting over to DAQmx and see what I can do to match speeds and eliminate the 200279 error.  I just need to figure out how to keep the buffer from filling up.

[Rich_Tennant_Tech]

Check the specifications o n your cards.

You are trying to set all the cards to 1 Hz, but some cards may have pre-defined sample rates, that you can't arbitrarily pick whatever you want.  I think there is one module that the rate can only go as low as 1.6 kHz, or something like that.

So if you try to set it as 1 Hz, but the card coerces it to 1.6 kHz.  It is collecting 1600 samples every second but you'd only be reading 1.  You will quickly fill up the buffer.

I'm not sure if that is definitely the reason here, but it is worth looking into.  You should be able to read the actual sampling rate via  a DAQmx property node.

------------------------------------------------

Thanks for pointing that out, as a new user I'm not understanding why the hardware would be set to always run wide open and then crash because of an error with different cards running at different speeds even though it's all NI hardware.  One other hook is that the test that I'm trying to setup will be running for weeks maybe even months "non-stop" so scanning at something faster than 1Hz doesn't have any value.

FYI, previously we've used Graphtec data loggers, and then married the different data types in Excel.  But with the need to run more channels at once and have them aligned as its being measured we've decided to try LabView.

Ok, sorry for the rant, I'll try converting over to DAQmx and see what I can do to match speeds and eliminate the 200279 error.  I just need to figure out how to keep the buffer from filling up.

[RavensFan]

---

@Rich_Tennant_Tech wrote:

------------------------------------------------

Thanks for pointing that out, as a new user I'm not understanding why the hardware would be set to always run wide open and then crash because of an error with different cards running at different speeds even though it's all NI hardware.  One other hook is that the test that I'm trying to setup will be running for weeks maybe even months "non-stop" so scanning at something faster than 1Hz doesn't have any value.

FYI, previously we've used Graphtec data loggers, and then married the different data types in Excel.  But with the need to run more channels at once and have them aligned as its being measured we've decided to try LabView.

Ok, sorry for the rant, I'll try converting over to DAQmx and see what I can do to match speeds and eliminate the 200279 error.  I just need to figure out how to keep the buffer from filling up.

---

It's not a matter of "always run wide open".  It is just that some cards are coerced to specific frequencies.    I did a quick search, but hadn't found whether your cards fell into that situation or not.

The error wouldn't be because you are running the different cards at different speeds, but because you aren't collecting enough data from the faster running cards.  Looking at your updated DAQmx code with a quick glance, I would have thought the problem would go away, it looked like you'd be collecting all the data in the buffer each iteration.  But I didn't dig down deep to see.

Remember, you can scan at a faster rate such as grab 1000 samples at 1 kHz.  Then throw away 999 of them, or average the 1000 down to 1 value.

[RavensFan]

------------------------------------------------

Thanks for pointing that out, as a new user I'm not understanding why the hardware would be set to always run wide open and then crash because of an error with different cards running at different speeds even though it's all NI hardware.  One other hook is that the test that I'm trying to setup will be running for weeks maybe even months "non-stop" so scanning at something faster than 1Hz doesn't have any value.

FYI, previously we've used Graphtec data loggers, and then married the different data types in Excel.  But with the need to run more channels at once and have them aligned as its being measured we've decided to try LabView.

Ok, sorry for the rant, I'll try converting over to DAQmx and see what I can do to match speeds and eliminate the 200279 error.  I just need to figure out how to keep the buffer from filling up.

[Kevin_Price]

RavensFan picked up on a detail I didn't even look into.  Indeed, the 9239 has a *minimum* sample rate of ~1.6 kHz, no matter what you request.  The 9211 also appears to support only a few limited possible sample rates.

I don't know the cDAQ family well enough to give specific advice, but it sure looks as though relatively trivial code based on DAQ Assistants won't be a viable path forward.  You'll need to learn more about the details of your cDAQ hardware behavior and limitations while structuring your code accordingly.  

There are several approaches that would probably lead to acceptable behavior, but they'll all require a good bit of "digging in."

Example 1: Both DAQ tasks are in independent parallel loops.  Both publish their data at, say, 10 or 20 Hz.  (You can publish to a Notifier, a Tag Channel, a global variable, or a Dynamic Event, among other possibilities.)  A third loop reads info from this place at 1 Hz and logs it to file.   

Example 2:  Keep both tasks in the same loop.  Treat the slower sampling task as a kind of master.  Configure the faster sampling task to "overwrite unread samples." 

    First read 1 second worth of samples from the slower sampling task.  After reading them, query the faster sampling task for a bunch of its most recent samples, up to a second worth.  Average, decimate, extract the very latest value, whatever -- reduce the bunches of samples down to 1 per task and log it.

There are other viable approaches too.

-Kevin P