VI Hangs

[Dennis_Knutson]

No its not okay. Read the help about event structures. The event structure is always capturing/waiting for events - whether it's inside a case statement or not.

[JÞB]

---

Dennis Knutson wrote:
No its not okay. Read the help about event structures. The event structure is always capturing/waiting for events - whether it's inside a case statement or not.

---

AH, you are saying is that the FP will become unresponsive after an event is generated UNTIL the event structure is re-enabled.  e.g. Assume you have a state machine that configures parameters with an event structure- and does stuff all by itselfin the other states.  some jerk presses a button and "WHAM" the event happens AND if FP locking is selected the FP LOCKS immediately to enforce that events must process in order.   

Thanks- I never really got that point that on the scope of the event structure.  

[Jörn]

to shrekt

  [" Are the events configured to lock the front panel? lock front panel? "]

  There is a checkbox, when configuring the events for a case of the event structure. When locked (standard selection) no further FP action is allowed.

to Dennis Knutson:

  What do you mean with "event structure is firing"? I expected the event structure to wait the configured time out for any event and having received an event the appropriate case of the event structure is processed. Is the event structure in an Xcontrol treated differently than in a normal VI? If not I would expect that its possible to have several event structures in a programm. But each except for one needs to have a timeout of 0 ms. Otherwise the program would jump from one to the next event structure with each event. Of course there must be only one while loop which allows serving all event structures successively.

to all:

  keep the processing of events in one loop and in one event structure

Message Edited by Jörn on 2009-12-07 07.12.2009 07:55 AM

[Jörn]

I made a little program (LV 8.6.1) with several event structures. So I don't see problems why there should be more than one event structure. But you have obey some rules:

1. In oder to execute all event structures they need to time out immediatly because an event struture is only executed if one of the treated events occurs unless you have only one event structure.

2. the loops needs to be placed around all event structures

But this technique is not recommended for non advanced LabView Programmers.

Always keep in mind that an event structure does not implies a loop.

Message Edited by Jörn on 2009-12-07 07.12.2009 08:33 AM

[altenbach]

There is nothing wrong with multiple event structures in a program (example), as long as all are ready to service events at all times. It is a really bad idea to trap event structures in inner structures or place slow or interactive code (e.g. while loops) inside events.

I am not sure what you are trying to prove with your "little program" You are digging yourself into a hole, writing unmaintainable and difficult to debug code.

---

Jörn wrote:

But this technique is not recommended for non advanced LabView Programmers.

---

It's not recommended for anyone! In fact if you are programming like this, chances are you are definitely not an advanced LabVIEW programmer. 🙂 Catch 22!

Just because it can be done by following hairtrigger rules, the code is as stable as a house of cards as soon as somebody else needs to maintain it in the future. We have an entire thread full of garbage code and this fits right in.

Here's a quick rewrite of your code, same functionality with much less fuss. As you can see, you can float buttons that need to be on all tabs. You should also use the outer loop for the blinking, so the code can be stopped even while it is blinking.

As I said earlier, you typically don't need to tie the tab terminal to a case structure. If you use events and a value change got triggered, it is obvious what tab was active. Right? Just handle the event. 😉

Message Edited by altenbach on 12-07-2009 01:36 AM

[Jörn]

to Altenbach

Sorry for posting this code and bothering you to correct it. I just wanted to try out what happens if one would split up the event case manually. Background for this is, that I was thinking about how the XControls work. 

I am not writing my code in this way. If I had to realize this functionality I would have done it like in your tidied code.

[Norbert_B]

Joern,

i think it is valuable for every reader of this post that code is posted and discussed. So if you are referring to you last example as "this could work, but it is not recommended at all", everything is fine about it (except that in my experience "negative examples" are not as valuable as "positive" ones).

What i don't understand is your note about the XControls. Your example does not match the mechanism of XControls. So maybe you can give some more info about your pondering that we can get into discussion about that. Maybe, even a new thread would be advisable....

Norbert 

[Jörn]

Background to my thoughts is the search for reducing the number of events in the event structure of the main VI to keep the overview. I posted it now in another thread: http://forums.ni.com/ni/board/message?board.id=170&thread.id=461016

My note about the XControls come from these thoughts: why does the event structure in the XControl has to timeout immediatly? And how is LabView serving the different event structures in an XControl and in the main VI to avoid blocking each other.

[Norbert_B]

The timeout set to 0 is used to stop execution of the XControl "for this iteration". Deleting this case will crash the XControl since it cannot "terminate" properly and therefore it will stuck.

I don't know the exact details of the XControls event structure, but it responses mainly on LV internal events (opposed to user generated events). You can read something in this direction in this link.

Please note that if you use an event structure within your application:

- You have different event sources for your VI and the XControl

- You have different events captured by the different structures

hope this helps,

Norbert