log temperature and voltages acquired by DAQ

[nyc_(is_out_of_here)]

I have been asked to look at a VI which "locks up".

I haven't worked that much with DAQ.

The purpose of the program is to "continuously" log temperature and voltages.

The simplified VI is attached below.

It appears that the programmer is acquiring waveforms and then truncating the waveform data to one data point.

Is this the best approach?

[NIquist]

Nothing is attached...

[nyc_(is_out_of_here)]

Ooops.

I have saved in 2010 version.

[NIquist]

Meh, there's nothing particularly wrong with his VI (except the pink while loop ).  There are other ways to code it but it appears that he needs to collect multiple points for other signals in the same task so hardware limitations force the temperature task to go along for the ride.  I would have averaged the temperature points rather than chucking all but the first but again, there may be reasons he did that.

There's still a lot hidden since he must have set up his task in MAX and then copies it.  So without knowing all the details of the hardware and exactly what the application is trying to do it's hard to suggest improvements.  Does it work as you expect it to???

[crossrulz]

---

nyc wrote:

The purpose of the program is to "continuously" log temperature and voltages.

---

Then I highly recommend using the DAQmx Configure Logging.  That way you just have to read the DAQ data and DAQmx will stream the data straight to a TDMS file for you.  Makes logging as simple as possible (and a lot more efficient than using the Write To Measurement File).

[nyc_(is_out_of_here)]

---

@NIquist wrote:

Meh, there's nothing particularly wrong with his VI (except the pink while loop ).  There are other ways to code it but it appears that he needs to collect multiple points for other signals in the same task so hardware limitations force the temperature task to go along for the ride.  I would have averaged the temperature points rather than chucking all but the first but again, there may be reasons he did that.

There's still a lot hidden since he must have set up his task in MAX and then copies it.  So without knowing all the details of the hardware and exactly what the application is trying to do it's hard to suggest improvements.  Does it work as you expect it to???

---

Right. The task starts out as just reading temperature with 32 thermocouples.

The program works except for the "locking up" issue. I was hoping to see if there was something that can be done to prevent that. 

Would you explain how to do the averaging of temperature?

I believe that the original programmer is chucking all but the first so that the waveforms for the temperatures and the voltages would both contain one data point in the waveform.

---

@crossrulz wrote:

---

nyc wrote:

The purpose of the program is to "continuously" log temperature and voltages.

---

Then I highly recommend using the DAQmx Configure Logging.  That way you just have to read the DAQ data and DAQmx will stream the data straight to a TDMS file for you.  Makes logging as simple as possible (and a lot more efficient than using the Write To Measurement File).

---

I won't be doing that mainly because other people use these *.lvm datafiles and they are used to them being in a certain format.

I am wondering whether it would be better to slightly modify the VI to be more similar to the one at http://www.ni.com/example/30007/en/

[GregFreeman]

When something like this happens in a small program like this, I just start disabling things you don't really need to see if the problem goes away. Start with the logging, work backwards. You need to narrow down where it hangs.

In an unrelated note, I dug into tha write to measurement file VI to see if it opened and closed the file with every write. That is horribly written code that I can't believe NI shipped. I closed it immediately.

[NIquist]

The Mean.vi in Math > Prob & Stat palette is polymorphic so you could just replace the Waveform Subset VI with it and the wires would change to an array of floats.  That shouldn't break anything since it's converted back to the (evil) DDT form to go into the (also evil) ExpressVI for writing to file.  Give it a try and use some probes (or create a few extra indicators) to monitor the results and see if it works as expected.

EDIT:  I should have heeded your warning Greg but I looked too...  

[nyc_(is_out_of_here)]

Is it necessary to use the Basic Averaged DC-RMS VI  in this program?

It appears that this is the only VI in the program that is causing the need to have the Full vs Base license.

Management is balking at paying the extra $2000.

[NIquist]

---

@nyc_(is_out_of_here) wrote:

Is it necessary to use the Basic Averaged DC-RMS VI  in this program?

---

No of course not.  You could write your own VIs for just about anything with just the primitives included in the base version.  But just like any language, the ability to leverage the work of other great minds from the past is a great advantage.  To calculate RMS of a simple signal is trivial.  It's just the square root of the average of the squares:  http://en.wikipedia.org/wiki/Root_mean_square

Once you get to complex signals you'll need the help of someone with a bit of calculus under their belt, OR try to search for them and see if you can find something appropriate for your needs.