#89 ResetRotationCount() does not work without Wait()

compiler
closed-rejected
John Hansen
NXC (53)
5
2011-06-22
2011-01-08
Matthias
No

I have written a test program (see attachment) that powers up the motors for 1 sec, then stops them again. Afterwards the motor rotation counters are printed to the display. Then, after resetting the counters via ResetRotationCount() both are printed to screen again. Unfortunately, resetting does not work "out of the box", afterwards the counters are still the same as before. It seems a Wait(1) command is needed after resetting the counter.

Is this a bug or a feature?

Cheers!

Discussion

  • Matthias
    Matthias
    2011-01-08

    test program

     
    Attachments
  • Jens Erat
    Jens Erat
    2011-01-08

    We're having the same problems, too. I think John Hansen posted about this in some newsgroup, this is a known problem. The reset-functions (and maybe some others, too) return before the counters are reset.

    We're usually resetting the counters and then polling them in an empty while-loop so we're stuck until the counters are reset.

     
  • John Hansen
    John Hansen
    2011-01-08

    • status: open --> open-rejected
     
  • John Hansen
    John Hansen
    2011-01-08

    The behavior of these commands is by design. All motor control functions (except RotateMotor*) simply modify the Output module's IOMap fields and set the UpdateFlag field accordingly. The actual change in motor behavior or, in this case, rotation counter values, is managed by the Output module which won't process the IOMap changes until it gets a chance to execute again. The firmware gives each module an opportunity to execute once every millisecond. So in the VM executing your program it may be that a call to ResetRotationCount comes right before the VM pauses briefly so that other modules can run - in which case the counter will be reset immediately - or the call to ResetRotationCount could come right at the beginning of the 1 ms that the VM allows your program to consume before it pauses for other modules to run. In that case the counter won't actually reset until as much as 1ms has elapsed. Other motor control functions like OnFwd are like this too. They all just call setout which just changes the specified fields in the Output module IOMap. If your program depends on the reset completing before continuing on to the next operation then you need to wait for the output module to do its thing. This will take up to 1ms but usually not any longer than that. Waiting in a loop is also an option but not not recommended unless you stick in a wait but then the wait for 1 ms is all you need so you don't need the loop. You can also use Yield which amounts to the same thing as Wait(MS_1).

    Again, this is by design so that the motor control functions do not introduce 1ms wait times into every NXC program when these waits may not be required in every program.

     
  • Matthias
    Matthias
    2011-01-08

    Thanks, that makes sense, than you can close this bug...
    cheers!

     
  • Matthias
    Matthias
    2011-01-08

    One more thing: maybe you want to add a note explaining that behaviour to your API docs? I spent some time today trying to find out what the heck is wrong with my code -- until I realized that behaviour :)

     
  • km1GEu <a href="http://fvtykwefwcav.com/">fvtykwefwcav</a>, [url=http://ijoqqugdkhkm.com/]ijoqqugdkhkm[/url], [link=http://ibjtqklgrrre.com/]ibjtqklgrrre[/link], http://oyqdbzbugxpe.com/

     
  • John Hansen
    John Hansen
    2011-06-22

    • status: open-rejected --> closed-rejected