Error -200361: Buffer Overflow Error

[coolhandLV7]

I'm working on an app to collect Pyrometer data, see attached .VI.  Originally i ran continuous sampling with my read AI.vi in a while loop (NChannels, 1Sample), i've since change it to finite (Nchannels, Nsamples) however i'm getting the error in the subject line.  Is this because the data is being streamed straight to file @ 50S/s, instead of buffering on the cDAQ chassis?  I don't get it, i thought running finite samples would make everything more efficient and free up CPU time.

Please help.

[Dan_K]

Hello coolhandLV7,

Could you provide more information on your hardware setup? Specifically the cDAQ Chassis and C-Series modules you are using.

[coolhandLV7]

Sure.

cDAQ Chassis 9174

NI9203 AI 4-20ma

NI9375 DIO

[Dan_K]

OK, I ran your code with simulated devices and did not get the error, so it's less likely to be an issue with the DAQmx coding.

It could be an issue with USB. You could try the solution from this forum post.

There is also the option of modifying the USB Transfer Request Size.

Other USB services on your machine could also be interfering.

I would also move your DAQmx Start into your case structure for when a software trigger occurs. This will explicitly start the acquisition every time instead of depending on implicit starts from DAQmx Read (after the first call).

Some other suggestions included things like rebooting your machine and using a powered hub (although that's usually with bus-powered devices, which the 9174 is not).

These are all just suggestions, but these, or something like them, could help you resolve this weird problem. 

[coolhandLV7]

Thanks, unfortunately the machine running this program is in France and it's after hours there.  I am remote accessing the PC running the executable for this program and did reboot it.  I just have to wait until they get in tomorrow to see if it works any better.  I read the article you mentioned earlier today but wanted to also get a check on my code structure.  i really thought about Producer/Consumer loops for this but it quickly became a project due to the triggering for two events.  Plus i read an article about TDMS streaming can be used to eliminate the complexity of Prod/Cons design and went that way.

Let me know if you have any other suggestions or if anyone has an example of how to queue data based on different trigger events.

[mcduff]

My Suggestion:

1. Rewrite your program.
2. Use the JKI State Machine - I think you can get away with a single loop
3. Use DAQmx Events for your DIO lines (Use the example finder for this)
4. The DAQmx Event will trigger your data acquisition.
5. Use the built-in TDMS logging, and just acquire all 8 channels.

mcduff

[coolhandLV7]

Ok so the latest update is that the code threw a generic IO error after one triggered event.  I'm starting to think that setting up the AI channel read for NChannels/NSamples and running it in finite mode is a mistake.  It seems to run better if it's in a while loop in continuous mode NChannels/1Sample mode.

I did look a little this morning into the DAQmx Configure Logging.vi, honestly i don't get it but wanted to try it out.  It threw an error 200557, and i can't seem to find the Logging.Mode property node to fix it.  

McDuff, do you have an example of how to use the built in TDMS logging and/or the DAQmx Events for the trigger?  I'd like to try it and see if it works better but i have no experience with either.

[mcduff]

Your application can easily be put into a State Machine architecture. I prefer the JKI STate Machine, available from VIPM, but it is your choice.

Think about want you do, I do not know what exactly you want, but from looking at your VI I can make the following guess:

1. Start the program.
2. Check if the DAQs are available
   1. If they are available go to an "IDLE" State
   2. If they are not give message to user and exit program (or you can add a "refresh" button to re do the search for the DAQs)
3. Now DAQs are present and you are in an IDLE State
4. Wait until somebody presses the "Run" or Start Button
5. Configure the DAQs
6. Set the DIO to wait for a "Change Detection Event"
   1. Depending on which line is detected go record the specified channels
7. Go back to IDLE State and Wait until the next event.

The JKI State machine has an event loop built in, so it is ready to go. BUT you need to know how to use events and State Machines.

Go to the Example Finder  and Search for Voltage - Finite Input you will see an example that includes the logging portion of DAQmx.

For the Change Detection Event you would have to do something like the following:

and then register the dynamic event in your event structure. I am not sure of your skill level, so maybe there is a better/easier way, but this is how I would approach the problem.

(There is a Digital Change Detection example it just does not use the Event Structure)

mcduff

[coolhandLV7]

I re-wrote the code, i haven't tested it out other than simulated.  I learned a little about event structures, i don't like setting them up but it seems as though the code does nothing at all until an event occurs, which is good.

My concerns at this point are around the DAQmx VI's, are they in the correct places so that they do not error out.  I don't know why but these VI's seem to work sometimes and not work other times.

The other problem i'm having is with the clear chart, i'd like it to clear each time the trigger occurs.  It doesn't work.

Any advice would be greatly appreciated.

[mcduff]

Attached is a skeleton project along the lines of what I was thinking. Open the project file.

Parts are complete but not tested, other parts you need to fill in. See if it makes sense to you. Right now, I need to drive kids and do work that pays the bills.

mcduff