How to implement boolean comparison and event structure?

[gBlaskov]

Hello all,

I'm currently developing an undergraduate lab in which a laptop sends out a voltage via USB-6008 to a circuit board with an op-amp, the voltage is amplified, and then sent back into the laptop. The student is going to have to determine an "unknown" voltage which will run in the background (they can do this by a step test, graph V_in vs V_out and extrapolate to the x-axis).

Currently, I have two loops that are independent in my VI. The first loop is used to "Set the zero." When 0 voltage (V_in) is sent out of the laptop it returns a value around -1.40V (V_out) typically. Thus, I created the first loop to average this value. The second loop, averages the V_out values that come into the laptop as the V_in numeric control changes. Then I take the "set zero" value from the first loop and subtract it from the second loop average to get as close to 0V for V_out when V_in is 0V.

The problem I'm facing is, the event structure waits for the V_in numeric control value change, but after "SET ZERO" is pressed, if there is an unknown value, it will not be added to the average for V_out until V_in is changed by the user. So, I tried implementing a comparison algorithm in the "[0] Timeout Case." This algorithm works for step tests with positive values for V_in, but there are two problems.

1) Negative values cannot be used for V_in

2) If a user uses increasing positive values for V_in there is no trouble, but if they try to go back to 0, the value change event has been called and it is added to V_out as well as the timeout case.

Sorry for the extremely long post, but I've been banging my head over this and can't figure out how to properly implement this. I'm using LabVIEW 8.0.

[RavensFan]

1.  Make sure you name all of your controls.  You can make the label invisible on the front panel.  Right now you have two boolean buttons with events assigned to them, but you because you didn't name the controls, you have no meaningful name showing up in the event structure.

2.  You have a bad architecture with two while loops, one dependent on the other, and event structures in each.  You can lock up your code hard because you have the events set to lock the front panel until they are handled.  If you are stuck in the first while loop, you can't get to the second while to handle any events there.

Read the Caveats and Recommendations when Using Events in LabVIEW.

Is there a reason why you have two while loops and two event structures?  Until you clean that up, any of your other problems won't be solveable.

[JÞB]

OK you have bigger problems than Raven's Fan is pointing out.

When the first event loop stops ( after pressing "") (the boolean text is "Set Zero")  The second loop may start- (AND PROCESSES all of the events it was registered to process before the loop started!)  that would enclude the value change event from "" (The boolean text is Stop) Being pressed bebore the loop started.  Of course, since the labels of "Set Zero" and Stop are identical nulls....................................................BOTH event trigger at the same time and are processed as soon as the event loop they are registerd to is available.

Get it ... The two buttons labeled "" both queue Value change events to both loops registered to act on the value change of the control labled ""!

Both loops will do what you programmed in the case of "" Value Change!  This can, (as you have observered) lead to confusing code actions.

Do avoid controls with duplicate labels (There is a VI Analizer test for that!)  Do avoid multiple event structures in the same hierarchy. 

DO NOT bring this to your studients to help you learn LabVIEW!  We get enough studii asking embarassing questions

VI Analizer will help you provide sound templates.  If you need help with that hit my sig line- e-mail me and I'll always be willing to help.

[RavensFan]

---

@JÞB wrote:

Both loops will do what you programmed in the case of "" Value Change!  This can, (as you have observered) lead to confusing code actions.

---

I'm pretty sure LabVIEW knows which of the identically labeled blank name "" matches with each event structure.

The problem with identical labels, or not labelled, controls, is not that LabVIEW gets confused, it is that the programmer doesn't know which event case matches with which control.

[johnsold]

I think Ravens Fan is correct. If you Edit Events Handled by This Case on both event structures, one points to a control marked "#2" and one to "#8" in the list of controls.  It appears that they do not both link to the same control.  All other comments are valid and important.

Lynn

[BowenM]

RavensFan IS correct. I decided to test it for my own curiosity.

Edit: Had an embarrasing mistake in the VI...

[JÞB]

---

@BowenM wrote:

RavensFan IS correct. I decided to test it for my own curiosity.

Edit: Had an embarrasing mistake in the VI...

---

---

Well I learned something!  Thanks! 

Still - duplicate controlls with the same labels confuse something---- even if it is me.   Don't do it!

[gBlaskov]

Thanks everyone for the feedback. I guess I should have mentioned I'm also a student learning LabVIEW...the point of this is not for the students to learn LabVIEW from my VI because it's an analytical chem lab; it's more about the op-amps.

@RavensFan I don't want the user to be able to get to the second while loop until they have gone through the first because the "zero" needs to be set.

@Jeff I haven't used or heard of VI analyzer before, so I'm not sure how that works

My instructor essentially told me as long as it works it's fine... I only have 2 weeks of class left, so I don't have much time to try and fix everything. If there is one thing that really needs to be fixed (especially since another student might end up finishing this) what would that be?

Regards,

Graeme

[RavensFan]

Well, you can't have any event in the 2nd event structure be able to lock the front panel, because if you haven't done what  you've needed to in order to stop the first while loop, your VI will be locked up with no way to ever interact with it.

A proper state machine would allow you to handle everything in one loop and not allow the "states" or actions that are happening in the 2nd while loop to happen until you've satisfied the appropriate conditions.

[johnsold]

I agree with Ravens Fan that a state machine architecture is the proper way to handle this. Anything you try to do with the existing two loop structure will continue to have problems. 

I am not sure what examples or Design Patterns (if any) were available in LV 8.0, but search for state machine examples and Producer/Consumer (Events).  Those existed in LV 8.2.

Lynn