Controlling Excel Data Rows (Write to Measurement File)

[Fabian391]

Hello all,

Objective:

Achieve somewhat of a live waveform from two pressure sensors, as well as calculate the differential pressure. This LabVIEW VI is meant for students for a lab module exercise, in which data will be exported into an excel file for the students to perform other calculations. Excel file should contain data from the beginning all the way to the end of a run. 

Problem:

Pressure sensors run well, waveform chart runs well, but when you stop collecting data, the amount of rows in the outputted Excel file will reflect the number of samples per channel of the DAQmx Read block (10= 10 rows of data, 100= 100 rows, so forth).

I would appreciate some guidance as to how to achieve data collection in that spreadsheet portion from Start to Finish, without it affecting the aesthetic experience for the student (by this I mean number of sample channels >10 will cause certain lag in the waveform, choppy). I attempted to solve that issue with something along the lines of  Tank1Solution.png with no success. I have included  a picture of the original block diagram (Tank2Block.png) and well as the VI file I've worked on.  Once again, any help would be very much appreciated, I am not well versed in LabVIEW and I'm not sure how to tackle this efficiently.

[mikeporter]

The issue is dataflow. You are not saving all your data. You are only saving the last block of data that you acquired in the middle while loop.

It would be helpful if you went through the tutorials. Your code has several issues. A loop that is doing nothing, a sequence structure that is unnecessary, two express VIs...

Mike...

[Bob_Schor]

The first thing I checked was the LabVIEW version you are using -- it is LabVIEW 2013, one version before NI started bundling the Report Generation Toolkit with basic LabVIEW.

It looks like your Sampling Loop is running at 100 Hz, and you seem to be sampling 10 samples at a time -- do you intend to write 10 rows of Excel ten times a second?  Are you intending to save all of the data?  Do you want to save it "on the fly" or accumulate it all in memory and save as one big 2D array?

If you are going to save "on the fly", you need to do the saving as the data come in.  This either means put the File I/O inside your sampling loop (not a good idea, as it can mess with the timing) or use something like the Producer/Consumer Design Pattern (to learn about this, create a Demo for yourself by going File, New ..., From Template, Framework, Producer/Consumer Design Pattern (data) -- I may have missed a step there, but if you do this, NI will generate a Producer/Consumer template for you that shows how this works).  If you are going to save "all at once", then you need to accumulate all of your data in an Indexing Array Tunnel leaving your While Loop.

If you had the Report Generation Toolkit, I think it would be possible to write Excel "on the fly" using code not unlike your Acquisition Loop.  You'd start (before the Loop) by opening the Excel Report, you'd write a "Table" inside the Loop using the 

data from the Acquisition (10 rows of N channels), then when the Loop exited, you save the Report under some Excel Filename.  I think Excel would be able to keep up with 100 rows/second, though I haven't timed it (hmm, maybe I have, need to look at my earlier Forum posts).

Bob Schor

[JÞB · Accepted solution]

Some guys are always doing things the hard way 

Of course you need a wires from ai0-ai2 and ai1-ai9.  That DAQmx Linear Scale sure comes in handy! and hey, TDMS files import very nicely into Excel! the addon is right there so why not just log the data?  TDMS is much more portable than xlsx.

A few addtional comments. a) you cannot stop that vi before you press Go- that needs a fix. b)Create Scale is probably going to return an error as is since the name is illegal. I named it that to show the source of the scale and offset values.

[Fabian391]

First of all:

Mike, Bob and Jeff, thank you for your patience and advice, I have been cleaning up the code and playing around with it. There definitely are some neat features provided in the later versions of LabVIEW, but unfortunately only the 2013 software version is available in the computer lab. 

Jeff, I'm trying to convert the incoming Voltage into the units of mmHg (which to my understanding, the unit is not available in LabVIEW). When creating the scale for the unit conversion, I am running into a certain issue when the signal reaches the DAQmx Channels. Penny for your thoughts?

Unit Error:  

"Units for the channel must be set to From Custom Scale when a custom scale is used with a channel."

RSE Constant Error:

"Requested value is not a supported value for this property"

I have included an image of the block diagram as well as the VI file.  

Side comment:

I corrected the y=mx+b [Fixed the equation to: y= (285/4)*(x-0.5)] values after carrying the 285/4 across. Slope and y-intercept have changed (71.25 and 35.63, respectively). Out of curiosity, is the ai2 channel supposed to represent both previous signals(ai0,ai1) to be later differentiated? Thanks!

