Disable front panel lock on dynamic events

[testingHotAir]

Hi all,

I use event structures with dynamic events through my application to handle streaming data displays.  Basic layout is a parallel loop receives the new data, acts on it, then sends the data needed to update the FP via a dynamic event.  The FP has an event structure that only updates the controls and therefore doesn't take very long.  However, there are many events triggered per second (20+).  The problem I'm having is that the entire app interface will freeze for between 2 and 6 seconds seemingly at random.  Using desktop execution trace toolkit, I can see that the time it takes to actually execute is not changing despite the apparent FP lock.  Everything I've found so far says to try disabling front panel locking on the event structures, but that does not seem to be possible for dynamic events.  Is there any way to do this with dynamic events?  I'm using LV 2014.  Any other things I might check?

Thanks

[JimChretz]

You can use the Defer Panel update property node.

http://zone.ni.com/reference/en-XX/help/371361H-01/lvprop/pnl_defer_pnl_updts/

Good luck!

[testingHotAir]

So I would need a VI ref in my loop that I use to set that property on and off while the event case is executing?

[crossrulz]

The front panel locking is only for events caused by the front panel, like a value change.  User Events will not freeze the front panel.  Perhaps you have something else happing in there?  Do you have any code that you can share for us to examine?

[Intaris]

---

@crossrulz wrote:

The front panel locking is only for events caused by the front panel, like a value change.  User Events will not freeze the front panel.  Perhaps you have something else happing in there?  Do you have any code that you can share for us to examine?

---

IIRC this is not strictly true.

If you register for an event of a FP control dynamically (As opposed to statically) then you can still choose whether or not the event locks the FP or not.  Say you have a control "Numeric" and you want to create a USER Event for the "Value changed" event.  When registering, you can right-click the "Register for events" for that event and shoose whether the event should lock the UI thread or not.

This is a very poorly documented thing and is (to top it all off) completely hidden from view when set (either way).

Again: This refers only to situations where you create USER EVENTS based on existing FP CONTROLS.  So if your "dynamic events" are really non-FP events, then this setting will be a) not available and b) invalid for the event anyway.  You don't offer code so I don't know for sure what event you're using to trigger communications.

Shane

[testingHotAir]

Unfortunately my code base is fairly large and difficult to share.  I've tried to reproduce the problem in a smaller version of the application without success.  The good news, however, is that the problem seems to have been solved by going through all the actors that use statically registered FP events and disabling locking.  I'm not ready to rule out some other root cause since I don't really understand why this would solve the problem.  Everything in the app that uses FP events is also inserted in a subpanel.  Could there be an interaction between the subpanels and the event structures that drives this behavior? 

[crossrulz]

---

@testingHotAir wrote:

Could there be an interaction between the subpanels and the event structures that drives this behavior? 

---

Not that I have ever ran into.  If I had to take a full on wild guess, it would be that you are using the Value (Signalling) property somewhere with an event case that was set to lock the front panel.

[testingHotAir]

There are a lot of Value(Signalling) events sprinkled throughout the app...  Locking has been disabled on all of them now so that could have been it.

[testingHotAir]

Ok so I lied...there are no Value(signaling) nodes in the project at all.  It's still giving me the problem but I'm starting to wonder if it's a hardware issue (eg: overloading my video card?).  Running the desktop execution trace, no VI calls or event structures are taking more than 20 ms to execute.  On the highest ones I've been able to verify this with tick count benchmarks.  Does anyone know a way to figure out if I'm asking too much of my hardware?

[csparksfly]

Hi testingHotAir,

You could use Windows Task Manager to monitor the performance of your hardware if you feel like that may be an issue. Are you still having an issue after disabling locking as you had mentioned previously?

Christine S.

Applications Engineer