these are probably mostly limitations imposed by the silicon of the drivers themselves, as they really kind of are ‘analog’ chips. The ESP32 runs pretty fast so I think catching 2.5ms events would be fine.
Are you sure that’s not 2.5 microseconds? I think steppers often run in the tens of thousands of steps per second, and 2.5ms per step is only 400 steps per second.
What is ESP32’s CPU frequency? Uno runs at 16MHz, so 2.5 microseconds is only 40 cycles and would probably miss interrupts, but if ESP32 is over 100MHz it might be ok.
To get an exact safe limit you have to figure out what is the longest possible time for interrupts to be blocked in your program. If the step pin is the only interrupt source, then you only need to measure the time it takes to process that interrupt, which is probably not more than a couple hundred cycles.
Yeah the pulse inputs on a CNC stepper driver are very fast, because microstepping is often used. That multiplies the steps per 1/200th of a rotation by a factor of a great many, usually 16 at least, and up to 256.
This is difficult, even minor timing issues will likely lead to artifacts in your prints. I have learned a lot about 3d printing in the last couple years and before that I was a CNC machine technician doing milling stuff. I’m sure you can do it but it will be a lot of work.
You could just count the pulses with some kind of hardware perhaps and then the software does what it needs to do and decrements the counter. So it takes a short time to catch up, but the PID loops will also insert similar delays and so on. Servo based CNC machines always seemed to work fine though so I see no problem with this but ultimately still advise the use of a TMC2209 stepper driver or similar, overall, with coolstep or step loss detection etc. to detect load on the motor and increase current or compensate.
Open loop is a pretty reasonable approach for a printer.
Yes, sorry it’s microseconds…the first 3D printers were running on ATmega2560, and they were capable of controlling 200x16 microsteps
The ESP32 runs at 240MHz. 15x faster.
They were capable of outputting that much, using pwm peripherals or bit banging. Accepting pulses as inputs is different. There may be hardware for pulse counting however which you could use.
For the AS5048A there is a precise sensor definition and also a preciseAngle method to avoid overflowing variables.
I want to use that, but I have no clue, where to put the preciseAngle stuff?
Is it this line?
motor.controller = MotionControlType::preciseAngle
That’s a work in progress. The motor target and PID and low-pass filters all need to be upgraded to use it somehow, which is not easy.
I tried to commuicate between ESP32 and the Duet controller via the step-dir listener.
I got some reaction, but it looked more like it would reset the driver. It did the initial sensor-align thing over and over again.
My question: do I have to declare the step/dir pins as inputs in the esp32-program or is it done automatically?
The preciseAngle functionality has since been implemented into the standard sensor class.
You can call sensor.getMechanicalAngle() to get the precise float angle within the current revolution, sensor.getFullRotations() to get the rotations with 32bit precision, or sensor.getPreciseAngle() to get the absolute angle, including full rotations, in radians, as a double.
No need to use the PreciseAngle class anymore…
The pins are initialized into INPUT mode in the StepDirListener.init() method.
I’m a bit confused about the &target stuff. In other examples it is often called target_angle
With an SPI sensor, wouldn’t I need the asynchronous call:
// attach the variable to be updated on each step (optional)
// the same can be done asynchronously by caling motor.move(step_dir.getValue());
step_dir.attach(&motor.target);
// or is it (&motor.target_angle) ??
I’ll try out both
Hey,
The StepDirListener sets the value to the given float-pointer location.
So you can use motor.target to directly set the target value on the motor.
Or you could declare a variable float target_value; (or any other name) and then pass this to StepDirListener: step_dir.attach(&target_value); and to the motor: motor.move(target_value);.
This second approach is better, because the target value change will happen at a well-defined time from the point of view of the motor, rather than at potentially any time during the algorithm execution if you use the first method.
Yup, I got it running with motor.move(target_value);
It makes sense using this method for any sensor that doesn’t use interrupt AB interface, I guess…
Thanks again
Olaf
I’ve done some testing of the BLDC extruder in my Delta printer.
Sometimes the initialization fails. The motor isn’t energized. I have to toggle power to the ESP.
Because it is wired in the printer, I can’t use USB-monitoring.
I suspect the power train as issue.
The printer and sFOC mini driver are directly connected to 24V PSU, but the ESP32 gets 5V power from the Duet3d controller. The ESP then feeds the sensor with 3.3V. I’ve added a 10uF cap there.
All components are on the same GND.
Is there a known issue with the power chain? A specific order to power them?
I guess, I can simply add a delay before I init each of the components, but I’d like to know what’s going on…
The monitoring can be on any serial interface- you can use a USB-UART converter to still read output, if you have access to some uart tx/rx pins. What board/ set of boards did you end up using to drive the motor?
I could see how if the motor is bound, it will fail to init. Are you providing the electrical zero + sensor dir before init or are you letting motor.initFOC() just do calibration from scratch?
That’s a problem with a cold hotend, you can’t move much. I’d have to heat it first before powering the ESP, but all MOSFet-PWM ports on my Duet3d are in use.
I have just read about angle-calibration, I initialize from scratch. Would it still move the motor back and fro, if I had a zero-calibration included?
PS: Could I use the WiFi chip of the ESP32 to communicate with sFOC-studio or even flash new firmware? (I read about the OTA feature, but never tried)
Run the auto-calibration without any filament loaded and save the zero angle and sensor direction. If you pass them to motor.initFOC it won’t move the motor back and forth. You only need to redo the calibration if you change the physical configuration (order of the motor wires or orientation of the sensor relative to the rotor magnets).
Possibly? But wifi can be pretty interrrupt heavy, so you might end up with erratic motor movement or failed webserial packets.
Like @dekutree64 says, if you pass the start parameters before running initFOC, then it will not move, so you don’t need to worry about having the hotend at temp before starting.
My hope is that the whole WiFi stuff runs on the other core. There are plenty of ESP32 programs using WiFi and HTTP-traffic doesn’t seem to reduce the performance.
That’s good news Thanks for the confirmation.
I’m glad, I have used connectors between Duet and ESP. Makes it easier to disassemble it.
My printer is too far away from any PC. I can handle it via WiFi, but not the sFOC part.