LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
schmieger

New Property "Blink Trigger" for front panel objects just to trigger one blink at a selectable time

Status: Declined

Any idea that has not received any kudos within a year after posting will be automatically declined. 

Normally setting the property "blinking" leads to slow blinking at a fixed time intervall of front panel elements. In automated processes you just want to give the user feedback which knob or parameter was changed by your state machine or other processes. So a short blink (e.g. 50ms) can do this job to pay the users attention. If you set and unset this property e.g. in a consecutive sequence structure you will not notice any colour change of your front panel element.

 

LabView 2015 doesn`t support this feature. You have to program workarounds (e.g. with FGV`s) which either leads to unwanted pausings or interruption of your program.

 

So, a new property node for triggering one short blink at a selectable time would be helpful.

8 Comments
elset191
Active Participant

Are you familiar with the Object Highlight method for controls and indicators, available through the invoke node?

--
Tim Elsey
Certified LabVIEW Architect
schmieger
Member

@elset191

No, I`m familiar with the property nodes. I have to go for information first how to use invoke node. I use the german version.

Actually I don`t find the property Object Highlight in method options.

schmieger
Member
Now I tried using this method "ObjMarkieren" but unfortunately it causes a pausing of the current loop and therefore leads to a dramatic drop of your processing speed. So my suggestion is still valid. Thanks for your idea!
Blokk
Trusted Enthusiast

Now I tried using this method "ObjMarkieren" but unfortunately it causes a pausing of the current loop and therefore leads to a dramatic drop of your processing speed. So my suggestion is still valid. Thanks for your idea!

 

I do not see why using this Invoke Node would cause a "pausing". Maybe the problem is in your implementation? Can you create a simple example to show when you see performance drop using this method?

 

edit: in the below snippet the usage of the "Wait until ...multiple" is not too lucky for benchmarking, hmm, I play with the example a bit more, when I get more info i will post back.ű

 

edit2: Now I see what you mentioned, see second snippet below. I will search in this topic a bit more...

 

highlight.png

 

Example_VI.png

Blokk
Trusted Enthusiast

Workaround for the Object Highlight Invoke method: decouple the invoke node call from your actual loop where execution speed is a priority. Use a losless communication like Queue or UserEvents (you can encapsulate the reference wire using an FGV so saving BD space):

 

Example_VI_wa.png

schmieger
Member

Now I`m back from vacation....

@Blokk: Thx for your workaround. It seems to work. The iteration counter itself pauses when pressing the button, but in the background the loop seems not to be interrupted.

By the way: nice construction to use the queue`s error line for the highlight case.

🙂

In case of multiple front panel objects you have to create different queue elements and cases, so you can`t use the error line.

 

Okay, beyond this workaround I guess NI should implement a non interrupting highlight method, otherwise you fill your program with unwanted stuff. This reduces the overview over your program.

Thanks again for your idea!

schmieger
Member

At least you can`t select the time duration for highlight period. The invoke method uses appx. 400msec, but in automated systems this is too long.With many object on front panel and many changes in a short time the front panel looks like a christmas tree or blinking lights on a county fair.

 

Short highlighting a front panel object at 50msec is enough to indicate which values are changed by your program.

Darren
Proven Zealot
Status changed to: Declined

Any idea that has not received any kudos within a year after posting will be automatically declined.