LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to decide when an a "wait for event action" is activated

Hi,

 

In the attched example file (which is a part of my program)I have 3 basic stages, enclosed in a sequence structure:
1) I initialize the GUI buttons
2) I check the instruments in my system are opened and ready to run ("VSWR initialize vi")and issue a true/false result.
3) A case structure for normal run or abort operation (if the instruments do not
respond correctly).
4) If everything is ok the user has to scan a S/N using a bar code scanner.

 

The problem is that when I run the program the EVENT STRUCTURE in the FALSE part of the case is automatically activated, before the VSWR initialize vi is started! 
This causes that when the user tries to scan the serial number on the GUI he can only type one character and then the screen is stuck.
If I disable the result from the VSWR initialize vi (as shown on the example) and connect a TRUE constant to the case structure, the event structure is not activated but then of course I can not use the "VSWR initialize vi".

 

How can I make sure the event structure is activated only after the two first parts are done? That is, in normal order - only after the "VSWR initialize vi" returns a false result.

Note, there's no need to understand each component in the attached file. The question is rather a general one about the right way to synchronize my program.

 

Can anyone help ?

Thank you in advance.

 

0 Kudos
Message 1 of 5
(2,966 Views)

Mentos wrote:

 

The problem is that when I run the program the EVENT STRUCTURE in the FALSE part of the case is automatically activated, before the VSWR initialize vi is started!


This can't happen because of dataflow. I don't know what your Initialize is doing since you did not include it.

 

General comment: you should restructure your code. You should look into using a state machine construction, or better yet, a producer-consumer architecture. You will be far better off. 

 

Also, code like this:

 

 example_BD.png     and   example2_BD.png

 

 

is simply silly. Comparing a Boolean to True is redundant.

Message Edited by smercurio_fc on 06-14-2009 11:45 AM
Message 2 of 5
(2,952 Views)

Saverio already mentione most critical points. here are a few more:

 

A very ugly quick fix (duct tape repair) is to configure the events to NOT lock the FP until the event completes. I recommend against this.

 

 

  • All your buttons should be latch action. Now you don't need to reset them at the beginning.
  • Set the "Board SN" string control to "limit to single line" and you don't need to remove the linefeed later. You should handle it with a "value changed event" anyway.
  • You have way too many sequence structures. Many times execution order is not that inportant.
  • Event structures need to be on a toplevel diagram loop, always ready to fire. Don't hide them inside case structures or inner loops.
  • Lot's of unecessary code. Let's look for example at the code in the big FALSE structure:
    • You have a reference and write to a value property of the message box while the message box terminal is disconnected elsewhere on the diagram. Remove all that extra baggage and place the terminal right there and wire to it. 😄
    • You have a while loop containing a sequence, containing another while loop. The sequence and outer while loop have no purpose.
    • The while loop spins millions of times per second, just burning CPU. How fast can you possibly type??? Place a 100ms wait.
    • Rewritten as event structure, it could looks as follows (buttons set to latch action, string set to "limit to single line" and NOT "update while typing"). (see iamge below).

 

Of course the entire code should be rewritten in a similar fashion and around this single event structure. A second event case could deal with the error condition. Simplify!!!!

 

Message Edited by altenbach on 06-14-2009 11:49 AM
Message 3 of 5
(2,943 Views)

The output of "empty string?" in the image above should be inverted, of course.

 

This is just a draft and there are probably other errors, I did not test. Modify as needed. 😉

0 Kudos
Message 4 of 5
(2,937 Views)

Thanks!

 

Theses are really some useful tips and links.

I think I have some homework to do....

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