Mindboards

I also don't understand. I may have not followed up with you on something a while back? I don't recall. If so, I apologize.

The PwnFreq field in the standard firmware was not used. It is used now (iirc) for the Position Regulation feature that was implemented by Nicolas Schodet.

John Hansen

I thought that was the update frequency you could adjust, not the PWM frequency.

What is MotorPwnFreq for? How can you set the frequency, instead of just reading it, or does it return something else (duty cycle, update rate etc.)? Also, shouldn't it be MotorPwmFreq?

Hi everybody

It's a bit late for me to jump in, but I've done many many tests on this subject, so I'd like to share my experience. I won't go into too many details right now, but just tell you my personal conclusions:

1) The Ramp up and Ramp Down features of the firmware are extremely difficult to use. You have to get the timing right of when the ramp up or the ramp down phases end to set a new output mode, and I think I remember the problem were discontinuities between these transitions (i.e. when you switch from ramp up to "normal speed", and when you switch from normal speed to ramp down, etc.) were a problem. I just remember that a solution which would allow all possible combinations with REGMODE_SPEED and REGMODE_SYNC and precise braking to a tacholimit didn't work.

I was surprised however to see that NXT-G's MOVE-block does use Ramp Down: http://www.mindstorms.rwth-aachen.de/tr ... eBlock.png . But look at the oscillations after the braking (i.e. once power = 0 has been set): It obviously doesn't work that great!

2) When you want to control the motor power manually during runtime, DO NOT USE REGMODE_SPEED. Always disable regulation, then direct motor power control works like a charme. You can set a power value, and the motor/firmware reacts. I've used this in MotorControl for custom ramp up and for the "smooth braking feature", i.e. a position- and speed-based ramp down.

I've got another log of one of my experiments: http://www.mindstorms.rwth-aachen.de/tr ... stance.png

Here you can see the ramp up at the beginning, done by firmware. No complaints here. At the end you see a manual ramp down, where the new motor power is set proportionally to the remaining distance to the target. As you can see, this works nicely (blue line, no overshooting, no oscillations).

After all, in my experience, I can recommend to set motor power manually this way, possible according to passed milliseconds (using GetTickCount()) or based on motor position.

Just for the record, all of this is actively being used in MotorControl, source code is here: http://www.mindstorms.rwth-aachen.de/tr ... torControl , and documentation is here: http://www.mindstorms.rwth-aachen.de/tr ... torControl

mattallen37 wrote:I thought that was the update frequency you could adjust, not the PWM frequency.

What is MotorPwnFreq for? How can you set the frequency, instead of just reading it, or does it return something else (duty cycle, update rate etc.)? Also, shouldn't it be MotorPwmFreq?

I just stuck with the name that exists in the Output module IOMap structure. For some reason it was named PwnFreq and it was also never used anywhere.

In the latest enhanced NBC/NXC firmware this field is now called RegulationTime and I added an additional field to the Output IOMap structure called RegulationOptions. RegulationTime is set to 100 by default (100ms). It is the interval between regulation checks. The RegulationOptions field was added as part of Nicolas' changes for position regulation. You can set the regulation time (which formerly was the PwnFreq field) to any number of milliseconds but 100 is the default and 10 has been tested by Nicolas. In the enhanced firmware the PwnFreq API function should be considered obsolete. I will mark it as such in the help.

It turns out that the OUT_OPTION_RAMPDOWNTOLIMIT option is, in fact, implemented. I was thinking of the OUT_OPTION_HOLDATLIMIT option which is definitely not implemented. If you set the OutputOptions field for an output to OUT_OPTION_RAMPDOWNTOLIMIT then, in theory, it should ramp down from whatever speed you specified when you set the tachometer limit once it reaches 80% of the limit down to zero for the remainder of the limit. It has not been tested widely so it may be buggy.

John Hansen