Open kablek opened 3 years ago
I personally think, that at least for 3d printing the added layer of complexity to the motion control with the required PID-tuning and the magnet encoder adjustment are only partly payed back in improved print reliability. There is only a small subset of issues that closed-loop can correct, e.g. bumping into some PETG blobs etc... but it can also kick the print off the bed. Maybe it is a different story for ultra-highspeed printers but nobody did demonstrate this yet and I suspect the high-speed fraction came to a similar conclusion than me. The inertia of the moved parts (print head, etc.) just does not reflect back to the motor shaft but is consumed by the flexability of the motion setup itself (belts, mounts, rails, frame,...) and therefore cannot be compensated by closed loop. That is also the reason why one has to invest in expensive ball-screws and proper rails and frame for metal mills or routers before even considering to switch to hybrid or servo motors.
I already explained in other threads, that I use these boards only for my geared direct extruders to keep the little pancake motors absolutely cool while providing +100% max. over-current (1.4A RMS). But, I have to rely on stripping the filament as my only safety or the motor will burn out in case of a hard jam. ;) Maybe I should just add a simple DS18B20 temp monitor function motor health checking and emergency shutdown of the extruder. ;P
@Quas7 Though if you set hold current to maximum, the close-loop can be driven same way as open-loop motor. It would need to be run at open-loop motor manner (i.e. rampu-up and ramp-down the speed). This way you could avoid running into PID issues, but the only advantage then would be that if perturbed, it wuldn't skip step.
Yeah, PID needs error in order to correct and errors are bad for prints. The only way to avoid errors while not driving the motor at full current all the time, would be to introduce accurate feed-forward term (mainly second derivative of position tarrget times lumped inertia).
I also don't see much use of close-loop in 3D printer bed that moves fast all the time and "hold current" needs to be cranked up.
For robotics they are great, though I wish hardware was safer.
@dzid26 just to complete my closed loop extruder concept: for extruders we have a 2nd order term via linear advance a.k.a pressure advance. Easy to calibrate with simple pattern printing that also works for tuning PID to zero out overextrusion on 100% speed changes. I just optimized rapid retracts for PETG stringing with 100mm/s that are hard to realize with undersized/underpowered nema17 pancakes on 3:1 gears.
I will probably go back to open loop setup since BTT does nothing really to make it work. My printer has been offline for more than half of the year due to me tinkering with these drivers. I don't think it is worth it, and with such lack of support... I will probably not buy anything else from them until they change my mind.
Hi. Great Work here. I am a super newbee of 3d printing. I am wondering whether to buy BTT S42B or MKS Servo42B. I dunno the difference between those two. Any idea?
for a beginner, I would stay away from closed loop setups. The benefit compared to TMC drivers is not proven and the possible complications are not worth the slighlty increased reliability.
With that being said, AliExpress.com has all these China products listed. I would use MKS servo42b as they show less trouble in the field and have a less buggy design. But, we did not get our hands dirty with the more recent S42B v2 though.
So I looked into 3 different versions of this project: BTT firmware for v2.0 hardware, kablek's fork and dzid26's fork with can support. Looks like latest platformio ststm32 platform update v10 broken everything and none of these projects can be built without modifications. There are deprecations in platformio.ini:
board_build.ldscript = $PROJECT_DIR/buildroot/ldscripts/STM32F103CB_FLASH.ld
add this to [env:BIGTREE_S42B_V1_2] part of platformio.inienv_default
to default_envs = BIGTREE_S42B_V1_2
in platformio.ini"product_line": "STM32F103XB",
add this to board specs in buildroot/boards/{filename}.jsonLatest update of the platform also updated STM32F1Cube package to latest version (1.8.3) that is incompatible with previous one (1.7.0). This will require changes in the code to be compliant with latest HAL.
Each project does have it's own structure (and different framework for btt) and making something unified is impossible.
Maybe as a first step we should start by defining of high level structure and algorithms of the program? Then go c++ way abstracting control algorithms from hardware, then making same thing for hardware drivers and then adapting for different cpus and platforms?
I updated to v10. Seems like they updated libraries finally. But there is issue with product line thingy on some mcu. Intresting.
I tried building the stuff:
Btw, I wonder what software AnanasStepper3 will have once they ship.
Due to lack of time and conditions with COVID and one of my end stops breaking, I have switched to TMC2209 for time being. I should continue development when I resolve some other things.
SimpleFOC is a closed-loop Arduino library that has support for STM32 devices, stepper motors, and magnetic encoders. Would it be possible to drive S42B using this code? Possibly saving some effort on a full firmware re-write?
Hi I also made a new firmware. But this is very different because it is for using these stepper in a Tower clock mechanism. So one stepper for minute hand and another one for hour hand. I want to thank @swanepoeljan for his cleaned version which was base of mine. Code https://github.com/flyingdogsoftware/TowerClock and project page: https://hackaday.io/project/178777-real-tower-clock-version-20
Check this out https://github.com/CAP1Sup/Intellistep/
I must admit I was very sad when I received my S42Bs and they didn't work well (display issues, skewed prints, steps missing, ...). At the time fixes for said problems were not available on this github page (and even today some are not really sure to work).
The code is not well documented, it is messy and apparently it doesn't work too well. Would anyone be interested to cooperate/make/use fresh code and decent open source firmware?
I have experience with STM but I am not ready to commit to such project if there is no interest in making such project happen if there is not enough interest.