I am using LabVIEW 2015 and am looking to disable the keyboard and prevent users from typing into the controls, so they only can use the increment and decrement arrows. Is there a simple solution to doing this programically in LabVIEW? Is there a way to utilize property nodes or simply alter the settings of the controls themselves?
Solved! Go to Solution.
Put a transparent decoration over the box part of the control so no one can click into it. You may need to make sure the control can't be tabbed into.
It can be done but, WHY would you want to? Tell us why and we might have a simpler way to do it.
I'm using the controls to adjust pressure to a pneumatic cylinder. The input to the controls is limited to a certain range and I set limited increment ranges as well. I'm using a control loop to control force with a PID controller, so I want to limit the amount that the user increase the force set point so the system does not overshoot to damage.
Are they going to be very small changes that need to be made?
Honestly, if you made me click the increment/decrement arrows, I wouldn't use your application. That might change if I only ever needed to change it by a couple. But, if I had to make changes that were beyond that, it'd be incredibly obnoxious to have to click the arrow a bunch of times because the developer didn't want to put something more elegant into the design to prevent a poor response.
I understand the concerns about the potential issues with using the increment/decrement arrows, but this will be the route that I am going.
Is using transparent decorations a feasible idea? Are there any other ways to go about it?
And, this is exactly what I meant. Keyboard is the wrong input device. It is inherently unsafe for your application. Use a joystick or foot pedal to control the change in setpoint and limit the rise and fall times with filters and software. With a ptbypt max change.
Do tell me you are using a RT OS! If not, seek someone with experience developing this type of application. And no, I'm not available.
Venu, his concern isn't going beyond the min/max values. It's easy to do a handful of different things to combat this. You can even go into the properties for the control to set it to not allow a value beyond the man/min values. Disabling the control here would be a pretty bad idea. How would you get it out of that state? You could never bring yourself back into range because you couldn't change the value. Let's not do that.
His concern is his PID loop. He's worried that if the user makes too drastic of a change, the PID loop will overshoot and take itself into an unstable place where it won't be able to regain control and bring the output back to the desired setpoint. In order to avoid this corner case, he's set himself on an idea that makes his application virtually unusable. If you absolutely have to control the setpoint to ensure it's a slow increment, he should be taking advice and looking at different input devices. The increment/decrement are a choice that should be considered intolerable if the setpoint ever moves more than a couple of values at a time.
There's a ton of ways to prevent this though. You can use the decoration as suggested. You can use an event to leave the old value in place and alert the user to use the increment/decrement. Etc. But, why would you hate your users enough to do this?
I think if you are going to require a user to use the increment/decrement buttons, it would be better to make customize the control to make those buttons larger. Alternatively, hide them and create separate buttons and use an event structure to increment the value up and down.
If the process is so sensitive to how fast that value is incremented, it might be a good idea to separate the control from the PID loop. Have some sort of rate limiter that only updates the PID input at a certain rate no matter how far/how fast the user updates the control. You'd want to have some sort of indicator or perhaps waveform chart that shows the actual value of the setpoint at the moment compared to the desired setpoint.