"SYSTEM" LATCHING BOOLEANS INTERMITTENT ON FRONT PANEL

[MontgomeryScott]

All,

Thank you in advance for taking time to review my problem. I am using labVIEW 2011 (don't laugh, this is the NEW version for us) Program uses event structure and makes measurements in timeout case according to interval setting. when not in "timeout" other cases are handled by the front panel enums and booleans. The enum controls work great, but I am having an issue with some of the booleans, specifically the "fast forward, rewind, and reset" buttons. They seem to "freeze" at times, and cannot be used. when they do work, they do exactly what they are supposed to do. I have tried various mechanical actions. They are set to latch when released at the moment.

They set the end time of both charts along with the "sweep function" the result is essentially a scroll bar for two waveform charts so that they are always showing the same time sweep. While hovering over the button, it changes light blue to show that the computer is recognizing the "mouse over" event. Timeout value has been changed from 50msec all the way to 300msec, so I do not think this is a processor issue. As you can see from the code, several controls trigger the same event since they all work together. Is this causing my issue?

Thank you all again. I appreciate the time and effort in helping.

[Gregory]

Hi Montgomery,

That probably means your event structure is getting stuck in a certain event. To figure out when it is getting stuck, I would put a probe on the error wire input to the event structure. This should be updating at 50ms + time to run your timeout case. If you don't press anything. Then starting using the application as your normally would. When you see the error wire probe "last updated" get frozen, then you know it got stuck.

If you want your event structure to accept new events even when it is working on an event, then you can go to each event, right click >> "edit events handled by this case..." and un-check "lock panel".

[altenbach]

All your events are set to lock the front panel until the event completes, so if you have event frames that take a while to complete, you get what you observe. Maybe you should split the UI code from the processing code using a more established code architecture.

There are plenty of missing subVIs (e.g. in the timeout case) so we cannot tell what they do and how long they take.

(BTW: the while loop and sequence structure in the "pause" event case is completely useless. There is an =0 primitive). 

[MontgomeryScott]

I have no idea what I was thinking with the structure and while loop. a "ensure one execution happens" maybe. Thanks for the tip! I changed it. Turns out it wasn't locking causing the issue.

Its the stinking custom buttons! I have transparent PNG's slapped on there, right in the middle of the stinking button, it seems when you click the PNG, you are clicking the png and not the button! All my other buttons are like the "erase graph" button and have the symbol to the side, so I never noticed. Wow. . . . 

In my frustration I just never noticed WHERE I was clicking and logical fallacies took over. 

Thanks a lot to everyone that took the time to review my issue! 

[MontgomeryScott]

gregoryj, 

see my response to altenbach for what it was.

Thanks for the good info I'll keep it in mind.. turned out it was a pure UI custom button issue. Excuse me while I flagellate myself with a network cable as punishment. . .. . . 

[Gregory]

You are allowed to have pictures on the button and click through them, BUT you must import them as a decal, you cannot simply paste them onto the button 🙂

[altenbach]

---

@Gregory wrote:

You are allowed to have pictures on the button and click through them, BUT you must import them as a decal, you cannot simply paste them onto the button 🙂

---

(Posting by phone, cannot test). 

There are severe limitations with customizing "system" buttons, though.