LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

confusing behavior of button event

In fact once you get the hang of it, you'll be amazed how simple LabVIEW is. It requires some training, but if the problem is simple such as in this case, the solution cannot be complicated or you are doing something wrong. LabVIEW is a full featured professional programming environment and does require experience that can only be gained by programming for a long time. If you have a very complicated programming problem the program itself will be more complicated too. LabVIEW is not a childs toy where you simply arrange little pictures. 😄

 

Here's a quick draft that could give you some ideas. Modify as needed.

Message 11 of 15
(369 Views)

@altenbach wrote:

Quick analysis:

 

  • Use latch action for the booleans, not exotic and most often inappropriate ones such as "switch until released". Once they are latch action, their terminals belong inside their respective event case.
  • The first inner sequence structure has no function (delete it!) and the other two can be eliminated by using proper data dependencies.
  • Use a single loop and a single event structure and keep track of the program state in a state variable in a shift register (e.g. an enum). No sequences needed.
  • There is no need for timeout events, because nothing special happend there (first event structure). So why spin the loop?
  • An event structure with only a timeout event is pretty useless (second event structure).

Hi altenbach, sorry for bugging again. I am trying to learn more from your comments but I try for hours, something still confuses me. I modified my code based on your suggestions and it works. Now, I smell some idea for the event handling in LV. But I am thinking the suggestion you made at the very beginning of the reply. You said Event structures should never be hidden inside sequence frames.  So in my extended code, I am going to implement something like that (pseudo code)

 

t1.png

 

There are two places needed events handling: frame 3 and the last loop for STOP button. As suggested, I pull the event structure outside the sequence and try to maintain one structure for all events. In the implementation, to make it simple, I use time delay for the TASK1 and TASK2, for TASK3 and TASK4 the time day is randomly picked from 0 to 5 seconds (in real case, it could be waiting any times as long as couple minutes).

 

Since I pull the event structure out, I place a while loop in frame 3 and waiitng for the button pused to quit the loop and jump to frame 4.

 

I handle two buttons value change events. One for the button stop the loop in frame 3 and one for the last loop.

 

But some times, the button in frame 3 doesn't response and sometimes the last button doesn't response.

 

Again, I cannot post the attachment. Someone told me to try different browser and computer. I finally get it uploaded in the next thread in another computer. Don't know why 😄

 

0 Kudos
Message 12 of 15
(354 Views)

seems attachment still not working for me 😞

0 Kudos
Message 13 of 15
(354 Views)

@PKIM wrote:

seems attachment still not working for me 😞


The attachment works - and it shows me that you are trying to learn how to use the parking brake to drift when you don't understand how the gas, brakes and steering wheel work.  Instead of trying to figure out how a latching boolean works, I think you should be concentrating on how LabVIEW, itself, works.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 14 of 15
(336 Views)

PKIM wrote:


Hi altenbach, sorry for bugging again. I am trying to learn more from your comments but I try for hours, something still confuses me. I modified my code based on your suggestions and it works. Now, I smell some idea for the event handling in LV. But I am thinking the suggestion you made at the very beginning of the reply. You said Event structures should never be hidden inside sequence frames.  So in my extended code, I am going to implement something like that (pseudo code)



You miunderstood. More accurately I should have said that an event structure needs to be ready to service events. It cannot sit there while lenghty code is executing in other sequence frames and such. This also meas that an event structure needs to be in a loop so it is ready to handle the next event once one has completed.

 

Let's look at your code.

Dataflow: you are completely deadlocking your event structure. It can only execute exactly once per run and frame #3 cannot start unless the event structure has completed once. Depending on the value of the boolean, the inner greedy loop will no either spin forever as fast as the computer allows of will complete immediately. Same for the next loop, depending on the state of the boolean going to its stop terminal. Once these loops start they will read the same value forever from the input tunnel. They will never know if any of the booleans are changed again in the future, because these terminals will only get read once.

Your VI is basically dead and simply rolls over whenever it is run, rattling through the sequence frames. A VI needs to be alive and have a hearbeat. As said before, use a single outer while loop containing a single event structure to handle user intereactions and keep track of the current state to decide what to do next. You don't need any sequence structures and you don't need any local variables if it is done right. Look at all your duplicate code. You can re-use most in various execution states.

 

At this point I strongly recommend to first learn some basics.

 

Did you even look at the VI i attached earlier for some ideas?

 

 

 

0 Kudos
Message 15 of 15
(329 Views)