[ldeffenb]

Kevin,

Given the structure of the code in main() surrounding the modal invocations and the position of the getdata() calls, it appears to me that the new code structure actually invokes the previous mode with the new mode's getdata() results immediately after a mode switch.

Consider: robot is in disable, rcdata has that fact recorded, hybrid begins. main() detects disabled mode, detects that new data is available, calls getdata() receiving the new autonomous flag but invokes disabled() anway. Autonomous_init() and Autonomous() doesn't get called until the NEXT command packet, 26.2msec later.

I've not done it yet, but I'm planning to restructure our main() to something like this (just pseudo code, not real code):

main loop:

if (new data available)
{ getdata();
set newdata flag;
}
if (...mode...)
{
all of the existing mode_init and mode() calls here, but no getdata or putdata() calls
}
if (newdata flag)
{ putdata();
}

goto main loop:

With this structure, the newly gotten mode is the one checked and invoked with the getdata() packet.

I hope to first prove this with a mode-checking printf in one (or all) of the _init() routine that check if the mode we're in is reflected in rcdata (hidden by the #defines for the mode flags). I suspect it is not.

Lynn (D) - Team Voltage 386 Software

PS. This also makes our new always_before(), always_after(), and always_spin MUCH easier to hook in, now that I've written it out! always_before() right after the getdata(), always_after() just before the putdata(), and always_spin, well, always in the loop!