1)buffer overflow, 2)input terminal configuration for multiple channels, 3)waveform fluctuation

1)buffer overflow, 2)input terminal configuration for multiple channels, 3)waveform fluctuation

Post by uclabm » Thu, 20 Apr 2006 17:10:09

Hello, There,I encountered a few questions.  Been pulling my hair out.  Getting bald so I am hoping to get some assistance here and save the rest of my precious hair.1.  I am encountering buffer overrun problem.  Though it has been mentioned by multiple threads, such as ( http://www.yqcomputer.com/ ;message.id=3035&view=by_date_ascending&page=1), I still have a few more questions.I am using PCI6259 and its sampling frequency should be up to 1.25MS/sec.  Yet I am sampling at only 33.33K and it seems to me already maxing out because of buffer overrun problem.  The objective I have for this VI is to continuous monitor the sensor output for up to 48 hours.  I have already trimmed down my VI to only saving data to a file.  At this time I am sampling at 33.33K Hz, continuous samples, 3333 samples but I get a buffer overrun error after 0.5 sec.(~3000 samples)  I don't mind slowing down the sampling time a bit as long as I can sampling my sensor for 48 hours.  What else should I do ?  Any advice?"Attempted to read samples that are no longer available. The requested sample was previously available, but has since been overwritten."1.5 Is there anyway I can view the entire chart using x-scroll bar?  Though I am not certain, I think there is a limit to what I can review.2.  I understand that I can do multiple input and output using this wonderful card...how should I change the input teminal configuration per channel(RSE, NRSE, differential..etc).3.  Sometimes the waveform chart will flicker and the square pulse train is changed to a slow moving DC wave then change right back...This is more frequent as it gets close to the limit of the buffer.  Any idea why it is causing this?<img src="file:///C:/DOCUME%7E1/UCLA/LOCALS%7E1/Temp/moz-screenshot-1.jpg" alt=""> I attached the VI I am working with...please advise.Thank you and I look forward to hearing your advice,CK

test final array appendix.vi:

square wave.jpg:


1)buffer overflow, 2)input terminal configuration for multiple channels, 3)waveform fluctuation

Post by altenbac » Sat, 22 Apr 2006 15:10:34

In Addition to Ryan's comments.

- You don't initialize the timestamp array, meaning it starts way oversized the second time you run the program.

- DAQmx clear task is hidden. There are many backwards wires and "birds nests". Check the LabVIEW style guide.

- After you generate the filename, you branch it for writing the header and the data. Since there is no data dependency, you have no guarantee that the header gets written before the data. THere is a reason the file io fucntion have a duplicate path output. It's to ensure sequencing.

- You should write the data using low level file I/O. Currently the "write characters to file" in the FOR loop, opens the file, writes a line and closes the file over and over. It is sufficient to open the file once, write everything, then close it.

I would recommend to write the header at the beginning, then stream the data to disk in the main while loop. There is no reason to built-up all that data in memory (1/sec for 48 hours!). If you stream to disk, the already aquired data is safe even if the computer would crash or there is a power failure. In your version you would loose it all. You could even add some code to browse (scroll) through the aquired disk data as desired, even during the run.


1)buffer overflow, 2)input terminal configuration for multiple channels, 3)waveform fluctuation

Post by altenbac » Wed, 26 Apr 2006 01:40:07

First of all, something is blowing the margins of your upper loop, and to me it looks like maybe a LabVIEW bug or corruption (?). For some reason, the label of the waveform chart is way off to the left and seemingly cannot be moved independently of its terminal for some reason. Deleting the chart and creating a new one fixes it. (that's why your upper loop contains so much hot air, it is autosizing when you move things around and e.g. trying to move the label pushes the right margin way out).
Secondly, your data is formatted and saved in an ASCII formatted text file, not binary. A binary file would be much more efficient! It would eliminate all the expensive formatting operations and would make the file MUCH smaller.
It seems foolish to artificially create all they x data and save it to file, since it is so redundant. Since the intermediary timestaps can be calculated at any time, they don't need to be saved. You can regenerate them when reading the file.
Obviously, you are relatively new to LabVIEW and there are a lot of odd constructs than can be simplfied, for example:

- After reading the data, you extract the first point from the array. Taking a lenght=1 "array subset" followed by a dynamic data conversion is not the right way. The entire thing can be replaced with a simple "index array". :)

- The lower FOR loop is autoindexing, you don't need to wire the loop count. Remember, you can resize the "index array" node to get both slices at once.

- For code readability, it is important to keep things organized. Align the DAQ thread and the file IO thread horizontally. Avoid all these wire kinks, backward wires and hidden wires.

Sorry, I don't have any DAQ installed, so I cannot test.