Help with Errors in our Design...Error -200279 from my DAQmx Read VI

[Kuhlhaas]

Hello all,

I am a senior Mechanical engineer at the University of Akron working on my senior project.  As a group we are trying to build a VI that will record temperature and heat flux off of a Lithium Ion battery.  Together we have about 2 months of experience using Labview and have exhausted most of our resources here on campus.  We are using 7 heat flux sensors with attached thermocouples as well as 2 other thermocouples wired through a Nitb 9214 (16-Channel Isothermal Thermocouple Input Module) then into a NI cDaQ-9171 usb into our computer.  We have built the attached VI system to display the temperature readouts and heat flux for all sensors during charging.  We are trying to have a full display graph of both heat flux and temperature from the start of the run, to completion.  This could be recording for up to 2 hours.  The data must also be written to excel. We are running continuous reading with 1 sample every second.  The issues we are running into are

1) The error message in the title as well as on the attached page.  This cause a jump in the data and ruins the results being gathered.  Usually occurs 40 minutes into our recording. 

2) There is a significant amount of noise in the heat flux readings and the record indicate it is not sampling a the rate we desire.

After reading many of the posts here we have come to the conclusion that we could use some serious help.  Any direction will be greatly appreciated

[JÞB]

You should be using DAQmx Read nCH 1 Sample (on demand) for such slow data rates.  you are reading fewer samples than are being buffered and evetually the old unread data gets overwritten.

You are also grossly abusing the Dynamic Data type.  Yor DAQ Assistant is set to read i sample for each channel so why are you converting each scalar point to arrays of 1 element?

[Kuhlhaas]

We called in to NI and were advised to do this so that the results would show up on the graph from the start of the run to completion rather than only showing the data for the sample period. We were told this could only be done by converting to an array?

[JÞB]

You were misinformed or miss-heard.  the only thing necessary is to have a long enough chart history length.

Lets stop some of the insanity of splitting and remerging the signals just to get the original array.

[Bob_Schor]

As I told some senior BME students who wanted to use LabVIEW for their Senior Design Project, "Find yourself a LabVIEW Guru and apprentice yourself for a few days" (I added "... and if you can't find one, I volunteer", but Akron is a few states over ...).  Here are some suggestions.

• Never (what, never? well, hardly ever ...) use Express VIs, particularly not the DAQ Assistant!  Read this and code your acquisition directly.
• Do not use Dynamic Whatever-they-are.  Output your data as simple arrays (1D or 2D, depending on how you are sampling).
• Simplify your plots.  If you look at the Help for Charts, you can see how to plot 9 channels a point-at-a-time and have it scroll across the screen.
• Think "Data Flow".  Your acquisition task has a Beginning (setting up your device), Middle (taking data), and End (cleaning up after yourself).  The Beginning and End you do once, the Middle is a (While) loop.
• Think "Data Flow allows Parallel Processing".  This might not apply in your case, but you have an Input process (collecting data), a "Visualize" process (producing a nice display), and an Output process (which you call Writing to Excel, but you wimp out by using Write to Spreadsheet, which has very little to do with Excel).  These have inherently different rates and "importance" -- you never want to miss acquiring data points, but if you don't "see" all the points flying by, or if disk I/O is variable in speed (opening a file takes more time, usually, then writing it), you may want to have independent loops running at their own speed for each of these tasks.  LabVIEW makes this easy.
• If you do want to write your data to Excel, use the Report Generation Toolkit and its Excel functions.  I rewrote one of the NI Excel Examples and posted it on this forum about a year ago -- I think if you type the word "Revised" in the Search function and pause, its the first thing that pops up).

Are there truly no faculty or graduate students using LabVIEW at the University of Akron?  [I should send a note to my friend, Dr. Karen Mudry, who was Akron's first chair of BME about this ...]

Bob Schor

[Kuhlhaas]

In this setup both displays seem to be showing the seperate nodes as indepent points on a single line graph.  We were trying to acheive a seperate line for each densor showing every reading. Or in other words all 7 temperatures on one graph and all 7 heat flux on the other graph.   This is the reason we had split them.

[Kuhlhaas]

Thanks for the Reply Bob,

In the brief experience we had with Labveiw a Daq Assist was always used.  That is why we have used it as a starting point. 

I was actually reading the link you have provided earlier today to try and understand the Daq read function.

We are searching for the answer to our chart problems within the help feature and still seem to be coming up with one line displaying each sensor as a single point for hat reading.

Once we can get the "Data Flow" portion cleaned up i will look into your post so we can fix the data gathering issues.

As for faculty here, I have reached out to many professors, graduate and undergraduate assistants for direction and have been directed to contact NI. Not saying a Guru doesn't exist, just not in my direct communications. We have been on the phone with NI a couple times now but usually ends with them going over our hardware and then e-mailing in the existing VI

[Bob_Schor]

Maybe you said, but what are you using to acquire the data?  I did a lab session where we used an NI USB-6009 (an inexpensive multi-function device) to construct a Touch Sensor out of a 1MOhm resistor.  We were sampling at 1KHz and analyzing each second of data for noise -- if it was noisy, someone was touching the resistor.  [Oops -- you did say, I'd just forgotten ...]

In your case, you are sampling at a much lower rate.  Each second, you get a point from multiple channels.  I haven't looked closely at how your device interfaces with your sensors, but you should be able to set it up to take a single sample "on demand" from all of your channels.  You can then put this inside a While loop with a "Wait until next multiple ms" delay of 1000 msec to take a sample per second.

Now, in a "real-world" application, you would use a Producer/Consumer model and export each point from the Producer loop to a Consumer loop (using a Queue).  However, since your Producer is so slow, you can probably just put the Chart right inside the same loop, wiring the N channels, 1 point, form of input and see your data slowly scroll across the face of the chart.

Have you played with MAX?  If you are having problems acquiring data and understanding the various acquisition options and settings, MAX is a great way to start.  Simply fire up MAX, connect your device and sensors, and run some Test Panels with the settings you plan to use.  You should be able to test the difference between On Demand, Single Sample, Continuous, etc. (I'm forgetting the terms MAX and NI use for these options, but if you try it out, it should be relatively intuitive).

Bob Schor