event structure - general

[Gabi1]

hello

this is probably something that had been treated millions times, however i could not find direct answers from previous threads on that, so i ask directly.

i am a bit confused by the utilisation of event structures:

first, one would expect that if the event is used, say in a while loop, then outgoing data would be kept trough the sequence, without having to wire trough the other events, unlike as depicted in the pic below. that should be to my understanding the definition of "use default values" on the outgoing data nodes.

however it seems not to work like that. why? is there a way to force LV to do as i want (instead of "use default values", make him "use last input value")?

wiring trough all the nodes make the event structures very unelegant.

second: this is probably a very naive one, but i dont like the way i do it: in some events i have same operations going on as on turn on of the vi. in other words, when i initialise my system, i pass trough several operations, which also exist in the event structure. to make the diagram more elegant it would be usefull to call all those events programmatically a first time. up to now i do it by programatically signalling the values of some controls. however there must be a more elegant way, where i could just queue the events needed. any suggestions?

Message Edited by Gabi1 on 05-17-2007 06:11 PM

Message Edited by Gabi1 on 05-17-2007 06:13 PM

[Jarrod_S.]

Use Default Values means if nothing is wired to that terminal, use the default data for that data type. For a numeric, it's zero. For a string, it's an empty string. For an array, it's an empty array, etc. You will have to wire through each case to maintain your data in the shift registers. If you don't want to forget to do this, you can right click the terminals and uncheck Use Default if Unwired. That will produce instead a broken Run Arrow if a tunnel isn't wired. So you won't be able to forget to wire through.

To respond to your comment that the tunnels should remember there last data value. If they did, then it seems like you'd be duplicating all your data. The shift register would have a copy, and the Case Structure would have a copy.

Regarding your second statement, there are two ways to generate events programmatically. One is Value Signaling, which you know about, and the other is User Events. User Events are more flexible and should have better performance, since they're not bound to UI objects, but they are a bit more complicated. You can mask any notification event (such as Value Change, Mouse Move, etc) with a User Event and programmatically fire it. Search ni.com for User Events or look in the Example Finder for User Event examples to get a handle on how to use them. They may or may not seem more elegant to you to use in your application.

Message Edited by Jarrod S. on 05-17-2007 06:51 PM

[Joe_H]

I prefer to use the event structure to handle events and not have to do any type of configuring. I would suggest that you think about code architecture. I would suggest the producer consumer with events and a queued state-machine type. There is an example of this in the example finder.

 That way the event structure handles your events or very small amount of code and the other loop handles the initialization or whatever type of code you want. This is a much more robust way of doing things.

[Jarrod_S.]

Joe really hit the nail on the head with his post. Just have your event loop enqueue commands onto a queue that get serviced by a background consumer loop. Then your initialization doesn't involve programmatically firing the correct events, but enqueuing the correct commands onto the queue before the two loops start running.

If you were looking for an elegant solution, Joe's got it!

[mikeporter]

How is creating a redundant event queue more elegant? If you have events that are already doing what you need just fire them and don't worry about the added complexity of a second seperate loop.

Mike...

[Jarrod_S.]

The second loop need not be redundant. For simple applications it might be overkill, but it has at least these advantages:

• Events by default will lock the front panel until the event case completes that handles the event. If your response to the event involves some large calculation or allocating a lot of memory, then you could lose responsiveness in your user interface. Out-sourcing the actual work to a second loop leaves the event loop ready and active to handle more incoming events and reduces the time the user interface is locked.
  
• It encourages parallel programming. Processors aren't getting too much faster these days, but already the standard is at least a dual-core. Future machines will have even more processors. Start planning for this. A producer loop and a consumer loop is a great way to distribute the workload across processors.
• You separate the interface to from the implementation. Commands can then be triggered from many places (code or UI events), but they are processed exactly the same.
• Triggering events forces a thread swap to the user interface thread, which can slow down execution. It can also make a redundant copy of the data that has to get stored in the control whose value change was triggered, which you might not need. Enqueuing commands onto a queue does not have these limitations.
  

Message Edited by Jarrod S. on 05-17-2007 11:23 PM

[Gabi1]

producer-consumer loop!

very interresting. i am going to try it out.

but still i think about the data nodes of the event structure should be able to hold previously created data. i dont understand why it would be so bad architecturally.

i think this actually could be a point for improvement.

[Joe_H]

Thanks for the backup jarrod,

Mike,

I agree with you also that sometimes it is overkill. If the code is small enough then stick it inside the event structure. The thing I like about queues and the event structure setup in a producer comsumer way is that I can have one producer (Event structure) and multiple consumers. Also I can have multiple producers and multiple consumers by using dynamic events all in one architecture without really having to change much to go from one to the other. This way the code is also more upgradeable and sometimes more robust.

Gabi1,

This may not be a bad idea but I think it would make the event structure a nightmare to debug (just my 2 cents).

Message Edited by Jhoskins on 05-18-2007 10:18 AM

[LabBEAN]

---

Jarrod S. wrote:

Triggering events forces a thread swap to the user interface thread, which can slow down execution. It can also make a redundant copy of the data that has to get stored in the control whose value change was triggered, which you might not need. Enqueuing commands onto a queue does not have these limitations.

---

 

To clarify Jarrod's comment, it's important to note that neither the event structure itself nor dynamic events cause a switch to the User Interface Thread.  Functions inside the event structure (e.g. property nodes, invoke nodes) can cause a switch to the UI Thread when they operate on UI components.

In that discussion, Jason King points out that:

"There is nothing specific about the event structure that requires the event-handling case to run in the UI thread.  In fact, there is not any event that will force it to run in the UI thread"

"Reading from or writing to a front panel terminal or local variable does not cause the diagram to run in the UI thread."

"Any actual processing of user interaction, however - either looking at user interaction to determine which events to generate or finishing processing a filter event after the event structure has had a chance to discard it or modify any of the event details - requires the UI thread."

"Pretty much anything you do with the reference to a control or indicator will cause a switch to the UI thread (property nodes, invoke nodes, etc)"