Please Help Compiled info Teleop Periodic Task need verification

[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.