Please Help Compiled info Teleop Periodic Task need verification

[Ether]

* Teleop is event driven, runs when Data packets are sent, occurs every 20mS

runs when data packets are received by your robot. sent by your Driver Station supposedly every 20ms, but may vary due to Windoze not being a realtime OS. therefore don't bank on the 20ms (i.e. don't base timing calculations such as rate computations on a fixed 20ms)

* If you Have code in teleop that will take more than 20mS, will impact/lag communications to robot

...because your code won't start processing the next DS data packet if it is still stuck in TeleOp from the previous packet.

* Periodic task wait Xms in loop, example 10mS, loop will run minimum required time 10mS, but each loop may vary in time

*To have periodic task run similar time each loop, use 'Wait Until Next Multiple', this is good for task that need to run very regular intervals

See Team 358's whitepaper "Timing Is Everything"

* periodic task wait time: do not want to have wait time too small...

Make it as small as necessary, and as large as tolerable.

...may force labview priority in CPU time sharing and may override task that need more priority?

Not sure what you mean by "need more priority". A higher priority task trumps a lower-priority one.

why put anything in teleop? Why not put all code put in multiple loops periodic task?

If you want the minimum latency between between the receipt of a new DS packet (containing updated driver commands) and the cRIO issuing new commands (to the various actuators on the robot) based on those new driver commands, TeleOp would be the place to put that code, since TeleOp is event-driven. Any code in a Periodic task has a latency based on how long its period is. However, for FRC purposes it probably makes little or no practical difference if the Periodic task is running fast enough.

*Joystick values show up when new control packets (Teleop) arrive, every 20mS? So teleop would be great place to catch the latest joystick events.

... and act* on them if you wish; see above


* or initiate action, in the case of an action (such as an action requiring delays) requiring a state machine or a parallel task

[mbone206]

Thank you Ether and Team 358, Great White Paper

Follow up questions if I may:
*After reading white paper, having 'Wait Until next multiple' is the better wait VI for using camera/servo PID. Will there be penalties if use this Wait VI in all the periodic loops (vs standard wait VI), just sounds better to use all the time?
* Comment on wait time periodic task loop: I am not sure what is 'as small as necessary/large tolerate', how do I determine this?
question on 'need more priority': What I read or possibly interpreted it wrong, *comment on what what mean by priority: if I make one periodic loop 2mS. and one 10mS, this forces LabView to give more priority (CPU time) on 2Ms loop than 10mS, also may force more critical task at a lower priority (less CPU time allocated for more critical task, say Teleop??)
* Good explanation on teleop or periodic task.... now I believe I fully understand... I think... Based on this: I will move tank drive to teleop, using victors, controlled by joystick, since victors update 100hz and teleop running 50hz (may be longer than 20mS based on expanation of Windows timing), however, I will keep solenoid low gear code in periodic task, not sure how fast solenoid/sol. vi will update, or be fast enough for Teleop 20mS, < 50Hz (does that make sense?)
* Can you please give me you input on question, do not see errors running Robot wireless at school in diagnostic window, but get them at competition, how can this be evaluated before competition? Is Field communication system part of the problem and not so much the code in this case?

Thanx again
Mark

[Ether]

*After reading white paper, having 'Wait Until next multiple' is the better wait VI for using camera/servo PID. Will there be penalties if use this Wait VI in all the periodic loops (vs standard wait VI), just sounds better to use all the time?

I was wondering the same thing:

Originally Posted by Ether

What's the downside of "Wait Until Next Multiple" ? When would you ever want to use "Wait" instead?

If anyone knows the answer would you please post?

* Comment on wait time periodic task loop: I am not sure what is 'as small as necessary/large tolerate', how do I determine this?

It's your call. If you put your DS command processing/output into a Periodic Task, and use a period of 5 seconds (I'm being ridiculous here to make a point), then that's obviously not "as small as necessary" to get acceptable response to driver commands. On the other hand, if you use a period of 1 millisecond, that's certainly not "as large as tolerable": you could double that period and the driver wouldn't notice any difference.

if I make one periodic loop 2mS. and one 10mS, this forces LabView to give more priority (CPU time) on 2Ms loop than 10mS,

LabVIEW does not automatically assign rate-monotonic priorities to parallel tasks in the Periodic Tasks vi. By default, all the parallel tasks in the Periodic Tasks vi are the same priority, regardless of their period (LabVIEW gurus please correct me if this is wrong).

...also may force more critical task at a lower priority (less CPU time allocated for more critical task, say Teleop??)

I believe TeleOp runs by default at the same priority as Periodic Tasks vi.
If a parallel task is truly "more critical", you should assign it a higher priority. But be careful: any parallel tasks of lower priority will not receive any CPU time while a higher priority parallel task is running.

* Can you please give me you input on question, do not see errors running Robot wireless at school in diagnostic window, but get them at competition, how can this be evaluated before competition? Is Field communication system part of the problem and not so much the code in this case?

Can't help you there. Maybe someone else can weigh in.