[Greg McKaskle]

My responses are marked with **.


*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?

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

** Wait and Wait ms Multiple (WMM) are closely related functions that implement different policies for late starts.
** Wait doesn't attempt to catch up. It sleeps the wired amount every time it is called. The OS may not awaken it on time, but it doesn't try to outsmart or adapt.
** WMM does some simple calculation to align itself with the system clock. If wired with 10, WMM will look at the remainder of the system clock/10 and will try to awaken on the 10-ticks of the clock. Its policy is that short sleeps are an acceptable way get the schedule back in phase. An odd side-effect of this is that the first sleep may be 1ms. If something causes it to miss entire periods, it doesn't not try to recover those, only partial misses.
** Your diagram can do your own scheduling math if you like, and then simply call the Wait function. That would be equivalent to the WMM.
** By the way, the uber-scheduler is the timed-loop. If you double-click, or right click and configure, the lower right corner includes policy for what to do with missed periods, phase alignment, offset, and even the clocking source.
** Note that I'm answering the questions more for informational purposes. I doubt this is contributing to the lag of the robot. Clearly timing errors can impact control, but none of this will make up for code that is far-far off schedule.

*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).

** This is correct. All regular loops within a VI inherit the VI's priority, and the VI typically inherits the caller's priority. Each subVI can specify a priority if you go to VI Properties >> Execution tab. The timed loop also has a priority specification.

*Does TeleOp runs by default at the same priority as Periodic Tasks vi. How do we you you find this out, documentation from Lab View?

** Inspect the VI Properties to verify. By default, all team code is at normal priority, as priorities were considered an advanced topic that we didn't want to require teams to understand in order to get started.

* 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?

** I may be able to help if I knew what the errors were. I was at San Antonio regional on Thursday, and the "it worked fine in our shop" phrase is very common. That is often due to insufficient testing. Many of those robots had wiring issues, coding issues, etc. One thing I'll suggest again is to run the robot through a DS practice match. Teams using only the Teleop and Auto modes of the DS are often surprised by the field as it transitions them from auto to disabled to tele. The robots that don't leave auto, or no longer have resources open in tele are usually ferreted out by a single practice mode test. I'll be happy to answer more questions if you have details of the errors that cropped up.

Greg McKaskle