Changing from finite to continuous samples and vice versa?

[jeanlucpicard]

Hello,

I have a problem which I'm trying to overcome: I have a measurement system consisting of an analog output and reading two analog inputs. I would like to run it continiously to monitor the current values (without saving the previous data), however, when I click something like a record button, I'd like to start a recording of a predefined period (like a finite samples measurement) and then restarting the monitoring without saving again.

Currently my measurement program is based on the examples "Continuous AO" and AI vis, and are made with continuous sample mode and while loops. How can I insert a record button?

I tried putting event handlers in the measurement loop, however it suspended the loop from running.

I attach a screenshot of my current measurement loop. (With the shift register I tried to read data, however I cannot get it out of the loop, until the loop is stopped)

Thank you in advance

[ogk.nz]

You shouldn't have to have a change in the recording method at all, you shuold just be able to extract the information that you want to store so that while the button is switched on or for a certain period the information that is going to the monitor is also being recorded. The simplest way would simply be to have a case structure inside of your monitoring loop that when a button is pressed records the information to an array which is then passed to a spreadsheet record or csv write when the button changes state again.

If you could present a copy of your vi then it shuld be pretty straight forward to see how it can be done.

[jeanlucpicard]

Thank you for your help, I attach the files needed. The MeasurementNI6211SR is the one that runs with the other vis being responsible for signal generation. The sgn file has to be loaded on the front panel.

So I plan to be able to start a measurement with the ability to restart a measurement before finishing saving (in case of something goes wrong) by clicking on the button again for example or by another button.

However, when I finish saving the measurement loop can be paused or something to display the data for quality checking (and some further processing).

I tried event handlers but they did not work the way I planned. (probably because it halted the loop in each iteration, while I insist on acquiring the points one by one for a continuous display.

[jeanlucpicard]

In the meanwhile I managed to make it work in a way more-or-less I want: I initiate a lossy-queue with a queue size to be as long as my measurement. When I click record I use another loop to first flush the queue and then save the data for a given length and then leave the queue to overwrite itself.

My main concern now is the recording button: I click the button and it starts saving the data. However if I click it again before it finishes it remembers, how many times I clicked and then does it in the end as many times. 

How can I make it to operate in a way to start recording but if I click record again it restarts saving immediately? (I attach an image of my loop writing the data from the queue)

[Zody]

Hi,

Why don't you enqueue the data only when you want to record them?

In this case you could simply monitor the status of the button and see if it was pressed or not. In this case I suggest to look up for the mechanical actions available in LabVIEW. https://decibel.ni.com/content/docs/DOC-32971

Or you could have a produce consumer architecture where the producer will generate events (button clicked etc). 

This while loop will contain an event structure.

In the consumer side you will acquire data but also monitor the events that are being generated from the producer. Whenever you receive a message that the button was pressed you could enqueue the data and a third loop will dequeue it and save it to a file. This way you will separate GUI from acquisition but also from the actually process of saving the data.

Best regards,

IR

[jeanlucpicard]

So you mean to have a while loop with an event handler linked to the record button containing only the queue initializer? then having the enqueue in the measurement loop and the de-queue in another loop but with no event handlers?

This way can I instantly restart recording when I click the button? (Because now I have to wait for the recording to finish, or if I click before, it starts a new recording after the current one finished)

I suppose, I should choose a latching button, probably latch when released.

[Zody]

Hi,

I am attaching a drawing that represents my idea of three threads.

Basically you will have to use two queues: One for sending data from GUI thread to DAQ thread and the second one that will send messages from DAQ thread to Log thread.

This architecture is flexible enough so that will allow you to reconfigure the device or any other messages from GUI thread.

Best regards,
IR

[jeanlucpicard]

I have tried adopting something similar, however it doesn't work the way it should. (Or at least the way I think it should) Could you please help me ironing it out? I've seen some vis on the internet with queue-controlled (but only one-way) and tried adopting them.

The MainProgram vi is the app, with some settings (now limited to a signal file selection and channel settings). Then the data acquisition can be started by clicking the Start Acq button.

And here come my problems: first sometimes the queue starts, sometimes it doesn't (or at least it doesn't start the data acquisition). And the main point: I set the sample rate, yet it is acquired at a much-much slower rate (my signal has a period time of 4 seconds, yet it needs at least 20 seconds to get near finishing). And the strangest: sometimes, mostly after some time (about 1-2 min) it hangs and does nothing with the daq (yet labview seems responsive, just my program hangs somewhere).

So now only the controlled acquisition is in the problem and first I don't care about forwarding the data for analysis and saving. (That seems to be the smaller problem).

What am I doing wrong? Thanks for your help. 

I attach all the files.  (MainProgram is the app itself, MY.SIGNAL is the signal file I want to output.) I use a USB-6211 device. (at work a physical one, at home a simulated one).