Hi gents,
I’m deep into 3D printing, mainly with RRF and Duet3D products. Over there we are currently discussing if and how to implement simpleFOC into the RRF ecosystem.
Duet3D already has a magnetic filament sensor which runs on i2c and there’s also a BLDC filament extruder using the sFOC-mini. (and AMT-103 sensor)
Now I want to combine the filament monitor with the BLDC-extruder:
Questions:
I was wondering how fast a closed loop BLDC-stepper driver would poll the i2c bus?
Would it react on interrupts?
How does initialisation of the motor work without hall sensors (flipping back and forth, reading backEMF?)
Does it require an index signal?
Has simpleFOC been integrated in any 3D-printer yet? I checked RRF and Klipper only and both aren’t supporting it.
Duet3D has a toolboard with SAM-C21 mcu, is that mcu supported (I read about SAM-D21, but what’s the difference?)
Thanks for reading and excuse me, if I asked questions already answered. I have to readup alot in the next few days…
This would be configured- the microcontroller would both be responsible for running simpleFOC + the I2C interface. The bus speed could be as fast as you like (within reason).
I’m not sure what you mean by this? Depending on what micro you pick, any pin could be an interrupt. This is not really a simpleFOC thing to manage, I think.
There are many different types of position sensors. The AMT one you mentioned earlier is ABZ type (quadrature + index). You could also use a magnetic sensor or find a way to mount hall sensors. This would be a design choice.
No, but it supports it.
I think a few people on the board have looked at making a sfoc Klipper node firmware, but I don’t think it went anywhere yet.
SimpleFOC takes a lot of processing power and you would need a separate microcontroller running the motor control software, and talking to your mainboard over I2C. It would not be possible to run SFOC on the same board as the printer firmware.
I’ve been thinking of making a similar extruder, though based on rq3’s VDE-100 with one flange bearing sharpened into a knife roller and two regular bearings to hold the filament against it. And linear hall sensors instead of the encoder (lighter weight and lower cost).
Yes, I2C can operate via interrupts on ATmega328P. You could also use step/dir interface so the printer firmware sees it as a normal stepper, and internally have the SimpleFOC program convert the steps to a position in radians to run the closed loop control. But you may run into trouble with excessively high interrupt frequency eating up all your CPU time, especially with the AMT-103 which also generates up to 2048 interrupts per revolution (and will lose position if any of them are missed). But it might work if you set the AMT-103 to lower resolution, reduce the steps per mm in the 3D printer firmware, and don’t use high retraction speed.
Better still, use a faster CPU like Valentine’s Mosquito Mosquito Board / New design
I’m pretty sure it can also use the STM32HWEncoder class in the SimpleFOC-drivers repository, which will track the AMT-103 position without the use of interrupts.
SimpleFOC doesn’t yet support sensorless back EMF commutation, and it wouldn’t be useful for this sort of low speed control anyway. Open loop mode is “driving blind” like stepper motors do, and it would work but doesn’t give as high torque or efficiency as closed loop control. With closed loop, SimpleFOC will turn the motor back and forth a bit at startup for calibration, but you can save the settings so it doesn’t have to be done every time (important for an extruder, which can’t move at startup when the filament hasn’t been melted yet).
Not that I’ve seen. But as said, you can use step/dir communication so the printer firmware doesn’t have to explicitly support it.
One more thing to be aware of is that SimpleFOC will run into trouble with floating point precision if you keep increasing the position long enough. This could rear its head toward the end of a long print, which would be very frustrating. Probably will need to figure some way to wrap the position back toward zero when it gets large.
Thanks for the warm welcome,
The idea is to make a dedicated toolboard for each BLDC extruder. It would communicate with the maincontroller via CAN-FD. That’s why the SAM-C21 is part of the RRF ecosystem.
But they also support RP2040, which (I think) could use it’s state-machines for interupt-handling of the encoder? The toolboard will mainly drive the motor and control filament temp, hotend-heater and fans. Not sure if that’s too much extra work?
The VDE-100 is also part of the discussion over here, but IMHO grinding the flanges of a bearing is not exactly business-friendly.
Finding small stepper motors with a hollow shaft or using gimbal BLDC motors are the challenges we conquer. Some say, the stepper will get too hot and melt or soften the filament too much.
I’m with @dekutree64 here, you should probably implement this using the StepDir interface. This way, the simpleFOC stuff is abstracted away from the mainboard, which also frees you from having to use any specific MCU and you could pick smaller/ cheaper chips. So you would have one board which mounts directly to the BLDC, which has power, ground, and four signal wires (pretending to be a stepper), and then you connect it to your regular RRF toolboard or the mainboard.
The simpleFOC firmware requires a lot of processing power and you will not be able to both run the motor control and a real-time RRF on the same chip so this feels like a natural reason to split the two apart.
Depending on the complexity of the RRF CAN API you could also just talk directly to the board running simpleFOC using CAN, but if you also want things like temperature sensors, PWM fans, etc, then I think you would be better off with a separate toolboard with RRF and separate BLDC driver with simpleFOC.
EDIT: actually, what you could do is just a single board, but have two microcontrollers on it - one for RRF and one for SFOC. This means less connectors, less wires, less room for EMI issues. You would just wire the RRF extruder stepper logic-level pins directly to the secondary micro.
Lots of stuff I don’t understand here, but just to weigh in, I have thought that an efficient power- producing motor i.e. a properly commutated motor like simplFOC is made for, not an open loop stepper motor, makes a lot of sense for a direct drive extruder. I haven’t seen this done anywhere. One guy was going to ridiculous lengths to get the weight of the system down by 3d printing titanium parts. But he was using a stepper motor open loop! Which is ridiculously heavy.
I think it makes sense to explore the use of a highly efficient power producing motor combined with suitable gearing to get the torque needed.
But it only makes sense for a direct drive extruder, which is better generally though.
I agree. The only thing that sticks out to me is that steppers have very high torque at low speeds (like in an extruder). For this to have enough torque to hold and drive the filament you probably need pretty high pole-pair motor, not many of which are small enough to mount on a toolhead.
There are threads in our forum for controlling simpleFOC via CAN using the SimpleCAN library. Might be a starting point?
We support SAMD21, but currently not SAMC21. I’d have to look into what the differences are regarding the motor-control relevant features like timers and ADC.
One key difference for you is that SAMD21 has no CAN peripherals, while SAMC21 does.
We do support RP2040, but it doesn’t have CAN either. It can do CAN via the PIO. There are also encoder drivers for PIO. not sure whether it would have the capability to do both at the same time.
Yeah, unfortunately these MCUs aren’t the best for your purpose, I guess. A nice STM32 with both CAN and motor control features, or an ESP32 perhaps?
I think on the right MCU and with some attention to the code this should be very possible.
We have a library (very new, not well tested!) called SimpleDC for dealing with DC motors like fans. Presumably, you could also use a “1-PWM” driver to control a heating element.
I want to point out, that RRF uses CAN-FD protocol. It might be a minor issue, but the usual CAN-devices (or libraries) don’t work.
RRF also has a CAN-FD light version running on the RP2040 PIO. I believe, this chip would be best used in a co-pro scenario (two mcu’s on one board, like @VIPQualityPost suggested) if it supports encoder reading.
My main concern about daisy-chaining Duet=>simpleFOC-controller=>sFOC-mini is the wire length between the boards and the auxiliary.
Which one is the most critical? i2c-encoder, step/dir/enable, motor wires…
Maybe buying the sFOC-mini wasn’t the best idea, but I read about the mosquito and @David_Leitner board after shopping.
Then there is this general issue with the infinite extrusion length and floating point-math.
I’d like to know where the limits are?
Some FDM printers work non-stop for days and extrude several kg of filament. (1kg equals ~330m filament)
(*) why do you use floating point anyways? There are ways to convert the math to integer without loosing accuracy and it works faster on some mcu’s. Even arduino-IDE should be capable of doing that. But let’s not discuss it here, it’s just a thing that puzzled me.
there are many STM32 controllers which have an FDCAN peripheral. There are a few users on this board who have worked in implementing it (I’m working on it now for my board, @Owen_Williams and @Grizzly both have working FDCAN code).
Yes.
ah, I thought you are planning to design your own toolhead board, in which case RRF MCU and SFOC MCU and the motor driver are all on one PCB. Note there is not really any self-contained “SFOC controller” widely available beyond user designs on this forum.
I usually stay out of the math threads on this board but maybe you can just subtract a revolution from the “true position” every time you rotate past 6.28 rads, so that the physical rotation is the unchanged but the algorithm position ends up being bound to reasonable values.
You should read up the forum post on CORDIC engine here, I think it was discussed in pretty good detail.
I’m trying to convince the devs from Duet3D to do that. But until then, I think I have to go the daisy chain route.
I was used to use Altium for PCB development, but now I’m retired and don’t bother with expensive user licenses anymore. (same for CAD licenses)
Old dogs don’t learn new tricks, but I’ll give it (another) try. My home-PC sucks, too…
I’m afraid, it will not reach the high standards of Duet3Ds boards, so it will never reach public release status.
Finding or making a NEMA14 stepper with hollow shaft is what most people will do, if they want to build a screw-extruder.
Unless I can convince them, that BLDC gimbal motors (like 2804) have more torque or run much cooler.
Time will tell.
I have no experience with CAN, so I can’t help with that part.
Motor wires can be extended without issue, but then the encoder wires get extended too and may pick up noise. But if you put the driver on the extruder, then the long signal wires from the motherboard to driver could pick up noise. Not sure which is more likely to be a problem.
What I was hoping to do is make a version of Mosquito with the footprint of a stepstick. Then there would be no cable from motherboard to driver, and the motor wires could use 3 pins from the regular stepper connector on the motherboard. But the hall sensors would still need a cable going to the driver, so it wouldn’t be perfectly elegant. May end up being nicer to connect the motor wires directly to the driver too, so they can be bundled in a single sleeve with the sensor wires. Noise probably wouldn’t be an issue for linear halls.
Float is used for simplicity’s sake (see how target and shaft_angle are used in BLDCMotor). It certainly can be fixed, we just haven’t settled on which solution to use.
I think float can generally represent about 7 significant digits. If the extruder pushes 1mm per revolution, then for resolution equivalent to 100 steps/mm, that’s 9999999/100/2pi = 15915mm of extrusion before you start losing accuracy. Divide that by 330m/kg and you get about 48 grams. So definitely will need wrapping even for single prints.
Yeah, the NEMA14 pancake is hard to beat. 55 grams, versus 34 grams for a 2804 gimbal. AMT103 is 14 grams, so there’s little advantage for all the extra trouble. My intended 2204 gimbal with hall sensors would probably be around 30 grams including the rollers, but may not have enough torque. Plus mounting hall sensors is annoyingly difficult (hence why I haven’t actually built it yet).
I haven’t done any long prints with high flow rate using the NEMA14, but I doubt it would get hot enough to soften the filament. The big NEMA17 stepper on my old CR-10 does get hot, but that’s pushing 31mm of filament per revolution of the shaft versus 1.4mm per revolution for the VDE-100, so about 22x higher torque, while it probably only weighs about 6x as much. So it’s working a lot harder.
I don’t think drilling shafts and grinding flanges would be any less business-friendly than making those threaded rollers. Maybe easier, since you only need a drill press rather than a lathe. I did have a difficult time drilling the shaft, but rq3 says he can do it in one shot with a 2mm split point drill. I had to go at it from both ends using short carbide drills. My standard length 2mm drills don’t seem to be sharp enough, and flex under the pressure of cutting which causes the hole to wander.
Yes, you have to check the compatibility - STM32 MCUs are mostly CAN-FD capable, its not unusual these days for MCUs to support the faster bitrates.
i2c-encoder → the encoder connection will be the most critical. I would not recommend using I2C as the encoder protocol, by the way. ABZ or SPI will be much better.
i2c for control: less critical, this should work fine, and also over distances up to 50cm-1m.
CAN-FD for control: faster, and longer ranges possible
I don’t see a problem here. I would leave the motor control to SimpleFOC code. You could use position mode, but I basically would not use the SimpleFOC control loops as the filament length management code. I would use SimpleFOC for motor control, and add additional outer control loops to manage your filament length measurement needs. Then you can use double precision maths, integer maths or whatever you want there, and are free to use SimpleFOC in velocity mode, or reset the motor position in position mode.
We still support 8 bit MCUs, and also most 32 bit MCUs we support have single precision FPUs. Double precision floating point maths is only available on quite advanced, expensive MCUs (or more advanced processors, of course).
Switching to integer maths, on the other hand, would make the code very hard to understand for most users. We like to keep the simple in SimpleFOC
I have already ordered 5x1mm stainless steel tubes. I won’t drill the shaft, but replace it. They are usually only pressfit into the rotor. A drop of loctite will help fixing the new shaft.
Cutting threads for rollers is simple CNC stuff (thinking in larger scale), but grinding an edge on a flange is tedious labour. Not even chinese workbench-slaves would be cheap enough nor produce constant quality.
Just a sidenote while waiting for the sFOC-mini to arrive
I’ve installed the simpleFOC library and read some of the example code.
In open-loop velocity control I have to send the speed in rad/s…not very user friendly IMHO
Another thing was the P value for PID tuning: what the heck is 0.02f ?
Yes, all of the setpoints for the controller types (outside of torque?) are in radians. You can just write a conversion if you prefer degrees, just make a function which takes a float angle and returns a float radian.
