How to use a dynamic true/false signal with a case structure?

[rbrown83]

Hey everyone -

Is there any way to input dynamic true/false data into a case structure?  We are trying to generate a waveform, and want our case structure to execute when the waveform goes above a certain threshold value, and freeze the execution when it goes below the threshold (the false case).  However, we want the case structure to execute continuously - i.e. if the case structure for the "true" case executes while the waveform is above the threshold, we then want the case structure for "false" to execute when the waveform goes below the threshold, and so on until we stop our program.

Any suggestions would be very much appreciated!

Rachel

[RavensFan]

Show us what you have so far.

Any reason you want to use a dynamic datatype?  Is it a single value or is it a series of values at any given iteration.

What "execution" is it you want to freeze?

[rbrown83]

Currently, we are simulating 2 channels of an NI 9237 that will eventually acquire data from 2 individual load cells.  We have written a code that records the data from the two channels, and separates into several files that we need for our analysis. I have placed this code inside of the 

Ideally, we would like to input a 3rd signal into the NI 9237, in the form of a square wave signal with an amplitude of approximately 5.  Whenever the square wave goes above a certain threshold value (i.e. 3), we would like our program to continuously acquire data using the code that we have written.   Whenever the square wave goes below the threshold value, we would like the NI 9237 to stop acquiring data (this is what I meant by freezing the execution; I wasn't very clear, I'm sorry).  However, whenever the square wave goes back above the threshold, our program needs to begin acquiring data again.  This is why we think we need to use a dynamic datatype.

We are very new to LabVIEW so we're not very sure what to do. The file entitled "NI 9237 with simulated trigger" contains the case structure that we are trying to use.  The other file is the function that we have previously written, and is used as a sub VI in the case structure.

Thanks!  

[rbrown83]

Forgot to add the files, sorry. 

[tbob]

You should combine both vi's into one vi using a Producer Consumer, or Master Slave architecture.  The master or producer would be the simulated trigger vi.  The output of the compare (greater than 3) can be sent to a queue or a notifier.  In the consumer or slave loop, you have your code to do the simulation.  It would dequeue the boolean on every loop and send it to the Stop terminal of the NI9237 express vi.  This will control the starting and stopping of the 9237.

Also for your compare, convert the dynamic data to a DBL before you compare it to 3.  Then you will get a boolean output from the greater than function.  This boolean is what you write to the queue or notifier.

Here is an example of the architecture:

[rbrown83]

Thanks for your reply! We have tried applying your example of the Producer-Consumer architecture to our VI's, but it doesn't seem to be working.  We've tried several variations of the code using different combinations of while loops and different connections for adding elements to the queue, but nothing seems to be working.  We have posted our current version of code below.

We ended up removing the case structure, because the NI 9237 continued to run continuously even after the square wave values went below the threshold. However, the NI 9237 ran continuously even after we removed the case structure, so we are not sure what to try next.  Another problem seems to be that the stop input in the NI 9237 DAQ doesn't seem to be accepting true or false values from the queue; we tried to test this in a smaller program, and we had the same problem.  

Any suggestions as to why this is not working would be appreciated!  Thanks!

[RavensFan]

The inner while loop down bottom containing your DAQ assistant will never stop.  You told it to stop the while loop based on the Stopped? output of the DAQ assistant.  Because you've set it for Continuous Samples, it will never stop.

The outer while loop at the bottom will never iterate again.  And the queue will just fill up with more elements.

Why do you have the Stop LabVIEW function up top.  Whenever that runs, it will effectively stop LabVIEW cold just like hitting the abort button.

Message Edited by Ravens Fan on 06-17-2010 05:11 PM

[tbob · Accepted solution]

Remove the loop around your DAQ Assistant express vi (I hate express VIs).  There is already a big loop around the whole code at the bottom.  As Ravens Fan pointed out, don't set it to continuous acquistion.  Set a finite number of acquisitions.  Then the rest of the code can execute and the loop can iterate again.

Get rid of the Stop sign at the top.  When the code is done, Labview will stop on its own.

You have two stop buttons.  Only one is needed.  Look at my example posted a couple of posts back.  One stop button with local variables.

Shrink your block diagram.  It takes more than one monitor of space.  Its hard to read when you have to scroll all over the place.

[rbrown83]

Thank-you for your suggestions - we have tried to implement these into our program and it seems to be working better than before; we have posted our current code below (sorry for the express VI!). However, the elements that are coming off of the Dequeue function seem to be significantly lagging behind those that are being added to the queue with the Enqueue function.  As a result, the signals from our simulated DAQ channels are running for much longer than they are supposed to, and are also signficantly lagging behind the rise and fall of the simulated square wave signal. If you allow the program to run for about 30 seconds, you will see what I mean (press the stop button twice to quit the program). 

Do you know how we might be able to decrease the time between elements being added to the queue and being taken off of the queue?

Thanks,

Rachel

[Greg_J]

Hi Rachel,

---

... the elements that are coming off of the Dequeue function seem to be significantly lagging behind those that are being added to the queue with the Enqueue function.  Do you know how we might be able to decrease the time between elements being added to the queue and being taken off of the queue?

---

I am guessing that your DAQ Assistant Express VI may be throttling back the execution rate of your Dequeue loop so that the buffer will fill faster than it can be emptied.  At a glance of the functionality of your code, I am curious why you are using the Consumer/Producer architecture to transfer your boolean values rather than a local variable to trigger a more immediate on or off with your DAQ Assistant.  Could you elaborate please?

---

... (press the stop button twice to quit the program)...

---

Also, I think the reason you have to press the stop button twice is because the boolean False constant at the end of  your Enqueue loop reinitializes the STOP control to False before the local variable in the Dequeue loop has a chance to read the first True.  Try reinitializing your local variable to False only after both loops have terminated.

I hope this helps!

- Greg J