Front panel controls lock up in XControl

[JackDunaway]

I have noticed some strange behavior in an XControl I've been working on, and I'd like someone to be able to explain why.

Here are the facts:

The XControl architecture contains an event structure. Generally, event structures respond to front panel UI changes. Also, when you unselect the box "Lock front panel until the event case for this event completes" you can activate controls while that event case is waiting to finish.

Here's what I did:

I placed an instance of my XControl on a blank VI, and it works just fine when that VI is in edit mode. While events are waiting to complete within the XControl code, controls on the Facade can actively be changed since that check box is unchecked.

Here's the fishy part:

When that VI is run, the controls on the front panel of the Facade of the XControl lock up until the events are complete. So, lots of explanation boils down to this: the XControl works fine when the instance is placed in a VI and that VI is in edit mode, but when that VI is running the XControl "locks" up its front panel controls until each event in the XControl completes.

(As a side note, I have no code within the XControl's "Exec State Change" event case)

What gives?

[TCPlomp]

Without the actual XControl I have no idea...
The owning VI is blank?
Do you have dynamic events inside the facade VI?

Ton

[JackDunaway]

Thank you for your quick reply, Ton.

1. The owning VI is not exactly "blank". It has the terminal of the XControl, a while loop with a 100msec wait and a "stop" button for the while loop conditional terminal. It is "functionally" blank, allowing nothing but manipulation of the XControl controls until the stop button is pressed.

2. Yes. The XControl registers a dynamic event.

Thanks,

Jack

[Ben]

Hi Jack,

Could you post a zip of a project that includes the XControl along with a demo VI?

We may be of greater assistance if we had code to poke at. XControls are simply too complicated to troubleshoot by playing 20 questions.

Trying to help,

Ben

[JackDunaway]

Ton and Ben,

Thank you for your replies. I frequent this board often, and I continually respect both of your answers across all areas of LabVIEW. Here is the attached code, saved in 8.5.1 format. Please advise if you are unable to open the code, or if I could zip it in a more portable manner.

The top level VI is "Scratchpad.vi", which contains the XControl. Here is the exact symptom I want to fix: When I drag the slider up and down rapidly when the Scratchpad is in edit mode, the animated pane continually updates its set point in the feedback loop. However, when the top level VI is running, the slider will cause the pane to animate, but it's control is locked until the pane has settled. It then updates the pane based upon queued movements that occurred while the first Slider Value Change Event was executing. The goal is to have the XControl behave in run mode the same way it behaves in edit mode.

Finally, I have removed the dynamic event I was previously using in order to streamline the code. Disregard my remark earlier that this XControl contains dynamic events.

Thank you in advance for your help.

Jack

[Ben]

"I frequent this board often, and I continually respect both of your answers across all areas of LabVIEW. "

Thank you Jack. If you do prowl this forum you may have noticed that I generally don't troubleshoot complex challenges durring the day. If nobody else solves this riddle before tomorw AM, please bump this thread before 8:00 Eastern US and I'll try to take a look while letting my coffee start to work.

Ben

[JackDunaway]

I have narrowed down the problem to a simple quandary.

When the owning VI of an XControl instance is in edit mode, the XControl's event structure continually responds to events triggered. If two events are fired back-to-back, one iteration of the XControl's Facade while loop will handle the first event and the next iteration will handle the next event.

When the owning VI is in running mode, the XControl Facade will not respond to it's events until after the While loop in the XControl's Facade has received the "True" stop command in the Timeout case. In other words, if two events are fired back-to-back, the Facade VI will handle the first event, timeout, then handle the next event.

In my operation the edit mode Facade event handling is preferred. How can I get the Facade VI to respond to multiple events triggered by the user without the Facade needing to Timeout in between each event?

Thanks,

Jack

[Ben]

HI Jack,

I downloaded your code and tried it out. I have now run out of time for this AM but I am now familiar with your code.

Could you please try again to exaplin the issue so I can now focus on trying to help.

Sorry no quick answer from me today.

Ben

PS: If there is someone else who can advise, PLEASE do SO!

[JackDunaway]

Thanks again, Ben. I have made some major changes streamlining the code that I can upload later today. It's probably much easier to read than the "beta" stuff I uploaded previously.

Assuming you are familiar with the operation of the XControl, let me explain the issue with new terms. The user has three controls that will change the set point (target point, requested point) of a closed-loop feedback animation. The animation will recenter the array of strings based upon the set point, in order to highlight the selected array item. The up-down buttons work fine, and clicking the list to recenter works fine. It's the slider I am having problems with.

In the feedback system, I want to be able to continually move the set point and have the animation dynamically try to achieve that set point. When the owning VI is in edit mode, the set point may be constantly changed via the slider since "Value Change" events fired back-to-back can be handled by subsequent adjacent iterations.

However, when the owning VI is running, when the user operates the slider thus triggering a "Value Change" event of the slider, the XControl forces itself to achieve the set point while queueing up any other Value Change events. Once the set point has been achieved, the XControl Facade times out, then re-enters itself to handle the queued Value Change events.

The result is a very smooth animation in edit mode, and a choppy, discontinuous motion in running mode.

Any ideas on how to get the XControl to respond to Value Change events back-to-back while the owning VI is running??

Thanks,

Jack

[Another Steve]

Hi there,

Did you manage to find a solution to this problem? I have a similar experience and would be very interested to know how to sort it out.

Cheers,

Steve