10-23-2009 10:10 AM - edited 10-23-2009 10:16 AM
I have a LabVIEW base version (v8.6) which does not have the event structure. I found it was quite inconvenient to monitor the status of several controls (the action after click a control depends on the status of other control(s)). Especially if I want to add another function (control), the effort increase exponentially with the existing number of controls
I got an idea of simulate the event structure using 'Shift Register'. First, I will bundle all the values of controls into a cluster. Then I will put the cluster in a while loop, and compare the value of the cluster with its previous value (xor the shift register). If the compare result is false (none of the control is changed), the program goes to next iteration. If the XOR result is true (one of the control was changed), then the program goes into event handling code (it will pass which control has changed, and the whole cluster). So for each control change, we can write a independent code to process the event. After processed the event, the event was cleared.
The following is a section of my ugly code currently used to monitor several controls. And I am thinking of rewrite it using above idea so that there will be less likely a hiden bug.
Any comments of suggestions?
Solved! Go to Solution.
10-23-2009 10:35 AM
Quick tip to eliminate the string of OR functions all in a row. Use the compound arthimetic function on the Boolean palette (also on numeric palette). Set the mode for OR. You can expand the node so that it handles multiple inputs. That way you can use one function in place of the three OR functions.
10-23-2009 10:43 AM
I'm not entirely sure what I'm looking at in your picture of your block diagram because it looks like only the lower right hand quarter of your code. I would do the following to detect a change in a cluster control w/o the event structure:
Does the base package include notifications or queus? You can put your "event handling" into another thread by this method:
The advantage here is your main program loop doesn't get "bogged down" whenever a change in your cluster occures. It also helps seperate the code so that it is cleaner.
Hope that helps!
-nicker
10-23-2009 10:49 AM
Altough this is an interseting academic question, we really can't duplicate the efficiency of the Event structure so springing for an upgrade is highly recomeneded.
But I am not here to sell LV but rather help LV developers so...
Start by developing an Action Engine with the following actions.
1) Init -caches control ref for all controls and indicators for which you need an event. Optionally rest them and cache their state.
2) Check - Will compare the current state with the prvious state and any changes get pushed onto a stack in the AE and if there are elements in the stack (due a change detected now or one left over form the last check) and returns a type-def'd enum describing what changed. Multiple changes should be on the stack for next time.
3) Get New - will return the new value of the value requested via an Enum.
In you top level VI use the AE to Init before you run and then use an "Check" method to se if anything changed. If it flags a change (boolean output of AE) then the Enum is used to select the proper case of a case structure. Inside the psuedo-Event case, you can use teh AE with the "Get New" action and pass the enum to choose which value to get.
It is hardly an Event Structure but it should come close.
Ben
10-23-2009 10:52 AM - edited 10-23-2009 10:54 AM
Ravens
That is a good point. I never noticed this function in the function panel.
However, you still need a cluster to handle the control change.
10-23-2009 10:53 AM - edited 10-23-2009 10:54 AM
Ben wrote:Altough this is an interseting academic question, we really can't duplicate the efficiency of the Event structure so springing for an upgrade is highly recomeneded.
But I am not here to sell LV but rather help LV developers so...
Start by developing an Action Engine with the following actions.
1) Init -caches control ref for all controls and indicators for which you need an event. Optionally rest them and cache their state.
2) Check - Will compare the current state with the prvious state and any changes get pushed onto a stack in the AE and if there are elements in the stack (due a change detected now or one left over form the last check) and returns a type-def'd enum describing what changed. Multiple changes should be on the stack for next time.
3) Get New - will return the new value of the value requested via an Enum.
In you top level VI use the AE to Init before you run and then use an "Check" method to se if anything changed. If it flags a change (boolean output of AE) then the Enum is used to select the proper case of a case structure. Inside the psuedo-Event case, you can use teh AE with the "Get New" action and pass the enum to choose which value to get.
It is hardly an Event Structure but it should come close.
Ben
But after looking at Knickerbocker's* post we can go farther.
Put the above code in a sub-VI that feeds a queue. Then you can monitor the queue for updates just like in an event structure AN you can queue up all of the changes at once and can ingore my mention of caching the change methods in the AE. Just let the queue handle the stack.
Ben
*Kudos for inspiration!
10-23-2009 10:57 AM
I like Nickerbocker's snippets, as they demonstrate how to fire code just once when "something happens". Not as neat as the Event Struct, but it'll do.
I also like to use Open G's "Data Changed" VI (or I will roll my own) -- the shift register is no longer needed!
10-23-2009 11:09 AM
Nickerbocker,
The base version has the queue functions under 'Data communications' category.
Ryan
10-23-2009 11:18 AM
10-23-2009 11:49 AM