Replies: 4 comments 6 replies
-
|
Unfortunately I've been busy with my Robotics team and AP exams... I just graduated this weekend. I'm hoping to have some time to work on the project soon. I was stuck on step counting. I tried every combination I could think of... but I still couldn't get it working. Without accurate counting, the whole project is not viable. However, I think that I might be able to load the factory firmware and use the STLink programmer to look at the timer configuration registers. Regarding your PR, I will take a look at it. I apologize for not taking care of it. I've been super busy but I don't want anyone to feel like they've put in a bunch of work only to be ignored. |
Beta Was this translation helpful? Give feedback.
-
|
congratulation for graduation! but your graduation was top priority of course! |
Beta Was this translation helpful? Give feedback.
-
|
It's been a bit, but I've kept my eye on this repository because I could benefit from making my s42b v2.0's not bad. My bed is heavy and so I got this jiggling oscillation (although I heard that increasing microstepping can help), I would love the ability to mess with PID values without recompiling the firmware, and it even looks like this repo has an autotuning feature, which is amazing. Unfortunately, I haven't had too much experience with embedded systems (fiddling with arduino mostly), but if it would at all help, I would love to test firmware builds for you if that would help at all. Otherwise, I might be able to read up and assist with development in some way. Regardless, any plans to continue to work on this project? Also a year later, but big congrats on graduating! |
Beta Was this translation helpful? Give feedback.
-
|
Hello! I'm glad to see that you're interested in the project... at least I'm not the only one. I began the process of re-writing the firmware from the ground up using BTT's code and other repos as guides. Originally, when the boards would receive a step pulse, they would update their PID's setpoint (where the motor should be). The PID loop would eventually come along and move the motor, but this process lags behind the desired stepper position. Think of it as trying to catch up every time as opposed to traditional drivers, which move the motor immediately. This causes rounding of corners... the motor isn't able to make quick speed changes that the printer expects. I designed the new firmware to use instant stepping instead of the PID. The motor will be moved as soon as the step pulse is received. If the motor moved out of place by over a tolerance, a PID loop was used to step the motor back into place. However... the board has a big issue: it doesn't always count step pulses perfectly. This causes layer shifts... not ideal in a printer. I've tried a whole host of solutions, but I can't figure it out. I wound up giving up... I thought that it was a design limitation that would kill the project. I gave up on the boards and went back to TMC2130s. However... with the proliferation of Klipper, the counting issue can be solved. Klipper uses a master controller (such as a Pi) to command slave MCUs. Klipper sends exact stepping counts digitally to its MCUs. By turning this board into a MCU, the boards could theoretically work as intended. As far as integrating this board into Klipper... there's a few good things and bad things. Klipper already supports the F103 MCU used in the boards and uses a step function similar to this repo. As for the bad things: Klipper has absolutely no framework for these. A step command for a typical MCU is a pin pulse. With these boards, there's a whole host of calculations to be done in order to move the stepper correctly. Not that they couldn't be added... but there is a lot of adapting to do. Also, the original boards have a "salmon skin" effect (although it could be from mathematical errors in the original firmware). Finally, since these boards use the A4950 drivers, they run hot and will likely always whine. After a year or two away from Intellistep, I had some free time today and took a look into Klipper and the possibility of adding these boards to it. My repo is here. I can't promise that I'll be able to get it working... it seems like a long shot at this point. Also, even if I did, I'm probably not going to write it in a way that Kevin (original author of Klipper) agrees with, which is understandable. For the first working version, I'll probably hack together a custom build that pretends to set up/use a regular driver but actually does Intellstepping behind the scenes. It also won't support any "fancy" features like closed loop, so it'll basically just be a "dumb" stepper. If I see that the boards do seem to work properly, maybe I'll continue to pursue it. Maybe even properly integrate into Klipper... but that's probably just crazy talk. Even so... keep an eye on my Klipper fork. I'll reach out if I have positive results. I'll commit regularly if I'm working on the project, so you'll be able to see my process as I attempt to work through the issues. I will be going back to college soon and I have a good amount of printing to do (Honeycomb wall!), so I probably won't get much time on this until later in the year. For now, I'd stick with TMCs. Best of luck with your printing... hopefully I can get these boards working eventually. |
Beta Was this translation helpful? Give feedback.
-
|
Out of curiosity, when you mention that you started "re-writing the firmware from the ground up using BTT's code and other repos as guides", what other repos were you looking at? I briefly looked at the other forks for the upstream repo, and I didn't see anything interesting (maybe I missed something?) After re-reading your post a few times, I can understand some of the subtle issues that you mention. Personally, I'm using marlin, and I'm unfamiliar with the fundamental differences between it and Klipper, other than some "general consensus" that I must have picked up somewhere that Klipper "is better for 'jankier' setups and/or lower level hardware (arduino?)" Not that I have anything against klipper, but I'm not sure if it would be a feasible shift for me given my unique hardware setup. That said, I'm not so concerned about that sort of detail, but I did want to restate your issues you mention in paragraph one, to see if I understand you right. Essentially, the non-closed loop motors (in my case, my screw lead z axis and my extruder), are driven directly by the commands sent to the driver, and "no latency" occurs during this process, however, the PID sets a "desired position", and there is a constant "correcting process" running at all times on the S42B that essentially just constantly "pursues" the "desired position" via PID, but this process naturally has latency. If all motors shared this exact latency, then I figure it wouldn't be a problem, but because the non-closed loop steppers don't share this latency hit, the prints can come out generally wonky. I suppose that you could hypothetically modify the mainboard firmware to artificially introduce some latency to fix this problem, but that seems unideal. It seems the solution you were aiming for was for the S42B to essentially "Keep an eye" on the stepper motor and to not intervene in any way (during this time, use direct drive), and only "step in to correct things" if the motor had sufficient error. However, you seem to indicate that the S42B's are rather poor at keeping track of steps? I'm not sure if this means "keeping track of the step commands issued" or "keeping track of the encoder's observation of the steps" or a combination of both; meaning "keeping track of the error delta due to one or both of these possible flaws". One of the things that confuses me about this possibility, is that these seem like hardware issues (S42B is too fundamentally flawed?) or something else I haven't considered. I think from reading that the primary issue with this approach is that when switching from instant stepping to PID (for correction), that there's inaccuracy that is caused during this process, or that simply over the course of a many hour print, that one or two steps being lost is just essentially guaranteed to happen. I'm under the impression as well that the compiled firmware from BTT does not exactly match the source from BTT, and that (possibly?) the compiled firmware is of a higher quality/polish than the source we have. If this is the case (I'm wildly lacking context & feasibility), but could a decompilation tool like ghidra or IDA potentially allow us to have a better shot at improving things? The main issue I'm interested in improving the performance of my S42B's is that my y-axis (bed gantry) is so massive that when closed loop is enabled, the bed jitters back & forth. I think this is happening because the inertia of the heavy bed & the elastic nature of the rubber belt literally causes a "rubber-banding" effect, where the S42B gets behind due to slow acceleration, it overcorrects, then pulls back to fix the overcorrection (which causes it to be pulled back too hard), and results in an endless "jittery" movement. I heard from somewhere (I can't find my source), that increasing the microstepping can fix this behavior, but doing so is extremely un-obvious. There's so many places to adjust microstepping, and I don't know which ones need to be set, which ones to ignore, which ones compound erroneously upon each other if both are applied, or which ones cause no effect. By my count, there's microstepping adjustment in: the motherboard firmware (marling config), jumpers on my SKR PRO v1.2 motherboard (just underneath the stepper driver socket), dip switches physically on the S42B, and a microstepping menu inside the S42B. This is so confusing! I was hoping that a PID adjustment may help, as I have not been able to figure out if my attempts at adjusting microstepping are yielding any results. (The movement of the y axis doesn't seem to be any different throughout my permutations of settings). Have fun at college, I'm just finishing my bachelor's myself, I'll try some blind fiddling & flashing (maybe diffing from BTT's firmware and re-applying minor changes) to see if I can get effective results from simple modifications. |
Beta Was this translation helpful? Give feedback.
-
|
I was primarily looking at the MKS SERVOB, Nano Stepper, and Mechaduino repos. I wouldn't say that Klipper is better for "jankier" (love the word choice)... it's just different than Marlin. Whereas Marlin uses a single microprocessor, such as an Arduino (mostly Arm chips nowadays though), Klipper uses multiple processors. Klipper uses a more powerful host processor, such as a RasPi, to do the "heavy lifting" such as complex lookahead, movement smoothing, etc. The host will then command one or more slave microprocessors, such as cheaper Arduinos, to carry out the lower level IO functions. For example, pulsing a stepper driver or running a PID loop for a heater. The benefit of Klipper is the ability to use multiple processors... on my printer, I have a toolhead board that manages the extruder, hotend, cooling fans, and BLTouch... all with 4 wires running to the toolhead board (positive and negative 12v, CAN low and high). This simplifies the wiring and allows me to easily add more devices... say I wanted another cooling fan for the hotend. It would be as simple as connecting the fan to the tool board and telling Klipper to about the new fan. Also, Klipper allows the printer's configuration to be altered without requiring constant firmware complications. Overall, I believe that Klipper is much more efficient and practical than Marlin... think of it as using a team of workers instead of a single one trying to do everything all at once. The movement latency that I'm referring to is caused by the nature of a PID loop. A PID loop receives a new position and attempts to react, leading to rounded corners. A traditionally stepped motor will be able to be pulsed at whatever frequency is necessary... meaning it can instantly accelerate at a given rate. A PID loop lags behind as it attempts to reach the new set point each time. This causes under and overshoot of the desired position. This under and overshoot will show up as rounded corners in your prints. By tuning the PID, you can tighten its response time (reducing motor movement behind or ahead of desired), but you'll never have the exact positional control that pulsed stepping gives. As for keeping track of steps... I believe that BTT uses the "encoder" interface (not the magnetic encoder... that's run over SPI) of the STM32F103 in order to count the steps. It's actually quite interesting that they repurposed it... I actually think it was a decent idea. However, an encoder typically doesn't see the pulse rate that is required for stepping. Say you're moving 60 mm/s on a motor with a pulley 10 mm in diameter. The motor will need to rotate about 2 rotations per second. A typical stepper motor is 1.8 deg... meaning 200 steps per rotation. Add in 16x microstepping. Now you're talking about around 6400 pulses per second. And that's only 60 mm/s... travel moves are commonly over 120 mm/s. See how impractical it becomes to count every pulse flawlessly? In my testing, I was losing a step or two per 5-10 minutes... major layer shifting that made unusable prints. I think that BTT uses PID because they couldn't execute steps fast enough. It's simple to add or subtract one from an integer... it's another to compute coil values based on a bunch of factors. Even with the best optimizations and overlocking the board almost double the recommended clock speed (128MHz!), the motor still loses steps. I believe that the stepping routine isn't fast enough to execute in real time... but I'm not sure. I've done PID tuning before on my FRC team... the unfortunate fact is that you'll never be able to tune the PID loop to be responsive enough for printing, let alone also get rid of the jittering. Take a look online at PID response graphs, hopefully you can see whet I mean. The benefit of Klipper is stepping commands are given to MCUs over digital communication... meaning there isn't a pulse to miss. The stepping is done through a decreasing counter. I think that's the only way to get this board working. Kevin (author and maintainer of Klipper) has a Mechaduino branch on his Klipper-dev repo. I believe that adding S42BV2 support will be fairly simple... it's very similar to the current implementations. As to why the branch was never finished and merged... I'm not sure. Maybe Kevin concluded that these boards just don't have a future in printing. Anyways, best of luck with your degree! I hope everything goes well for you. |
Beta Was this translation helpful? Give feedback.
-
|
I've come back, with more slightly more understanding of my situation, and some minutiae filled in. I understand the rounded corners issue that you're talking about, and this problem seems unobvious and difficult to tackle. After looking at MKS SERVOB (and C, the newer one), a small part of me wonders if the implementations (hardware) are a rebrand of BTT's items, or vice versa? Anyways, I was wondering if you had arrived at a "closed loop stepper solution" that you've been satisfied with since I last posted. Although they are loud, my X axis has been working wonderfully, it's just my bedslinging y-axis that's too heavy and causing jittering in the y axis. (I know I should try increasing microstepping, but I'm not sure which combination of firmware/motherboard jumpers/s42b oled menu/s42b dip switches I need to configure for a [particular] microstepping value. I'm not sure if [e.g., marlin] is expecting microstepping to be configured within its software (and therefore, if further "microstepping adjustments" are performed "downstream" (e.g., jumpers or s42b config) could cause a compounding effect, causing the microstepping settings for both to "fight each other" or something.) Either way, I'm surprised at this point that this wasn't user error (on my part) and that this has genuinely turned out to be a poor experience, and that I can't reap as many benefits as I would like. I've noticed that MKS SERVO42C apparently doesn't use a A49XX (or similar) driver, and instead "directly drives the motor using mosfets" (or something?) This seems to be an interesting "simplification"/"adjustment" that I wonder if it solves any of the underlying issues here. That said, we've been discussing the issues of PID in relation to the hardware at play (rounded corners), as well as the flaws with counting every single step, because the encoder misses them sometimes and results in layer shifts. To me, this sounds like the only two solutions would be [something something "make PID faster"] or [something something more accurate/higher quality encoder/higher polling rate], we can't do much about the quality of the encoder, but it seems higher polling rate (overclocking) didn't seem to solve it. Does the "Incremental PID" of the MKS SERVO42C solve any of these problems? If not, do you have any other thoughts? If things truly don't shake out, I might keep my closed loop X axis and just switch my Y over to TMC2209. Thank you for your time. |
Beta Was this translation helpful? Give feedback.
-
|
amuzing to see that we are several working on this project in different ways...
I didn't yet committed my branch, because it's almost a whole rework, so I still have code to clean and test, and didn't yet tested it printing so I don't know the qualities and issues
my approach is really different, I base everything on the angular sensor, step/dir impulses are converted in interrupt into a structure describing a position (angle, full rotation count....)
the angular sensor is polled in timer interrupt for position and motor is driven to reach the position, the external micro steppings are different from the internal microstepping so that the motor will be driven smoothly (creating a PID like effect, but instead of trying to reach the final position "as fast as it can" (PID move fast at begin of curve and then slow down when closing to the target) the approach is to try to force the movement to be as linear as possible)
this is the angular sensor that drive the motor, the step/dir or serial/can position act as a "target to reach", in case of step/dir the speed info will have a lag in case of fast speed change, in case of serial, the info is taken from the GCODE. BUT this should not have missed steps since the conversion is in interrupts and fast to perform, even if the motor didn't reached the previous target in time, it will correct in current target
for BUS communication, the speed info is provided into the GCODE, and BUS GCODE can be either "out of band" or "in band" FIFO (eg several GCODE move commands can be sent but will be consumed in time, but some info for time synchro, error handling or status reporting are performed out of band in interrupt like way)
I dropped the PID because it was more a hack to correct "afterward" the position rather than a way the klipper project use
the main difference with klipper is that the system is designed as decentralized masters/slaves : a motor can be a master of another motor and a slave of another, and that the communication is not in term of steps (because motors can have different settings) but in term of position
this approach allow to
PC <-serial-> Master <-CAN-> X position controler <-serial-> second X position slave
Y position controler <-serial-> second Y position slave
Z position controler <-serial> second Z position slave
Extruder (modified board to manage the heat sensor)
+ bed leveling
heating bed controler
CNC motor controler (with rpm sensor)
even if not recommanded the <-serial-> or <-CAN-> can be replaced by <-StepDir-> in above configuration (with limitation that a step/dir link can't be used as output of a board) :
PC <-serial-> MCU Motherboard <-StepDir-> X position controler <-serial/CAN-> second X position slave
(this setup won't be recommanded, and just for compatibility and integration)
the issue with klipper approach is that it's designed to not use closed loop, the slaves microcontrolers are dumb and even gpio is driven by the master... so closed loop is not a solution in such system,
serial will be tunnable up to 3Mbps speed (and maybe in some release will handle the STM32'serial bus protocol (it's a special mode where the hardware filter serial communicatioin in network like way (with MAC@ like)
my ultimate goal is to have all communication done using X/Y/Z position and all servo translating the position into motor position, so that it can serve to drive a robotic arm and use the roboting arm to print/CNC machining, without slicer modification (a slicer producing GCode for a cartesian X/Y/Z will work with the robotic arm, but since in robotic arm land, a motor position depend on the previous motor position...)
with time : the switch and oled display will be dropped, everything like status and configuration will be performed upon serial/CAN, using jSON format
serial speed will be tunnable but base speed will be increased to at least 1Mbps (usb-serial converter will be advised, so that the serial length will be reduced)
if the design prove to be efficient, it will be used to create a new controler hardware with more capabilities like extension board (removing the oled, button (appart the reset) and switches).... and step/dir will eventually be dropped
but will be added : temperature sensor extension board, heat bed driver, print head temperature driver, rpm sensor board, bed leveling extension board (likely on print head/temperature extension and on rpm sensor board)
Best regards
…------- Original Message -------
On Monday, August 7th, 2023 at 07:27, Christian Piper - notifications at github.com ***@***.***> wrote:
Hello! I'm glad to see that you're interested in the project... at least I'm not the only one. I began the process of re-writing the firmware from the ground up using BTT's code and other repos as guides. Originally, when the boards would receive a step pulse, they would update their PID's setpoint (where the motor should be). The PID loop would eventually come along and move the motor, but this process lags behind the desired stepper position. Think of it as trying to catch up every time as opposed to traditional drivers, which move the motor immediately. This causes rounding of corners... the motor isn't able to make quick speed changes that the printer expects. I designed the new firmware to use instant stepping instead of the PID. The motor will be moved as soon as the step pulse is received. If the motor moved out of place by over a tolerance, a PID loop was used to step the motor back into place. However... the board has a big issue: it doesn't always count step pulses perfectly. This causes layer shifts... not ideal in a printer. I've tried a whole host of solutions, but I can't figure it out. I wound up giving up... I thought that it was a design limitation that would kill the project. I gave up on the boards and went back to TMC2130s.
However... with the proliferation of Klipper, the counting issue can be solved. Klipper uses a master controller (such as a Pi) to command slave MCUs. Klipper sends exact stepping counts digitally to its MCUs. By turning this board into a MCU, the boards could theoretically work as intended. As far as integrating this board into Klipper... there's a few good things and bad things. Klipper already supports the F103 MCU used in the boards and uses a step function similar to this repo. As for the bad things: Klipper has absolutely no framework for these. A step command for a typical MCU is a pin pulse. With these boards, there's a whole host of calculations to be done in order to move the stepper correctly. Not that they couldn't be added... but there is a lot of adapting to do. Also, the original boards have a "salmon skin" effect (although it could be from mathematical errors in the original firmware). Finally, since these boards use the A4950 drivers, they run hot and will likely always whine.
After a year or two away from Intellistep, I had some free time today and took a look into Klipper and the possibility of adding these boards to it. My repo is [here](https://github.com/CAP1Sup/klipper-S42BV2). I can't promise that I'll be able to get it working... it seems like a long shot at this point. Also, even if I did, I'm probably not going to write it in a way that Kevin (original author of Klipper) agrees with, which is understandable. For the first working version, I'll probably hack together a custom build that pretends to set up/use a regular driver but actually does Intellstepping behind the scenes. It also won't support any "fancy" features like closed loop, so it'll basically just be a "dumb" stepper. If I see that the boards do seem to work properly, maybe I'll continue to pursue it. Maybe even properly integrate into Klipper... but that's probably just crazy talk. Even so... keep an eye on my Klipper fork. I'll reach out if I have positive results. I'll commit regularly if I'm working on the project, so you'll be able to see my process as I attempt to work through the issues. I will be going back to college soon and I have a good amount of printing to do (Honeycomb wall!), so I probably won't get much time on this until later in the year. For now, I'd stick with TMCs. Best of luck with your printing... hopefully I can get these boards working eventually.
—
Reply to this email directly, [view it on GitHub](#121 (reply in thread)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AJUDLRGV45TXGZ7ZV5IWACTXUB4EJANCNFSM5X5T7CPQ).
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Is your branch published on a public repo? |
Beta Was this translation helpful? Give feedback.
-
|
to add my 2 cents to the knowledge
main difference between marlin and distributed (klipper...)
marlin behave like this :
- it send new step count using the step/dir interface to first motor, the sending duration depend of the number of step count
- first motor driver begin to move (if you correctly setup the max movement speed, the motor that is slower won't reach the position before long after the new position was sent)
- it move to next driver and send it's position, the second driver begin to move to it asked position
- it move to next driver..
- it move to next driver...
- it sleep for enough time (performing other task like temperature...) to let the driver reach the position
- it restart the process
- if miss configured (mm/s too high) the motor won't reach the position and will drift, until missing step arrive
what does that implies ?
that you can't have dual motor per axis : since it send the move command one driver after another, the first motor on an axis will begin to move before the second motor get a new command, some boards allow dual motors by having a single driver control 2 motors, but this means that the 2 motors get half the power and have to have same electrical characteristics to be seen by the driver as a single motor...
this means that for marlin, all have to stay on a single motherboard, so you have to have complex motherboards that cost a lot and aren't extensible (try to find one that can manage dual motor on Z, dual motor on X, dual motor on Y, a bed power interface, and 4 extruders (3 for color or different materials, one for support....)
this also means that all the motors don't move at the same time, there is always a lag, it's only working as long as the "sleep" is long enough and that's why the timings of a setup is really touchy, everyone want to print the faster but the faster you send command the more you'll have the X motor in place before the Z motor begins to move...
if you have a microscope you can see that the "stairs" created by the non sync move (but it's not really important)
the other issue is that there is no control of the motor, if you setup the speed wrongly there is no information coming back from the motor, between two position sending cycle, the marlin assume the position was reached, you can't detect object collision and missed steps...
the most critical issue for me is the fact that system is difficult to setup beside the 3d printer world, for driving a CNC for example, you need powerfull motors, dual axis setups... and no motherboard will meets the requirements in term of power and number of drivers.... same, collision detection is a must because you can burn motor or destroy tools by trying to go through.... (for a printer, you'll just loose a print...)
coming to klipper and decentralized setup : this allow cheaper "slaves" that do a single task, as said by Christian, and also this allow to a better sync : you can send the next position in advance and give a start to have all driver begin to move, you gain a lot in wire setup, prevent cross talking and noise error.... but you have to be a bit smarter in sync (have a way to correct clock drifts and propagation time on the bus) in a way, complex setups is possible with decentralized setup, and you can have better control
comming to the PID topic
the main issue that I see with BTT current intellistep way PID is implemented, is that it's not PID.... PID is a way to reach the position the fastest it can, but slow down before reaching to avoid oscillations : if you raw drive a motor, asking to move from one angle to the next, the motor just "go the fastest", cross the position due to inertia, and have electromagnetic force pulling it back to the position the fastest, cross due to inertia and so on.... current intellistep PID way is almost like it, but use the angle sensor to know how to modulate the power so that the pull back isn't too strong and reduce the oscillation...
the problem that sees christian, is not a PID effect, it's a timing missconfiguration, a PID loop prevent the motor going too far, and then some printing artefact, but the cost is time... you have to tune per motor for the best PID setup according to the motor, but this won't prevent you setting too fast moves, if you're too fast, you'll receive the next move command before one of the motor can reach the position, so, according to timing, it will receive the next position on the way forward or backward target position.... because PID is SLOWER (it will ALWAYS be slower, but it's more precise) timings have to be slowed... however in current intellistep PID implementation, neither precision nor speed is achieved
you can overclock the CPU as you want, this is not a CPU issue, this is a mechanical issue, you're just wanting to dance a too fast music... (the music is the CPU, the dance is the hardware, you can have your brain says "now you have to move" if your leg is too slow, you will finish to be out of sync)
so now, what klipper won't solve ? what you need/want is a truly decentralized system : each driver has to wait for the others before begin to move... but klipper is still a "head and legs" system, the legs never report when they ended the command, because they aren't closed loop, they don't know, they just assume, and because klipper has no support for closed loop, it has never been designed to get drivers's reports.... so you'll have the same issue, the only way to solve your issue, is, to slow the music... klipper has just some "clever thinkahead routines to reduce the artifacts like tuning acceleration and slowdown before a change of direction)
what I try to do is a truly decentralized system, which means that the head broadcast the command to the legs, the legs begin to move and report when they are in position, the next move can only be performed when everyone is in position. This way the "timing" of the setting in the slicer has no importance, at least for fast moves, because even if you ask for a move at 100000000mm/s if the slowest motor can only do 30mm/s even if the fastest can go 5000mm/s it will have to wait for the 30mm/s one to be in position before starting a next move.
…------- Original Message -------
On Friday, August 18th, 2023 at 05:46, Christian Piper - notifications at github.com ***@***.***> wrote:
I was primarily looking at the [MKS SERVOB](https://github.com/makerbase-mks/MKS-SERVO42B), [Nano Stepper](https://github.com/Misfittech/nano_stepper), and [Mechaduino](https://github.com/jcchurch13/Mechaduino-Firmware) repos.
I wouldn't say that Klipper is better for "jankier" (love the word choice)... it's just different than Marlin. Whereas Marlin uses a single microprocessor, such as an Arduino (mostly Arm chips nowadays though), Klipper uses multiple processors. Klipper uses a more powerful host processor, such as a RasPi, to do the "heavy lifting" such as complex lookahead, movement smoothing, etc. The host will then command one or more slave microprocessors, such as cheaper Arduinos, to carry out the lower level IO functions. For example, pulsing a stepper driver or running a PID loop for a heater. The benefit of Klipper is the ability to use multiple processors... on my printer, I have a toolhead board that manages the extruder, hotend, cooling fans, and BLTouch... all with 4 wires running to the toolhead board (positive and negative 12v, CAN low and high). This simplifies the wiring and allows me to easily add more devices... say I wanted another cooling fan for the hotend. It would be as simple as connecting the fan to the tool board and telling Klipper to about the new fan. Also, Klipper allows the printer's configuration to be altered without requiring constant firmware complications. Overall, I believe that Klipper is much more efficient and practical than Marlin... think of it as using a team of workers instead of a single one trying to do everything all at once.
The movement latency that I'm referring to is caused by the nature of a PID loop. A PID loop receives a new position and attempts to react, leading to rounded corners. A traditionally stepped motor will be able to be pulsed at whatever frequency is necessary... meaning it can instantly accelerate at a given rate. A PID loop lags behind as it attempts to reach the new set point each time. This causes under and overshoot of the desired position. This under and overshoot will show up as rounded corners in your prints. By tuning the PID, you can tighten its response time (reducing motor movement behind or ahead of desired), but you'll never have the exact positional control that pulsed stepping gives.
As for keeping track of steps... I believe that BTT uses the "encoder" interface (not the magnetic encoder... that's run over SPI) of the STM32F103 in order to count the steps. It's actually quite interesting that they repurposed it... I actually think it was a decent idea. However, an encoder typically doesn't see the pulse rate that is required for stepping. Say you're moving 60 mm/s on a motor with a pulley 10 mm in diameter. The motor will need to rotate about 2 rotations per second. A typical stepper motor is 1.8 deg... meaning 200 steps per rotation. Add in 16x microstepping. Now you're talking about around 6400 pulses per second. And that's only 60 mm/s... travel moves are commonly over 120 mm/s. See how impractical it becomes to count every pulse flawlessly? In my testing, I was losing a step or two per 5-10 minutes... major layer shifting that made unusable prints.
I think that BTT uses PID because they couldn't execute steps fast enough. It's simple to add or subtract one from an integer... it's another to compute coil values based on a bunch of factors. Even with the best optimizations and overlocking the board almost double the recommended clock speed (128MHz!), the motor still loses steps. I believe that the stepping routine isn't fast enough to execute in real time... but I'm not sure.
I've done PID tuning before on my FRC team... the unfortunate fact is that you'll never be able to tune the PID loop to be responsive enough for printing, let alone also get rid of the jittering. Take a look online at PID response graphs, hopefully you can see whet I mean.
The benefit of Klipper is stepping commands are given to MCUs over digital communication... meaning there isn't a pulse to miss. The stepping is done through a decreasing counter. I think that's the only way to get this board working. Kevin (author and maintainer of Klipper) has a [Mechaduino branch on his Klipper-dev repo](https://github.com/KevinOConnor/klipper-dev/tree/work-mechaduino-20181205). I believe that adding S42BV2 support will be fairly simple... it's very similar to the current implementations. As to why the branch was never finished and merged... I'm not sure. Maybe Kevin concluded that these boards just don't have a future in printing.
Anyways, best of luck with your degree! I hope everything goes well for you.
—
Reply to this email directly, [view it on GitHub](#121 (reply in thread)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AJUDLRAXFLBCUFWEBYCZMK3XV3QQBANCNFSM5X5T7CPQ).
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
just a discussion for some pinging ;)
I hope the project is still alive since there is no more commit for 4 months and I made a merge request for flash refactoring review.... and still got no answer....
Beta Was this translation helpful? Give feedback.
All reactions