How to continuously read data and save a portion based on a triggered event?

[coolhandLV7]

I am monitoring Pyrometers, where i'd like to display the readings at all times for the users, however when a triggered event, such as the temperature reaching a predetermined set point, i'd like to save that data until the temperature returns below that same set point.

Attached the VI, saving the data seems to slow it down and ultimately cause it to error out.  I'm not sure what the best approach is so i was hoping for some ideas or to learn from someone who knows better.

[ogk.nz]

Well first things first, you are probably going to want to have some sort of conversion on the way that you are setting the timing on your wait. At the moment any frequency greater than 1 is going to have a reciprocal that will be less then 1 and effectively rounded to 0 when it is converted to a U32 at the wait function.

You aren't having any issues with it at the moment due to the fact that you introducing another wait at the reading from the DAQ that happens to be how long it takes you to read your samples.

Next is, why are you using a boolean to control whether or not your DAQ is running? This would seem to indicate that you are using the 'Run Continuously' button which is generally advised against except in certain debug cases.

Onto the crux of the matter, The reason everything is slowing down is due to the fact is that you are attempting to open, write to then close your file 1000x per second. You might see why this could cause things to slow down.

In order to avoid this you can use some boolean logic and some shift registers track the recording state and the reference for the opened file.

To figure the state of your recording when comparing the state of the recording value:

FALSE -> TRUE: Create logging file, add headers and first value

TRUE -> TRUE: Log data to already opened file

TRUE -> FALSE: Log last item and close file

FALSE -> FALSE: Do nothing

And lastly, the easiest part of this whole thing is triggering on a value being greater then a preset, all you need to do is figure which value you want to check and against what, pass the boolean result to your case structure instead of the boolean control you are using at the moment.

[RTSLVU]

Building on what pgk.nz said you really need to rethink your approach and use a proper program architecture like a simple state machine.

Then programming the tasks you require will be a lot easier. 

[crossrulz]

And whenever logging is involved with a timed process (such as a DAQ), you really should learn the Producer/Consumer architecture.

[coolhandLV7]

Thank you for the responses, I was using the run continuously button to enable the user to start and stop the data collection as they see fit.  I realize i'm not a top notch programmer yet, so i have some questions...

I don't understand the timing issue that was pointed out, it's a DBL and i set it up to enable the loop and the DAQ to execute at the same time.  I don't have any wait functions in there.  Can you explain this in the next level of detail?  I'm not sure what i'm missing but i want to learn.

Also do you have a simple example code you could point me too or share with me that would help me understand the state machine setup?

Thanks for the help...

[Davidvilla87]

There is an exampl of the state machine in the LabVIEW examples:

[JÞB]

Just to help out with some areas that you are missing

Spoiler

I almost said there are soooooo many things wrong on that BD the OP may be hopeless then you reported a strong desire to learn

• What is wrong with a DAQmx Scale?  you should have Temperature reported directly by applying the scale.  right-click on this BDand the fourth selection from the bottom is New NI-DAQmx Task> play with those options.  Launch the DAQ Config Wizard and really try out scales, ranges, sample modes, timing, triggering (Oh lots of triggering) and even run the task using that wizard until you see something you like.  Save the task and close the wizard
• The BD should look like this
• Right-click it again and the previously greyed out option "Generate code>" shows up.  Play with those options  how does the generated code differ from your code?
• Edit the task again- rinse and repeat.

That experiment will teach you more about DAQmx than a very high percentage of LabVIEW coders know.  (#WorkingOnIt)

[AnVajpeyi]

Hi 'coolhandLV7'

The solution is for you, if I have understood your issue.

I generate a sine signal and create event with a boolean input, during which the amplitude rises by 2

I have a pre-event and post-event recording of nearly 5 seconds.

Hope this works.

best of luck

[coolhandLV7]

Thanks for the responses, i have updated the code to a produce/consume process.  I've attached the code, i have tested this out with random numbers generators to generically test the function, i hope to test it on the actual Pyrometers today.  Anyway have a look and let me know what you think.

Jeff, thanks for the info, i had know idea there was that level of functionality.  I'll try it out the scaling today.

AnVajpeyi, thank you for the code, however your version is newer than my 2011 so i can't see it...

Let me know what you think of the attached .vi, this is a good learning opportunity for me.

[ogk.nz]

I'm impressed, it looks like it would be much nicer to work with the newer version as well.

Just one little thing, the point of a producer consumer is that there should be as little in the producer loop to slow down the generation of the data as possible, while at this stage it seems like there is not going to be any issues, if you get to more arduous processing consider moving the "LumaSense_ScaledOut4" subvi into the consumer loop.