cDAQ based DATA ACQUISITION SYSTEM-MULTICHANNEL CONTINUOUS SAMPLES MODE

[lh666]

Will the waveform chart occur the same problem like the graph? I plan to use waveform chart to display the data. And also I plan to use multicolumn listbox to show the data and write to spreadsheet VI to save the data in the same while loop. Do you have some suggestions? Thank you so much.

Best,

lh666 

[mcduff]

Look at the Voltage - Continuous Input example that ships with LabVIEW. You can find it under Help, Find Examples, ...

You can save a copy of it and modify to your needs.

Log your data in TDMS, as in the example, and convert it later. This is the simplest and least resource intensive method available.

mcduff

[JÞB]

---

@mcduff wrote:

Look at the Voltage - Continuous Input example that ships with LabVIEW. You can find it under Help, Find Examples, ...

You can save a copy of it and modify to your needs.

Log your data in TDMS, as in the example, and convert it later. This is the simplest and least resource intensive method available.

mcduff

---

 completely agree with mcduff on this (well with Two Provisos)

1!!!) That example uses a Graph and not a chart and so it has the same unbounded memory needs I was looking to help you prevent.  I hope you trust me enough to replace that graph with a chart.  Seriously, your storing every last reading in the TDMS file anyway so you the TDMS file viewer to look at history data and use the chart on the FP to look for strange operations.

2? Lets look at this really close

This is an example of just how confusing understanding the DAQmx State transition diagram is.  

As we come into the Start Task vi the Task has just been created and properties of the Task have been set.  The Task is in the "Verified" State, assuming of course that there were no conflicting properties set that would be beyond the devices capabilities.  If the device couldn't do that that way, an error would have been thrown.

Now there are still things that could cause "Start Task" to fail:

1. The task needs a device resource that another task has currently reserved (some shared clock, ADC, DMA,) and start task fails the verified to reserved transition.
2. The device has a defect that prevents the hardware itself from "Spinning up" (Likely won't pass a self test either) and the task fails the reserved to commited transition
3. The task cannot enter the run state after committing all reserved resources.  I can just about surely guarantee you that unless you are testing FW for a new device you will never see that happen (And likely not even then since Unit Tests could have covered that type of SW Defect before it ever got to HW)

Adding a DAQmx Control Task.vi before the Start Task would get those failures found. and place the Task in the committed state prior to entering the loop.   That is somewhat important because in the example as is the transitions are "Implied" So, after the stop task vi runs the only possible thing to do is return the task to the verified state by spinning down the HW and releasing the locks on the reserved resources.  In large applications that can lead less experienced developers down an unhappy path where tasks run but sometimes don't restart.

And the transition from commited to running is enforced by the DAQmx Read.vi in every case.

[mcduff]

Jeff,

Won't be able to reply until later, need to head to little league, but can you explain why the Graphs grow and grow. I have used them in applications that run for days without ever seeing the memory change, am I missing something or did I somehow stumble on an unknown setting to me that avoids the memory problem you are referring to.

Thanks

mcduff

[JÞB]

---

@mcduff wrote:

Jeff,

Won't be able to reply until later, need to head to little league, but can you explain why the Graphs grow and grow. I have used them in applications that run for days without ever seeing the memory change, am I missing something or did I somehow stumble on an unknown setting to me that avoids the memory problem you are referring to.

Thanks

mcduff

---

My apologies and thank you for the correction.

I've seen so many instances of build array and concatenate waveform in an acquisition loop that I almost can't recognize an approriately configured graph

It would be a lot more humourous if it was not so true.

[mcduff]

No hassles, no apology needed. Just wanted to make sure I wasn't missing something obvious.

cheers,

mcduff

[lh666]

Hi,mcduff

I have tried the method, and it works longer than before. But the system was stopped for the same error(The application is not able to keep up with the hardware acquisition) after several days. The settings are as follow:rate (512 S/s);Samples per channel for clock(512*8);Samples per channel for read VI(512). There is no wait function in the while loop. Are there some wrong with my settings?  Thanks.

Have a nice day.

Best,

lh666

[mcduff]

Can you attach your vi?

Your buffer size is still really, really small, 8*512. You can always increase to 64*512, 128*512, etc.

mcduff

[lh666]

Hi,mcduff

Thank you so much. The VI is the same one that I post in the first page. Currently, I have increased the buffer size to 128*512 and see how it works. Are there any other parts that can be modified to try to improve the performance?

Thanks. Have a nice day.

Best,

lh666