Both Makita and Milwaukee apparently think it is. My guess is that the speed control response is faster when the load changes - but its just a guess.
Im pretty sure we can control the speed control response with PID control on the VESC. Even with stock defaults it seems pretty responsive.
I was actually thinking of doing some test cutting with manual control and seeing what the logs look like.
(I wouldnāt want to interrupt such a great thread, so just FYI: starting v2.4 the E-stop is not accessible on CM boards anymore. Feed hold is still there)
1 Like
What does it do and do you know itās interface requirements?
Itās a NO switch and does this when triggered.
1 Like
Cool - it does just what it says, except inverted and likely pulled up to 3.3 or 5V with a resistor. Is there a schematic available for that PCB?
The Hall sensors allow the controller to accurately keep track of the rotorās position under all load conditions. So it knows which winding to drive at any given time under all load and speed conditions without any calculations. They essentially replace the brush function in brushed motors with electronic switches. Nothing else will be as fast or accurate as using them.
Sensor less BLDC controllers use the back EMF from the windings to calculate where the rotor is. Thereās no back EMF when the motor is stopped, so the motor has to turn at some minimum speed to run. They work best under constant speed and load conditions and are inherently slow to respond to changes in either. Proportional feedback (P) speed controllers can respond fairly quickly to both types of changes, but they require some error to work. Adding an integrator in the speed controllerās feedback loop (PI) can eliminate the error at the expense of response time. Adding a differentiator to the feedback loop (PID) can speed the PI loop up at the expense of instability. Because of that potential instability they work best with stable loads (like with elevators.)
Iām struggling to understand why manual speed control and monitoring from the VESC software or App isnāt adequate. Other than the Feed_Hold function, it seems to provide everything thatās really required at minimal expense and hassle. What am I missing?
Will you be using the the stock housing and fan for your tests? Will you be monitoring motor stator and housing temperature? Will you share your results?
Its my understanding that hall sensors arenāt the best for high rpm, which is probably why the vesc has a hybrid option. After adjusting the BEMF, startup wasnāt an issue with sensorless.
I tested 5krpm with a manual load in rpm mode and the motor pulled up to max input amps pretty good and strong like.
Fully automated control would be ideal.
Been running fanless ever since testing started. Adaptive roughing produces pretty stable loads.
Yup, but it sounds like thatās not eminent. Maybe modifying the VESC Tool is the easiest path to getting there @LiamN?
The hall sensors are used at lower RPMs. Above 4k RPM the hall sensors are ignored by the VESC. However if you want to do a drilling operation at 500 RPM, the hall sensors will allow the system to operate properly.
2 Likes
It supports three different options for temperature sensors. They are not required though by the VESC. My board will throw a temperature fault though if it does not see one in the output.
1 Like
My Shapeoko is scheduled to arrive tomorrow. I plan on assembling it, making a few chips with the stock ESC on my Makita for funs, then switch out to the VESC and test my code. I expect to have something working properly by the end of the week.
2 Likes
Did you make or buy a mounting bracket for it?
I selected the mounting bracket for a Makita when buying it. The BLDC version has the same diameter as the brushed version.
1 Like
Sorry, I donāt quite follow, what do we mean by fully automated control?
I assume he meant force feedback control of speed, feedrate, DOC, and/or WOC.
Well in that case, yes, weād need some glue between the VESC and the GCode sender, the VESC app might be a good place to start, really depends on what GCode sender we want to plug into.
As all those GCode senders Iāve seen (CM, CNCjs, UGS) have a pre-compiled toolpath from a CAM tool weāre not going to be changing depth or width of cut, only RPM or feedrate in this loop.
A little Arduino would give a dedicated device quite easily, or use a full Windows app like the VESC tool. For manual use either would be fine so far as I can tell, for integration to a CGode sender, weād need to choose the sender and then work back from there based on the requirements.
1 Like
Controlling speed and feed rate would likely be the best starting point anyway, and maybe even be all thatās required.
1 Like
Yep, letās try it out with display of cutting torque and motor power for a user to respond to first, maybe log it and see whether we think thatās enough info on a machine of this type to override feed rates with.
1 Like
So come to find out current_motor is actually avgMotorCurrent. Not sure how that average is calculated. Like average since it was powered on. Average over the last minute. Average since last ārechargeā etc.
Also I am pretty sure that conversion is missing something. Isnāt torque related to the Wattage ie (Voltage * Current)?