LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Help with parallel event structures (.vi attached)

Hi, I'm having a little trouble with a .vi I'm putting together. Basically, it continuously reads two digital input lines and if either of them goes high, it executes a test (in a subpanel). These tests should be able to run in parallel, so if both lines go high, both tests should both be carried out fairly simultaneously.

However, I have a problem I don't understand. The event structures don't seem to respond to the lines going high, though it appears to me that I've configured everything correctly. I've attached the .vi, hopefully someone spots something that I haven't!

Many thanks,

Chris.
 
PS. Any hints on a better way to do what I'm doing would be greatly appreciated.. My way doesn't seem particularly elegant 🙂
0 Kudos
Message 1 of 5
(2,449 Views)

Event structures are mainly designed for user interaction and don't react to programmatic changes for very good reasons.

To programmatically trigger an event, you can write to a singaling property of the control or indicator. Be aware that this will always trigger so you would need some logic so the signaling property is only written if the LED goes from Off to On, and not every 100 ms. Use a shift register and an "implies" function in the left loop for this.

You should also guarantee that the event time is shorter than the time between triggers.

  1. A lot of things can be simplified, for example your boolean logic boggles the mind e.g. you "equals TRUE" can be removed and replaced by a plain wire, right? The "equals FALSE" is just an "NOT". Since you are triggered by a value change, the old values is probably different to the new value so it would be sufficient to wire the "new Value" to the case structure. (Sure, writing to a "value signaling" property triggers the event even if the values does not change, but this can be easily prevented from occuring).
  2. The index array node in the left loop can be resized to provide two elements. No need to have two "index array" nodes.
  3. There does not seem to be a stop button, meaning you cannot properly stop the VI and e.g. close the task properly

Maybe there is a better way to do all this. What exactly are you trying to do?

Message Edited by altenbach on 03-04-2007 03:36 PM

0 Kudos
Message 2 of 5
(2,444 Views)

Hi Altenbach, thanks for your reply - I've made the changes you suggested and it does seem much cleaner (and smarter :).

Basically, this program will be part of a test jig to test 2 circuits independently. A circuits is plugged in, a physical button is pressed, and the test commences on that circuit. Later on, while the first test is going, a second circuit could be plugged in, a second physical button could be pressed, and another test is carried out on the second circuit.

The operator of the jig won't be interacting with labview directly - the only input will be this physical button, which is pressed and sends a 2-second high signal to the DAQ card. So, I'm trying to write this TestFP.vi to 'poll' the DAQ card inputs (100ms is probably too often, could be 500ms or 1.9s just as easily), and then when one of the buttons is pressed, and the DAQ input goes high, it will run the appropriate test program. While this program is running, button presses should have no effect, but once the test has finished, you can replace the circuit on the test jig, press the button, and the test will start up again on the new circuit.

I started using the event structure because of the ValueChange and Oldval/Newval properties. It seemed to me to be a little more difficult to use just a case structure or something similar to make this process: 1. check if DAQ input has gone low to high 2. as long as test program isn't running already for this circuit, start the test program.

I'd appreciate any more help you or any others can give me, thanks in advance.

0 Kudos
Message 3 of 5
(2,430 Views)
Hi Altenbach, I've made some alterations to the original .vi I posted - this seems to work for me, though if you have any idea how to make it cleaner or more elegant, I'd appreciate any input you could give me.
Download All
0 Kudos
Message 4 of 5
(2,408 Views)
Hello Chris,
 
Good program.  A few suggestions:
 
1) Your program does not contain any mechanism for terminating itself other than hitting the LabVIEW environment's "Abort" button.  This is generally not a reccommended practice.  You should have some way to terminate your program without halting it so abrubtly (like a stop button on the front panel).
 
2) In each event structure, you have logic to make sure that the event is triggered by a rising edge on your boolean variable.  This looks like something similar to an "assert" statement.  It should never be the case that this condition is false as long as the DAQ loop is executing properly.  That being the case, I would make the false case in your event structures (the "non-rising edge" case) abort the program and display an appropriate message to the user because something unexpected is happenning.
 
3) If you are feeling ambitious, I think changing your program to a more traditional (and proven) architecture like a producer/consumer architecture would do you some good.  Your DAQ loop would be the producer loop and your event loops would be consumer loops.  You could use a mechanism such as notifiers or queues to trigger the consumer loops.  If you did things this way you could totally eliminate the need for event structures (which are typically used for UI interaction).  This architecture would also eliminate the need for your "Boolean" variables which trigger the events.
 
If you are interested in this 3rd suggestion, check out the following developer zone.  It has some good information about the producer/consumer design pattern.  Also, our LabVIEW Intermediate II course goes into much more detail on this.
 
 
Regards,
Justin D
0 Kudos
Message 5 of 5
(2,387 Views)