God bless the Queen! How about a plugin for Carbide Motion?
1 Like
I donāt know if Carbide Motion supports plugins, I suggested CNCjs because I know itās got a plugin structure and an open code base thatās amenable to extension. Iād be happy to plug into CM too.
Whatever you choose needs to be able to connect to two serial ports at the same time.
Oh and donāt count on me to write it. Iām good with low level stuff.
What do you use on your Shapeoko?
Could your plugin calculate, display, and log input power, output power, MRR, and K-Factor (MRR / Output Power)? Good K-Factors are required for accurate speeds and feeds calculators and a good indicator of cutting efficiency.
Maybe even a force feedback loop to increase cutting speed, decrease feed rate, decrease DOC, and/or decrease WOC to automatically limit force? @fenrus might even find āreal timeā cutting force measurements useful for his adaptive tool paths?
SpaceX launch today? Ironically Tesla is using BLDC motors (rather than AC induction motors) in their new Model 3 (change companyās name to Edison)?
I have used Carbide Motion so far but have installed CNCjs and am just starting to figure out how to use it.
I donāt currently speak JavaScript so Iād need to either learn enough to be dangerous or work with somebody who does to make a suitable plugin for CNCjs. My Python is good, my C++ is usable on Arduino level hardware.
I would say the first step is to get the power and current data out of both the VESC and HuanYang VFD motor options in a reasonably consistent manner. Obviously for the VFD this is going to be a bit harder as output current does not tell us much useful about motor torque current so we need to do some additional calculations and we need a real power into the drive meter on the AC line feed to the VFD.
Second step is for us to apply our losses models (with some tested params for the given spindle / BLDC motor) to that data to get a reasonable estimate of the motor mechanical torque and power. The temperature sensors in the BLDC motors become key at this point and Iām going to find out whether we can usefully infer anything about the VFD spindle temps from the return water temps when my sensors turn up. This is probably where the Arduino level stuff should hand over to CM or CNCjs.
I think it would be OK (but weāll need to prototype and test) to plug a basic display into the Arduino to show motor electrical (RPM, Amps, Power) as well as estimated mechanical (Torque, Power). I think showing the motor internal temps for BLDC or the water flow rate and supply / return temps for a spindle might also be useful. This would also let us put the VFD away in a cabinet with air inlet filters so it doesnāt fill up with sawdust and celebrate new year unexpectedly.
We could also, just at the Arduino, set a āwarning torqueā number and do some sort of alarm to say āyour spindle is working harder than your set max currentā, not sure how useful that would be, but only testing will tell there. Alarms on motor temp might also be useful for those who really push their machines? ( @Vince.Fab )
We then get the data off the Arduino level devices by some suitable mechanism, BT, USB or Ethernet and send it to a larger computer such as a Raspberry Pi or a PC running the CM or CNCjs software where weād log and interpret the data. Data off the Arduino is not something Iāve done before so Iād love to hear from somebody who knows more.
So far as I can see we need to know the cutter params to know what the cutting force is, all we can know at the motor level is torque and power. That means to do any more analysis we really need to be able to talk to the CNC control software which has seen the GCode and knows what tool is loaded etc.
From there, it would seem to be possible to log the motor data and then calculate some processed data points regarding the actual cutting force, MRR etc. if we have sufficient knowledge of the tool in use.
Automatic feedback to adjust feed rate would be something to go in the āfuturesā bucket I think based on testing and manual use of the real time power and torque displays to adjust feed rates and user observations of how useful this is.
Letās hope Doug gets to the ISS safe and collects that flag he left there when he took that last space shuttle up.
There was an interesting blog post by a Tesla engineer a while ago talking about choosing Induction vs. BLDC.
1 Like
My understanding is that Tesla only recently transitioned to BLDC motors (or PMSRM) as described here. Hereās some info on the Model S.
Wouldnāt just subtracting non-cutting power/torque from cutting power/torque suffice (even be more accurate)?
1 Like
I think weāre saying the same thing here, what the use wants to see is the motor mechanical power / torque, what we can directly measure is the electrical power / current so we need to convert measured to estimated mechanical for display. As we canāt measure the losses directly in real time we need to use the simple losses model to do that.
These are the fault codes the VESC can return:
FAULT_CODE_NONE = 0,
FAULT_CODE_OVER_VOLTAGE,
FAULT_CODE_UNDER_VOLTAGE,
FAULT_CODE_DRV,
FAULT_CODE_ABS_OVER_CURRENT,
FAULT_CODE_OVER_TEMP_FET,
FAULT_CODE_OVER_TEMP_MOTOR,
FAULT_CODE_GATE_DRIVER_OVER_VOLTAGE,
FAULT_CODE_GATE_DRIVER_UNDER_VOLTAGE,
FAULT_CODE_MCU_UNDER_VOLTAGE,
FAULT_CODE_BOOTING_FROM_WATCHDOG_RESET,
FAULT_CODE_ENCODER_SPI,
FAULT_CODE_ENCODER_SINCOS_BELOW_MIN_AMPLITUDE,
FAULT_CODE_ENCODER_SINCOS_ABOVE_MAX_AMPLITUDE,
FAULT_CODE_FLASH_CORRUPTION,
FAULT_CODE_HIGH_OFFSET_CURRENT_SENSOR_1,
FAULT_CODE_HIGH_OFFSET_CURRENT_SENSOR_2,
FAULT_CODE_HIGH_OFFSET_CURRENT_SENSOR_3,
FAULT_CODE_UNBALANCED_CURRENTS,
FAULT_CODE_BRK,
FAULT_CODE_RESOLVER_LOT,
FAULT_CODE_RESOLVER_DOS,
FAULT_CODE_RESOLVER_LOS
Current plan is to just pull the fault pin low to trigger an E-Stop when any fault triggers.
1 Like
Could āFeed Holdā (Pause?) be better/easier? Maybe @DanStory or @Julien know the interface requirements.
You can wire that fault pin to whatever you like. Personally I recommend the E-STOP because if a fault code is reach the VESC immediately stops the motor.
Yep, by the time the VESC has thrown a fault itās probably stop time. I believe thereās a feature request in the queue for CM to restart a job partway through if the fault turns out to be recoverable.
I guess Iām confused again - sorry. Doesnāt E-Stop require killing power to at least the stepper motors (a power relay)?
Depends if it is a hard or soft E-Stop system. A hard stop is basically cutting power to everything. Soft stop is basically pause the job and lift the tool up and out of the way of the work. Hard stop is the safest but there is no recovery. Soft stop is less safe but you may be able to recover assuming your work piece has not shifted and your steppers have not lost steps. Personally this is one of the reasons I plan at some point to upgrade my Shapeoko to use a Duet Wifi board. It uses Trinamic stepper drivers so it knows if it lost steps and how to compensate.
1 Like
So the way I have the code for the DutyCycle to RPM mapping done the DutyCycle can range from 1 to 255. I plan to have the mapping be something like this for testing purposes:
1-20 = 0 RPM
21-23 = 5000 RPM
24-26 = 5500 RPM
27-29 = 6000 RPM
30-32 = 6500 RPM
ā¦
195-197 = 34000 RPM
198-200 = 34500 RPM
201-255 = 35000 RPM
The steps of 3 in the Duty Cycle to RPM is because I am not sure how spot on accurate the calculation of the duty cycle is going to be. The steps of 500 RPM just seemed like a reasonable value for me though I am basically a noob when it comes to actual CNC work. The room at the bottom and top of the duty cycle range is so there is room for expansion. This whole mapping will be able to be tuned as well in the Arduino IDE.
1 Like
Quick question, how happy is the BLDC to run slowly, as in 500-1000 RPM?
I ask because this is the sort of range that a wiggler or edge finder can be useful assuming you can fit one in your collet.
1 Like
No problems running 500-1000rpm over here
500rpm steps should be fine for most anyone imo.
Until I have the thing making chips and am able to monitor it, I want to keep the RPM band conservative. I would love to have the RPM band be 250 - 50000 on the thing (though that might require a VESC 6 instead of a VESC 4). Just do not want to put something out in the wild that could possibly damage the tool.
1 Like
Well I have my code at the point where it SHOULD work. Just need the Carbide board to test with.
1 Like
The current CM boards appear to support both E-Stop and Feed_Hold (āSoftā but fast stop?).
If you figured out the correct Hall sensor connections, how did you do it?
Do you know if your VESC (Ver. 4.*?) likely expects 10k NTC temperature sensors for the motor like the newer Ver. 6.*?
1 Like
Is the hall connection even worth it? Running sensorless has been pretty straightforward.
The vesc also has options for NTC 10K, PTC 1K at 100c, and KTY83/122