I think I’ve also figured out why the MoveTo() calls to move my medium motor return immediately. I do a MoveTo() with a speed of 100 and a position of 2160 (6 rotations). As I trace through the code, I discovered that MoveTo() calls On(speed, degrees, brake, waitForCompletion), which calculates a ramp up and ramp down step count. However, since my number of steps is so high (2160), it creates a large rampUpSteps of 324 steps.
I think the large ramp up time, coupled with a delay I noticed when starting the motors, is responsible for WaitForMotorToStop() not working correctly. WaitForMotorToStop() is implemented as follows:
protected virtual void WaitForMotorToStop()
while ((int) this.output.GetSpeed(this.PortList) != 0);
I think that the large ramp up time and the start-up delay I’ve noticed results in the speed still being 0 after the 350 ms that WaitForMotorToStop() waits before it checks the speed. Therefore it thinks the motor has already stopped when it hasn’t actually started moving.
Before looking at the source code I had tried directly using the SpeedProfileStep() method and specifying the ramp up of only 50 steps. This worked better but was still unreliable. The first time I called it, it always failed to wait. Subsequent calls would usually wait, but occasionally wouldn’t. I’m guessing that the first time, the start-up delay is longer for some reason, and for subsequent calls, it’s right on the edge of the 350 ms.
Anyhow, now that I can see what’s going on inside MonoBrickFirmware.dll, I can work around the issues I’m having. I think I’ll make my own MoveTo method that checks the tacho first to make sure the motor has started moving before it checks the speed to see if it’s stopped.