[JÞB]

---

@Fabian391 wrote:

Unit Error:  

"Units for the channel must be set to From Custom Scale when a custom scale is used with a channel."

RSE Constant Error:

"Requested value is not a supported value for this property"

Side comment:

I corrected the y=mx+b [Fixed the equation to: y= (285/4)*(x-0.5)] values after carrying the 285/4 across. Slope and y-intercept have changed (71.25 and 35.63, respectively). Out of curiosity, is the ai2 channel supposed to represent both previous signals(ai0,ai1) to be later differentiated? Thanks!

---

Unit Error: The DAQmxCreate Virtual Channel.vi has a units input just above error in it is an enum<Volts | From Custom Scale> the default is Volts so, just right- click the units terminal and create a constant select "From Custom Scale"(or any I32 with 10065 value)

RSE Constant Error: Try "Default" Not knowing the device I couldn't know supported modes

Side comment: Differential measurements require an ai+ and an ai- input.  All modern NI DAQ devices internally pair the +&- channels ai0-7 are ai+0-7 and ai8-15 are ai-0-7  so ai2 is the positive and ai9 the negative for 1 differential channel.  you can't use the same challel twice so, we need to jumper ai0-ai2 and ai1-ai-2(ai9)  differential channels are defined by the + side so "myDAQ/ai2" is the right way to go.

OTHER issues:

• you may need to scale the diff channel too
• input Ranges are in scaled units you may need to wire something there (Top left and center inputs to DAQmxCreate Virtual Channel.vi)
• Where do I send the invoice for $0.01?

[Fabian391]

Once again Jeff, thank you very much for your suggestions. Everything seems to be working good so far!

The tiny pressure sensor's operating range is from 0 to 258mmHg (0 to 5 psi). As a final update to this block diagram, I am interested in adding a bulb (flashing bulb warning near the waveform chart) or warning message to indicate to the user that the device is operating outside of recommended parameters (should conditions result in pressures higher than 5psi). How could I incorporate this into the current design? Thanks!

[JÞB]

---

@Fabian391 wrote:

Once again Jeff, thank you very much for your suggestions. Everything seems to be working good so far!

The tiny pressure sensor's operating range is from 0 to 258mmHg (0 to 5 psi). As a final update to this block diagram, I am interested in adding a bulb (flashing bulb warning near the waveform chart) or warning message to indicate to the user that the device is operating outside of recommended parameters (should conditions result in pressures higher than 5psi). How could I incorporate this into the current design? Thanks!

---

Glad to here its going well.

IF your Sensor is 0-258mmHg you need to set the limit below 258mmHg since the sensor really is "Railed" or you need a sensor with more range.  The warning is generated the same way in any case.  Simply stick a "Waveform Scalar Limit Comparison.vi" in there on the data in a loop over each channel

[Bob_Schor]

Notice that you have a loop that is "clocked" by the DAQmx Read -- you appear to be reading 10 points at 100 Hz, so this loop should cycle every 0.1 sec (100 msec).

Generally, if you have a clocked loop such as this, you don't want to "overload" it with additional processing tasks that can impede the input of data.  The Producer/Consumer Design Pattern provides you a way to "export" incoming data from a "Producer Loop" (like your DAQmx Loop) where the data is "Produced" and send it to a "Consumer Loop" that can process it, taking its own sweet time.

A good way to learn about this is to create one using the Templates that ship with LabVIEW.  Open a New VI by going to the File Menu, choose "New ..." (the dots are important), and look for From Template, Frameworks, Design Patterns, Producer/Consumer Design Pattern (Data).  Let it create this for you, then study it.  Note in particular that you create a Queue into which you put a copy of the DAQmx data as it comes in, send it through the Queue to the Consumer, where you do what you need.

In your case, your Consumer just looks at the Data and if it sees values in a certain range, does something.  What you do is up to you.  However, to get a Blinking Indicator, you can simply change the Properties of a String (or Boolean) Indicator, located at a strategic place, from "Invisible" to "Visible" and "Blinking" (so you, yourself, don't have to make it Blink).

Bob Schor

[Fabian391]

Hello Jeff,

For some reason, once the data reaches 113.44 mmHg (Y-scale), it caps (see FrontPanel pic). Any thoughts as to why it might be capping at this value? I've tried tampering with auto-scaling options but with little success.  The sensors should operate up to 258mmHg (~5psi). I've attached the code along with front panel and block diagram pictures.

Thanks!