It is my understanding that @Vince.Fab is currently setting the duty cycle of the VESC to get close to the desired RPM. He would need to chime in to confirm. This is why his RPM drops so much under load. There is nothing to raise the duty cycle back up to compensate. But yes if @Moded1952 wanted to us a VESC he can do what @Vince.Fab is doing. It just takes away functionality from the Nomad. Mainly the ability to set the RPM.
With the ODrive I am telling it I want the Ve to be 2100 (about 10k RPM) and it is maintaining that for me. It still needs its internal PID controller adjusted to better maintain the RPM under load, but once that is done it should stay almost spot on under load (assuming it does not run out of current).
The VESC is manual control but can be set with duty cycle, rpm speed control or input amperage. The rpm drop when using speed control mode is negligible, in fact its probably more accurate than the stock Nomad target rpm.
Keep in mind I havenāt done any PID tuning yet and real world rpm drop was around 200ish when cutting metal. That means chip thickness would increase very very small amounts.
Workflow really isnāt bad, you just click on/off from a different window on your computer. However if the ODrive can run it automatically with a feedhold output signal on spindle fault then there really isnāt a reason to use a VESC unless you already have one or you ar just going to run manual control and like the nice, more user friendly interface. Seeing everything in realtime is also a benefit on the VESC side.
1 Like
Thatās right. The problem with speed control from the arduino was that there would be two PID controllers trying to maintain the speed and fighting each other which is dangerous
Hmm, I might be a bit confused about what youāre doing.
My assumption was that you were connecting the VESC to a regular controller and using the VESC tool to record data from the VESC. That data was then handed over to @gmack who did his wizardry on it.
It sounds like rather than that, youāve hooked up a bunch of stuff to an Arduino and youāre using that to collect the data?
My intent was just to hook up the VESCās ADC input to the DAC output of my CNC controller, but sounds like thatās something completely different.
Oh and regarding ODrive, my obsession, like always, is noise. My hope is that the VESC, possibly with FOC, might drive the motor much quieter than the McGillicutty.
1 Like
IMO seeing things like VESC input current as well as motor speed, current, and temperature in real time is far more useful than being able to use software to set speed and having it accurately maintained with an inherently unstable PID controller. The recorded data contains both speed and current, which is all thatās required to calculate cutting power and forces (given cutter diameter).
I tried doing this. The VESCās ADC is 3.3V and is not 5V tolerant. The Carbide board is 5V and super noisy from all the stepper motors. As a result the value on the ADC was all over the place.
The ODrive is only FOC.
That was also part of my logic @gmack, all that data and tooling looks really nice.
@CthulhuLabs Iām not using the Nomadās electronics, Iām using another controller that uses a DAC instead of PWM, so I can tell it to output precisely 3.3V and never higher.
And it looks like the ODrive probably isnāt an option. The docs seem to say you need an encoder and Iām not sure where Iād put one on the Nomadās motor. The VESC on the other hand has sensorless FOC.
I really hope this does not come across as rude, but you really should trust me on this. I am the one who has been doing the research on replacing the Makitaās ESC and am very well versed in the capabilities of both the VESC and the ODrive.
Here is the documentation from ODrive on setting it up to use a sensorless motor:
https://docs.odriverobotics.com/commands.html#setting-up-sensorless
to quote it:
Setting up sensorless
The ODrive can run without encoder/hall feedback, but there is a minimum speed, usually around a few hunderd RPM. However the units of this mode is different from when using an encoder. Velocities are not measured in counts/s, instead it is electrical rad/s. This also applies to the gains. For example,
vel_gainis in units ofA / (rad/s)instead ofA / (count/s).
Also the VESC 4.12 that @Vince.Fab and I have are not rated to go over 60k ERPM. An ERPM is your RPM times the number of pole pairs you have. The Makita has 2 pole pairs. No clue what the Nomad motor has. With the VESC and the Makita you are basically limited to 30k RPM (though I think Vince is trying to live dangerously lol). On top of that they do not recommend running the VESC 4.12 in FOC mode unless you are using a manufacture approved motor. If the motorās back EMF is too high it can fry the VESC. Ask me how I know. The VESC 6s handles FOC better and can handle 150k ERPM, but are also considerably more expensive.
1 Like
I should also mention that my Makita is currently running in sensorless mode. I am just using the Hall sensor for RPM feed back for tuning.
1 Like
Not rude at all, thanks for saving me the trouble of a fried ESC.
Overall I think you will be happier with the ODrive and I am more than happy to help you configure either one.
2 Likes
@Vince.Fab do you still have the original motor for your Nomad? If so mind pulling it apart and checking how many magnets it has on the shaft? That way I can help @Moded1952 to make a Modmad 883 Pro. LOL
I can inspect it no problem, but it will have to wait for a few days until Iām back in town.
IMO heād be much better served going with a Modkita so he could run at 30,000 PPM instead of being limited to 10,000 RPM!
For quiet (when not cutting), he might want to consider a high speed water cooled HF spindle like this one.
It looks like the Nomad motorās maximum speed is likely ~3k RPM - so a 60k ERPM limit probably isnāt a problem.
Not bad ideas but Iād like to put that off until Iām confident I can actually machine the block to hold a larger spindle/router.
A serious disadvantage for that motor? @Vince.Fab apparently isnāt using FOC with his VESC.
FOC has a higher top speed and more importantly efficiency.