MC-2100 Control Algorithms – What I’ve learned so far…

I was helped out immensely by receiving a reverse engineered schematic of the MC-2100. That enabled me to examine and begin to understand how the hardware of the controller worked together to control the motor. However, it didn’t have much to say about the algorithms contained in the Cypress PSoC serving as the controller’s brain.

Throughout the process of developing a control circuit to drive the controller, I’ve learned quite a bit about the software in the PSoC, and I’d like to share the information. The best way I can think to accomplish that is to document the timeline of my testing, and comment on the results. There’s a lot to read here, but if you’re trying to figure this thing out, I think it will be helpful. Here goes!

Test conditions and results in roughly chronological order:

1. Running a motor (in the lathe) without speed feedback

Operated normally as best I could tell. This was using an early version of the standalone PWM circuit.

I’ll find out later that the tach input is used for speed feedback by the controller. The MC-60 I’ve used before doesn’t use the tach at all, so I didn’t think to hook it up.

2. Testing the MC-2100 on the bench with no motor or tach connected

No function. Status LED remained solid indicating AC power but no control signal from dash. 0% duty cycle (no voltage) at the motor terminals. After troubleshooting everything I could think of, replacing components on the MC-2100, etc., I eventually plugged a motor in and it fired right up.

Apparently the MC-2100 won’t do anything unless it senses current through the motor. That made sense I guess, which lead me to my next bright idea…

3. Bench testing with a large value resistor (10k?) across the motor terminals, no tach

The status LED blinked rapidly indicating control signal received. The duty cycle of voltage across the motor terminals varied with control signal duty cycle.

Apparently functioning normally. I figured this way I could test the controller without a big spinning flywheel on my desk. I tested in this way for a while, working the bugs out of my standalone circuit.

4. Bench testing with a motor connected (after above resistor testing), no tach

Once I got the bugs worked out of my circuit, it was time to test with the motor connected to make sure everything was working. The LED would begin to blink quickly indicating signal received, but shortly after the motor started, the LED would blink slowly indicating operation at or near current limit, and duty cycle of the motor voltage would be reduced, stopping the motor. Resetting the control signal to zero was necessary before the motor voltage would increase again. At very low control signal duty cycle (low motor target speed), the motor would turn without tripping the over current, but at erratic (slow) speed.

At this point, I theorized that the MC-2100 has closed loop speed control with an adaptive algorithm to tune the control constants. I must have messed up the control constants by running with the resistor in place of the motor. Basically, the controller changed it’s definition of current overload to be much lower, because “normal” current for a given voltage through the resistor was very low. Connecting the motor resulted in much higher currents, tripping the alarm. There was also no speed feedback to inform the controller that the motor was actually functioning correctly, not stalled and overheating. I assume condition 1 worked OK because the current limit hadn’t been messed up yet, so the MC-2100 just assumed the reed switch had gone bad.

5. Bench testing with motor and tach directly reading motor RPM

Better performance than above test. Sensitivity to current limit seemed to reduce with time. Response to step change in control signal still had significant overshoot, with high settling time.

Testing with the tach connected seemed to desensitize the current limit, but not remove it. My theory was that the controller would eventually adapt to the new current demand of the motor once it had feedback that the motor was spinning. This seemed true to an extent, maybe it just needs more time?

6. Programmed ramp testing with motor and direct tach (Arduino based ramped cycle testing)

Speed ramped from 0 to ~20% for 10sec, held for 15, then ramped back down and held at 0 for 15sec.

I let the controller run this cycle off and on for several days. Step response characteristics improved, but were still unsatisfactory. I was able to command higher steady state speeds without tripping the current limit as well. At this point, I became impatient and just wanted to finish the project, so I bought a replacement MC-2100 on ebay 🙂

7. New (used) MC-2100 testing with motor and direct tach

First test with new controller resulted in shutdowns shortly after motor start. Similar to case 4 above, but not identical.

My assumption here is that the default control constants expect a ~2:1 speed reduction through the treadmill drive belt. Directly reading the motor speed made the MC-2100 think the motor was running away. I decided to more directly replicate the treadmill environment to see if it would help.

8. New (used) MC-2100 testing with motor and half speed tach

I used Arduino to output a tach pulse to the MC-2100 at half motor speed (comparable to actual treadmill installation). Normal motor function resulted. Good step response, little to no speed fluctuation. Response to torque disturbances untested at this point.

This is the current state of development. I’m working on finalizing the arduino compatible control and speed readout circuit and enclosure, as well as mounting reed switches to my lathe. I’m curious to see if the controller responds well to the motor I’m using in the lathe, as it’s larger than the motor I’ve been testing with up till now.