Hi Folks,
Designing an electric dental handpiece (drill).
There are essentially 2 modes - 1 for cavity prep, which is usually run at high speed, and doesn't require much torque;
the other is called Endo mode, which is used for endodontic procedures (mostly root canal).
I'm running into a problem with the Endo Mode.
There are 3 Endo features, all of them dependent on a parameter called Torque Limit, or Torque Threshold.
1. Auto Stop - which stops the motor when the Torque threshold is exceeded.
2. Auto Reverse - which backs the bur (how we refer to the drill bit) out of whatever it's in, again when the Torque Limit is breached.
3. Auto Reverse/Forward - which puts the motor in reverse for 3 seconds, when the Torque Limit is exceeded; then runs forward again.
The torque threshold goes from a minimum of 0.3 Ncm up to a max of 3.0 Ncm (Newton-Centimeters).
The speed can be set anywhere from 100 rpm to 40,000 rpm.
All three of these features work reasonably well when the debugger is hooked up, and I'm running the program from Code Composer.
When the program is run from FLASH, however, as a stand-alone device, it behaves quite differently.
When I select AUTO STOP:
When the debugger is running, the minimum speed that reacts to a 0.3 Ncm torque is 500 rpm. The motor won't stop in response to an applied
load, until the speed is 500 rpm or greater. In other words, the motor is not capable of exceeding the 0.3 Nm threshold, unless it's going
500 rpm, or faster. This is not ideal, but it's just a limitation of the motor. I can live with that.
When code is being executed from FLASH, and 0.3 Ncm is selected as the torque threshold, every speed reacts not only to an applied load,
but stops in response to just the load supplied by the handpiece itself. The thing just doesn't move, unless I change the torque
limit to 0.7 Ncm, or greater.
I can understand some differences in how the system reacts when run from the Debugger vs. stand-alone, but this is kind of extreme.
I feel like I must be doing something wrong, or the A to D is providing quite different values, depending only on whether the code
is being deployed in debug or from FLASH.
There is another anomaly in addition the one described above.
We can't have the drill running backward on start-up, when it's told to go forward (and vice-versa). Didn't want to go through the
rigamarole of implementing high frequency injection (I don't think I understand it anyway).
So, we opted for a controlled stop, so that the motor always ends up at or near the zero position. That way, the controls know where it is
on start-up, and it can zip right up to speed, going in the proper direction.
This works really well when the debugger is hooked up and running the show. When I power the system up as a stand-alone device, I get that
back and forth dance when the motor starts up.
Can you help me?
Thanks,
Dave
