Error -200279 with NI 9211

[SophiaS]

I'm attempting to write a program where I acquire temperature data from a 9211 with K-type thermocouple, and data from a non-NI piece of hardware via serial connection. From my understanding, the 9211 (using a 9162 usb carrier) basically just acquires data based on the timing settings I put in: sample rate (must be <12 for some reason), samples per loop (unsure what this means, really), and the onboard clock. I started the temperature acquisition using one of the labview examples from the example finder, and modified it for my needs. For the serial connection, I write the command and read the response (pressure), every 10 seconds. This could happen more or less often, but it can't be a continuous thing like the temperature acquisition. I also used one of the serial examples and modified it. 

My issue is that the timing never syncs, so I decided to try a state machine. One state I'm always getting the temp data (I set sample rate to 1 Hz), and dumping it into a slot in a cluster that I've made a typedef/ctl file. There's also a 10 second counter, then it switches to the other state. Here it writes/reads the serial device, takes whatever the latest temperature reading was (I basically throw away all the data between pressure readings, cause it doesn't really matter to me), and then puts time, date, temperature, and pressure into a .csv file. Then it goes back to the temp acquisition state. I have tried two different versions of the "acquire and log" state: one where I still read and store temperature data within that state in addition to my "wait" state, and one where I only read and store temperature data when I'm in the "wait" state.

When I tried it just all together in a 10 second delay while loop, it would also give this error.

I've taken the Core 1 course, and done some independent learning, but this is my first real program on my own. Can anyone let me know what I'm doing wrong? My theory is that the device itself is acquiring data roughly once per second, and putting it the buffer/memory, and then my read function is happening ever so slightly slower, so it's filling up? But how on earth would I make the read function go faster than/exactly equal to the hardware data acquisition? If I make the data acquisition slower or the read function faster (how?), then I'd not have enough samples to read? And given that the clock on this thing seems to be way slower than reality, the chance of them syncing perfectly seems to be zero.... So it seems I'm missing some crucial piece of information.

I also tried a version without the serial component at all - same state machine, but the "log" state would just log the temperature, time, and date. No serial read/write. It still gave this error, albeit after longer time. Usually this error comes after 15-20 minutes, without serial read/write it works for 2ish hours before throwing the error. 

My understanding is that I'm filling up some sort of buffer/register, but I don't understand how. I'm letting it do samples and read at its own pace, and not trying to store the samples anywhere. My data is just overwriting itself, theoretically. Or is the issue outside of the while loop, so it's never even going to the read function? I wish there was more documentation on how to program with this device....

Anyways I've attached the following files:

Temp State Machine.vi - this is my state machine with just the temperature, no visa read/write. I don't think the visa read/write is the issue, because this still gives the error, but I can post the version with that in it if necessary.

Temp Data.ctl - my cluster for data holding between states

[ZYOng]

Please post your VI in the earlier version like 2019 in the future. Most community users don't have access to the latest version of LabVIEW.

In your VI, you specify the sample rate as 1000Hz and read 100 samples. However, NI-9211 has a max sample rate of 14Hz thus the actual sample rate will be 14Hz. 

See Number of Samples per Channel Input of -1 On DAQmx Read VI to understand the difference of sample per channel on Read vs Timing VI.

Since you use time elapsed to read 100 samples every 10 seconds but 140 samples will be generated every 10 seconds. Eventually buffer overflown error will occur.

In your case, I recommend you set the sample rate to be 10Hz then you read 10 samples every second, or read 5 samples every 0.5 second.

[SophiaS]

Hi, thanks so much for the reply! I'll attach the files in 2019. 

I'm not sure why it says those values for sample rate and samples per loop, those are not the values I use. I'm using 1 for each of those. I'm collecting 1 sample per second, and reading one sample per "loop", whatever that means. 

When you try to run it with the default values (1000Hz/100 per loop) it throws an immediate error and states that the max rate is 12Hz. So that's definitely not my problem, as I'm not using those values and the VI won't even run with them. 

I do have an even simpler VI, that I've attached here, which still runs into the same error. Basically it seems like I can't run this hardware for more than an hour or so without it overflowing (or underflowing?) the buffer. 

