Limit on how complex Teleop.vi should be?

[flemdogmillion]

Hello from 3007 (again),
I have a rather crowded and complex teleop.vi, and I was wondering if there is a downside of this.
Also, can anyone tell me if I dropped a negative sign somewhere in my lateral aiming algorithm? I can't keep track of all of it.

[Mark McLeod]

Teleop needs to complete faster than 20ms.
You can check this using the Elapsed Times.vi provided under the Support Code in the project tree.

Drop it into Teleop and open the front panel of Elapsed Times to watch, then run debug from Robot Main. You'll get how long it takes Teleop to run.

Normally you should put complete, time consuming tasks somewhere other than Teleop.
Usually Periodic Tasks.vi is a good choice.

[flemdogmillion]

Originally Posted by Mark McLeod

Teleop needs to complete faster than 20ms.
You can check this using the Elapsed Times.vi provided under support in the project tree.

Drop it into Teleop and open the front panel of Elapsed Times to watch, then run debug from Robot Main. You'll get how long it takes Teleop to run.

Normally you should put complete, time consuming tasks somewhere other than Teleop.
Usually Periodic Tasks.vi is a good choice.

I'm pretty sure it completes within 20ms, but I should probably check.

[Jonathan L.]

Just by looking at it, I don't think it should be a problem for the roboRIO to handle. Using Elapsed Time.vi as Mark McLeod said would be a good idea if you really want to know for sure.

I see a Negate function just before the PID's process variable input. I don't know if that's what your looking for.



Visually, it does seam a bit messy. You can fix that by creating subVIs for each function (e.g. Drive.vi, Feeder.vi, Climber.vi, etc.). I wouldn't hesitate to copy the Joystick Get code into each of those VIs. If you end up with two actuators that are strongly related, you can still put those in the same vi. For example, in 2015 we had an elevator that used a motor and a pneumatic piston as a brake. The operator had an up button and a down button. Whenever, the up or down buttons were pressed, the brake would be off and the motor would move in the appropriate direction (assuming it was safe according to limit switches). If neither button was pressed the motor would be off and the brake would be on. That was all a subVI in TeleOp.

Additianaly, you can put most of that code inside a VI that gets reused in autonomous. See our code from last year for an example of that.

Of course there are other ways to organize code. This is just one way that you could easily use without having to learn a whole lot about communication inside a LabVIEW program.



FYI, I think you can safely remove the compressor code as the compressor will still run automatically as long as you open a solenoid.

[flemdogmillion]

Originally Posted by Jonathan L.

Just by looking at it, I don't think it should be a problem for the roboRIO to handle. Using Elapsed Time.vi as Mark McLeod said would be a good idea if you really want to know for sure.



I see a Negate function just before the PID's process variable input. I don't know if that's what your looking for.







Visually, it does seam a bit messy. You can fix that by creating subVIs for each function (e.g. Drive.vi, Feeder.vi, Climber.vi, etc.). I wouldn't hesitate to copy the Joystick Get code into each of those VIs. If you end up with two actuators that are strongly related, you can still put those in the same vi. For example, in 2015 we had an elevator that used a motor and a pneumatic piston as a brake. The operator had an up button and a down button. Whenever, the up or down buttons were pressed, the brake would be off and the motor would move in the appropriate direction (assuming it was safe according to limit switches). If neither button was pressed the motor would be off and the brake would be on. That was all a subVI in TeleOp.



Additianaly, you can put most of that code inside a VI that gets reused in autonomous. See our code from last year for an example of that.



Of course there are other ways to organize code. This is just one way that you could easily use without having to learn a whole lot about communication inside a LabVIEW program.







FYI, I think you can safely remove the compressor code as the compressor will still run automatically as long as you open a solenoid.

The compressor code is there to turn off the compressor when the climber is enabled.

[billbo911]

Back in the day....(When we used LabView), we had a rule of thumb.
Onlu driving code was included in Teleop.vi. Everything else was run through parallel tasks (periodic task). One key is to make certain the Teleop.vi is not waiting for a parallel task to complete.
Trigger tasks from within teleop.vi if you want, but don't wait on them to complete.