Re : Export Waveforms to Spreadsheet file not reading file path

[NicolasK]

I am writing temperature data into a queue at 100 s/s and 2000Hz from a thermoucouple. I wish to log this data (1 sample in this example, so 50ms of data) when the Log Data pushbutton is pressed, and have a different csv file per test point. 

1) I start the program 

2) I point the file path to test_a.csv and record one sample. It records it in test_a.csv as expected (as shown in new file path indicator).

3) I now point the file path to test_b.csv and record another sample. Instead of logging the data in test_b.csv, it logs it again in test_a.csv.

4) I hit Log Data again, and only now does it actually record the test point in test_b.csv. 

How could I fix this problem?

I attached a simple VI that you should be able to use fairly easily to reproduce the problem I am encountering. 

Thanks in advance

[LandJBelenky]

This is definitely much more complicated than it needs to be.  I'm pretty sure you don't need the queue stuff, and I very much doubt that you want two separate loops.

I'm not quite sure this is going to do what you want, but I think the form is correct and this is a good starting point to build from.

Let me know if we're getting close.

[ben64]

In this case the issue is dataflow. The value of the path control is read before it is changed and the loop wait for data to be dequeued. A simple fix is to put a flat sequence around the path control and write to spreadsheet function.

Ben64

[ben64]

Here is a more standard way:

The error case is empty. When the queue is released the Dequeue Element vi throws an error and the consumer loop is stopped. You don't need a stop local variable and you can set the stop button mechanical action to  Latch When Released. This way the stop button is automatically reset when read.

Ben64

[LandJBelenky]

Ben,

Good fix, for the way the program currently stands.  

In your opinion, is this a good time to be using a queue? In twenty years, I've almost never used one, and would encourage others to avoid them as much as possible. They are, of course, appropriate some times, but I'm not seeing anything here that makes me think this would be a good time to use one. 

[Bob_Schor]

Let me summarize what I think you are trying to do.  My understanding might be wrong, but you can fix that up.

You are doing continuous sampling at 2KHz, and are taking 100 samples at a time (and doing something useful with them).  Periodically, you want to push a "Log Me" button and save the current sample set (I'm going to assume you want the current set of 100 samples) saved in a file that auto-increments each time you push the "Log Me" button.  In addition, you want this to run with minimal "interference" from the on-going logging.  And you don't want to use those nasty queues (I don't quite understand your aversion, but so be it).

So what is the time-critical element here?  Pushing the Log Me button.  At that time, you want to (a) define your file name, (b) have the data "in hand", and (c) write the file.  Let's solve (b) first (without using Queues).

Do you know about VIGs (Virtual Instrument Globals, also called FGV, or Functional Global Variable)?  This is a "Memory Element".  I'm not going to insult your intelligence by telling you about them -- in 20 years of LabVIEW, you've surely encountered them.  As your sample comes in, store it in a VIG.  This takes almost no time, and now you can access the "latest data" whenever you need it.

So create an Event Loop.  Make the Log Me button a Latch When Released control, and create a Value Changed? Event for it.  What do you do when the button is pressed?  Why, you get the data from the VIG and write it to your Waveform to Spreadsheet Express VI (ugh -- I hate Express VIs).  But you use a trick -- since you are running LabVIEW 2016, you pass the File Name through the Create File with Incrementing Suffix VI before wiring the Path into the Express VI.  Now, this actually creates a File first, so you just Close the File and use the (now unique) File Name.

Alternatively, if you want to "roll your own", you can put the intended File Name in a Shift Register of the While Loop surrounding the Event Structure.  Use the File Name, do some simple String Manipulation to change it as you desire (i.e. "Log Me A.log" becomes "Log Me B.log"), load the new name into the out-going Shift Register, and you are ready for the next round.

The important thing is that the File Name definition needs to be in proximity to the File usage.  Using both in an Event Loop keeps it also in (temporal) proximity with the Button Press.

Bob Schor

[NicolasK]

Thank you for your answers. I believe a little clarification is in order concerning my usage of queues. 

The reason for using queues here is that the VI I posted here is part of a larger VI for gathering data from different sensors, with different rates, but saving all of them in the same file, with a common time. Queues have been recommended to me in that case (Themocouple (2000Hz), Load cells (2000Hz), three axis accelerometer (2048 Hz), Optical RPM sensor (frequency counter), RS485 TX and RX (50ms) and CAN TX and RX (10ms)).

I only posted a subset of this larger VI here to understand the problem with the data logging, and that "lag" in the reading of the file path.

[LandJBelenky]

That seems like a reasonable scenario in which to use a queue.