Thank you for the suggestion of 10Hz and reading 10 samples/sec, is there any reason that would work better than 1Hz and reading 1 sample/sec, which is what I'm currently doing?

[GerdW]

Hi Sophia,

---

@SophiaS wrote:

I'll attach the files in 2019. 

---

No, you did not attach a LV2019 file. (It's still the LV2025 VI.)

Just renaming the VI does not change its LabVIEW version, you need to "save for previous"!

[SophiaS]

Hi Gerd, 

Thank you for letting me know it wasn't 2019! I did save for previous, if it didn't save properly then I'm not sure what happened. I guess I'll try again later, I'm currently trying to run it to see if the error happens again after changing some things!

I added the "samples per channel" control that was pointed out in the document the past person sent in their message, which theoretically sets the buffer size, so hopefully that works!

I'll try and convert my original files to 2019 to see if I'm doing something wrong in that process!

[SophiaS]

Okay, I figured out the save for previous version issue! Turns out when I opened it in my current version, the file reverted back to 2025. This should be 2019

[SophiaS]

These should be 2019 versions of my original files. To clarify, I've been trying mostly sampling rate = 1, and samples per loop = 1. It seems like I'm missing some sort of timing setting.

[ZYOng]

Sample rate of 1 in Timing VI -> OK

Number of sample per channel of 1 in Read VI -> OK

Sample per channel of 1 in Timing VI -> This input sets the buffer size. Ideally this value should be 10 times of Number of sample per channel of Read VI. Or leave this unwired to let DAQmx decide the value.

Again, see Number of Samples per Channel Input of -1 On DAQmx Read VI to understand the difference of sample per channel on Read vs Timing VI.

[GerdW]

Hi Sophia,

thanks for learning about the "save for previous"!

Now please learn some more LabVIEW basics:

• Why do you need to convert arrays to clusters just to index an element? Learn basics of array handling!
• Why do you need to unbundle 6 items of a waveform cluster that only contains 4 items??? What's the reason to unbundle t0/attributes twice?
• Why do you convert the Y array to a cluster just to index the first sample???
• Why do you convert that sample value to a string, this string into a cluster of strings, that cluster into an array of strings, that array into a spreadsheet string with a complete nonsense format string at ArrayToSpreadsheetString???

And after these questions:

• When you want to read just one (1) sample per iteration then you should use the "N chan 1 sample" mode of DAQmxRead. No need to hop through arrays and cluster just to read one sample!

Also read the LabVIEW help for each function you use:

• Don't show the function labels in the block diagram, use the context help instead! (No need to clutter the block diagram!)
• Read the help for DAQmxTiming, it explains the "samples per channel" input for EACH different "sample mode"!
  That value is used for manipulating internal DAQmx settings and should only be used for very specific use cases. Yours is not "very specific"…

[SophiaS]

Hi Gerd, 

I'm trying to learn the basics, it seems that the LabVIEW Core classes don't actually teach that well outside of the very specific examples they use. 

Admittedly, a lot of this is sloppy, because it's pared down from my overall code. My overall code involves a pressure sensor which spits out a string as the reading, and I have time and date strings, so that's why I have a cluster of strings. From the Core1 course, it was my understanding that the easiest way to write to a text file in a spreadsheet/table form was the write to spreadsheet string, which takes an array of strings. I have no idea how to change the values of the items within an array, I was under the impression that you could add or remove elements but I couldn't, say, change element 2 from 15 to 17 easily. Would love to figure that out, if it's possible. That's why I'm using clusters, because the examples in the class used clusters where you unbundled to access an item, and changed it. 

I convert the Y array to a cluster because it's somehow a "1D array of dbl" but I couldn't convert that straight into a string (again, need a string for the spreadsheet), I needed the actual number data type not an array of one number. 

Yes, it was sloppy for me to open 9 slots of the data and 6 slots from the waveform to access the Y array, I should definitely take more time to neaten things up once I find what I'm looking for!

That's a good point about Nchan1samp. Again this was me not really knowing how to handle something new, because in the class we were only taught 1chan1samp or nchannsamp, but I guess I can learn to branch out. 

I didn't realize my format string was "nonsense".... I genuinely thought that's how you're supposed to do it? I read the instructions and that's how I've seen others do it.