FIRST Robotics Competition Discussions

I saw this same behavior with the team I mentored and was equally surprised, but didn't spend much time playing with it.  I assume your PID VI is in a frequently-called subVI; try moving the front panel controls out to the main front panel and see if it that works.  It looked like every time the subVI is called the front panel controls reinitialize to their default values, so putting the controls in a long-running VI (the top level) should fix the problem.  Some other things to experiment with: see whether it matters if your front panel controls are connected to terminals in the connector pane - if they are, make sure nothing is wired to them, of course - and check the VI properties (maybe re-entrant execution) to see if any option is set that might cause that behavior.

In addition to nathand's awesome suggestions I would like to point out you can change the value of a numeric control by different increments depending on what digit you click on with your mouse before pressing the increment decrement buttons.  For Example:

We have a numeric control with a value of 0.00.  By default the increment button would make this value 1.00 then 2.00.  But if we click on the last digit in the control and then increment the value we would get 0.01 and 0.02.

Its also very helpful if you could post the code or a screenshot of the code that is demonstrating the behavior you have described.  This way the community can help analyze any possible issues with the code that would explain the problem.

Cheers,

Mark

NI FIRST Support

It is easily reproducable by creating a new advanced template and adding a numeric control to the disabled.vi front panel. Then run the robot main and open the disabled front panel. Anything you type into that control is instantly deleted.

As for nathan's suggestion about moving the controls further up the heirarchy, using the advanced framework, that's about as far back as you can go, as putting controls in robot main doesn't seem like a good idea. No changes were made to the execution portion of the VI properties.

The click the digit you want to increment trick also doesn't work, probably for the same reason you can't type.

I think you'd need to put the controls in the Robot Main, since its front panel will stay open as long as your robot code is running.  Why does this seem like a bad idea to you?  (I understand that the framework says you shouldn't need to modify anything in Robot Main, but putting controls or indicators on the front panel will not cause any problems.)

I had the same problem with numeric controls, and I also agree with sciencewhiz .

The controls should stay on the same front panel as the VI that uses them.

Any other solution is just a kludge.

In my case, the PID tuning parameters were the worst.

I had a turret tracking sub-VI that used a PID to slave the turret to the camera target.

I only needed to tweak the PID coefficients now and then, and they were an integral part of the sub-VI.

I ended up having to start and stop the app every time I weanted to tweak the tuning.

It wouldn't have been much worse if they had been hard-coded as constants.

It makes no sense to have to move this tuning control out of the VI where it's used and pass the values in somehow.

Doing so makes it harder to re-use the sub-VI in other instances since the tuning is no longer integral.

The whole power of Labview is that the debugging/display screens are local to the VI, and only displayed when needed.

That's how it is in non-realtime (PC), thats how it should be real-time (cRIO).

This seems to be a problem with how the PC deals with the keyboard focus and remote change notification.

We often resolved the problem by replacing the numeric controls with sliders (with numeric readouts only).

So it's not a systemic problem, it only relates to numeric text entry.

Phil.

Hey guys,

I have been trying to reproduce this beahavior here at NI but I have so far been unable.  Does anyone want to post some example code?

Cheers,

Mark

I've attached an advanced project, with the only thing changed was a numeric control that I added to the disabled.vi front panel. When you run the program, try typing in the numeric control.

Howdy,

I have been able to reproduce the behavior (thanks sciencewhiz for the tips), and I was even able to find a bug report (CAR #95366) filed with the LabVIEW Real-Time development team describing this behavior.  Unfortunately for us this behavior was deemed expected and therefore it is "not a bug."  Here is the explination from our developers.

The subVI is constantly being called and closed with each iteration of the while loop. The delay of the main VI gives the user time to change the subVI value and set the value, but once the delay is finished the subVI is closed then reopened with the default value.

We may be able to work around this behavior by adding a long wait inside the subVI in question to give us time to input the value of the control.