Some findings regarding Klipper

[TazerReloaded]

Hello,

i recently switched from Marlin to Klipper, and I have 2 S42B V2.0 on my printer, one for X, and one for Y. Currently they run stock firmware. Today I calibrated Input Shaper in Klipper, which tries to avoid resonant frequencies of the printer by measuring resonance with an accelerometer. I found the following issues with my setup, maybe that helps you for the development process:

• Frequencies above around 30Hz with small movements are not reproduced by the drivers, I assume the PID smoothes them away. This could be a problem when using small zigzag infill.
• The DIP switches are inverted on mine, seems to be the case on all V2 boards? DIP 2 enables closed loop mode for example, not 3 as described in the manual.
• I experienced a lot of overshoot in closed loop mode, e.g. the print head did not stop right on a corner, but moved on for around half a millimeter and sprung back, resulting in rounded corners, even with slow acceleration.
• Open loop mode works fine, I also got my Input Shaper tuned that way, but the steppers are a lot louder and obviously can't detect missed steps.

So in conclusion, I think the controller should respect the instructions from the MCU as closely as possible. I saw that it's on the ToDo-List with a question mark, but for Klipper, that might be the only way to use the firmware motion optimization. A lost step is usually a relatively big angle jump, so only if a certain tolerance is exceeded, the controller should take corrective action. A counter for the amount of lost steps since power up on the main screen would also be nice, because losing steps should not be common on a accurately calibrated printer and could point out other issues. Low noise and low holding current would be nice features too, but I'm mostly concerned about accurate motion for the moment. Thank you for investing your time into developing this firmware, I'll test it on my drivers when the core features are done!

[CAP1Sup]

Thanks for the insight! I have already implemented the fix for incorrectly installed dips, that was one of the first things on my list. I'm definitely going to be moving away from using the PID loop all of the time, it's just not reliable enough. I believe that there's also an issue with another specific frequency which may or may not have been fixed in the v2 boards. I'll try to fix this issue with software limiting, but I'm not sure if I can do it from the board itself. The encoder and stepper fixes should be coming soon, so I'm hoping to have the board 100% operational soon (within the next month or two). Glad to have another person interested!

[xerootg]

I've been kind of wondering if pid as implemented was the right approach, given that positional control is not speed control. The nano stepper project has a very interesting pid for positional control that would still leave us with quality controls and accurate positioning.

On Sun, Mar 21, 2021, 16:52 Christian Piper @.***> wrote:

Thanks for the insight! I have already implemented the fix for incorrectly installed dips, that was one of the first things on my list. I'm definitely going to be moving away from using the PID loop all of the time, it's just not reliable enough. I believe that there's also an issue with another specific frequency, but you'll have to take a look at the v1 repository (under BTT's account). The encoder and stepper fixes should be coming soon, so I'm hoping to have the board 100% operational soon (within the next month or two). Glad to have another person interested!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/CAP1Sup/Intellistep/issues/6#issuecomment-803674205, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6S6SQCNG4TEKO7ZKMYV5LTEZ2BDANCNFSM4ZR335SA .

[CAP1Sup]

I'm going to pursue a traditional stepper operation for the time being, but it would be interest to have a PID mode.

[xerootg]

Ok, so something along the lines of one step commanded, one step held? I think that's what most of us are really after.

[CAP1Sup]

Basically the controller requests the step, just like with any other driver such as the A4988. The only difference is that the motor will be driven back into place in the event that it is moved from its controller requested position. I think that's what you meant. I just have to figure out how the motor coils are calculated and the exact method of driving it back

[TazerReloaded]

The controller could use PID for driving the stepper back in the event of missed steps, but standard operation should be normal stepping according to the MCUs commands (like open loop mode). This way we could get maximum accuracy, but can still mitigate errors caused by lost steps. Movements are smoothed by the printer firmware in normal operation, so no need to do everything again in the driver and lose timing and accuracy. Only if a difference between the requested position an the actual position occurs (accounting for reaction time of the motor and sensor noise), the PID should kick in and move the motor towards the wanted position. This has to be reasonably fast, or the controller will always lag behind any new incoming steps. Most motion planners regulate nozzle pressure according to expected position, and if the controller does its own thing, the position might not be correct at that point in time. Similar problem with a laser. As I wrote above, the stock controller firmware removes any fast recurring movements because of the PID delay. So if the nozzle is commanded to move back and forth to do a zigzag pattern for example, the stepper will do nothing, because the PID is too slow and just averages out in the middle.

[CAP1Sup]

Yeah, I think a PID loop with a large P term would be optimal. That way, the loop will be responsive and able to correct quickly but only used when the motor is out of position

[TazerReloaded]

Another find on the Klipper repo: There were experiments with the predecessor of the S42B, the "Mechaduino": https://tropical-labs.com/mechaduino/

A fair amount of work has been put into this subject, the main problem seems to be overheating A4954s due to high currents when operating them directly, so some sort of current control might be necessary on the S42B too. Here is the original PR: https://github.com/KevinOConnor/klipper/pull/1038 And the ongoing work by Arksine: https://github.com/Arksine/klipper/commits/work-mechaduino-updated

Maybe we can use some of their research so we don't have to reinvent the wheel too often. Direct control via CAN or Klipper would be a cool feature, but then the S42B is not a drop-in replacement anymore, but needs a matching MCU and MCU firmware to run, which significantly reduces the amount of people that can use it.

[xerootg]

Yeah, the pid loop is used to adjust the current in positional pid in the design of the microstepper project for this exact reason.

On Sun, Apr 4, 2021, 19:36 TazerReloaded @.***> wrote:

Another find on the Klipper repo: There were experiments with the predecessor of the S42B, the "Mechaduino": https://tropical-labs.com/mechaduino/

A fair amount of work has been put into this subject, the main problem seems to be overheating A4954s due to high currents when operating them directly, so some sort of current control might be necessary on the S42B too. Here is the original PR: KevinOConnor/klipper#1038 https://github.com/KevinOConnor/klipper/pull/1038 And the ongoing work by Arksine: https://github.com/Arksine/klipper/commits/work-mechaduino-updated

Maybe we can use some of their research so we don't have to reinvent the wheel too often. Direct control via CAN or Klipper would be a cool feature, but then the S42B is not a drop-in replacement anymore, but needs a matching MCU and MCU firmware to run, which significantly reduces the amount of people that can use it.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/CAP1Sup/Intellistep/issues/6#issuecomment-813137497, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6S6STOKBH7VGGHWZ7EW43THEH3XANCNFSM4ZR335SA .

[CAP1Sup]

Another find on the Klipper repo: There were experiments with the predecessor of the S42B, the "Mechaduino": https://tropical-labs.com/mechaduino/

A fair amount of work has been put into this subject, the main problem seems to be overheating A4954s due to high currents when operating them directly, so some sort of current control might be necessary on the S42B too.

Here is the original PR: https://github.com/KevinOConnor/klipper/pull/1038

And the ongoing work by Arksine: https://github.com/Arksine/klipper/commits/work-mechaduino-updated

Maybe we can use some of their research so we don't have to reinvent the wheel too often.

Direct control via CAN or Klipper would be a cool feature, but then the S42B is not a drop-in replacement anymore, but needs a matching MCU and MCU firmware to run, which significantly reduces the amount of people that can use it.

Definitely an interesting find. I saw references to a Mechaduino in the Nano Stepper code, but it's nice to know what it is now. We could probably pull off direct control by setting the extra DIPs on the board or a command. By direct control, I assume you mean telling it to go to a position and the motor doing the rest? It's possible, absolutely. I just don't think it's something that I want to invest time into right now. I really just want to get it to the point where it can be dropped in. After that, we can look at all kinds of custom features and supporting a wide range of boards. However, if you wanted to make a fork and do the coding yourself, I have tried to make the commenting as transparent as possible. I'd be happy to pull request it into the code once you'd finished. As for maybe adding support for it myself... IDK. Maybe. It's just this project has dragged on for a while now. I want to finish it absolutely, but I don't know if I'll be invested enough to add in a whole new feature set.

[TazerReloaded]

Klipper works with multiple MCUs, so it can control more than one controller simultaneously without the controllers knowing about each other. You could for example plug 2 SKRs into the Klipper host via USB and then attach half your printer to one and the other half to the other, and Klipper would do all the synchronisation and run the whole printer as one. So they tried to adapt that concept for closed loop steppers, the Klipper host sees them as external MCUs, sends movement commands to them, and gets sensor readings in return. All the motion logic is computed on the Klipper host (a Linux machine running Python, usually a Raspberry Pi), and the motor just executes commands, like "move N steps clockwise at timestamp X with speed Y". I don't know exactly how the Klipper protocol works, but essentially they have a C firmware that can be flashed on any supported chip and expose inputs/outputs.

Absolutely no need to implement that on your side, would be way too complex to support any third party protocols, but I think it's an interesting approach. If the step/dir interface works reliably and the OLEDs work for settings, Klipper does not have to be aware that it's running closed loop steppers. Less compatibility issues, less wiring, it just works.

I am a little concerned about the heat problem though, because my S42B are very noisy in open loop mode. Maybe the current can be adjusted dynamically based on a calibration process, so that the motors run at the minimum current necessary to not lose steps, which is then increased for faster moves. My simplest idea would be a counter which is decremented by a timer and incremented by incoming step pulses and sets the current within a given min and max range, so the motor is running at minimum current when standing still and it's ramping up the faster the moves are. If there is any disturbance, the already implemented automatic step correction would move the motor back to the wanted position.

[CAP1Sup]

Klipper works with multiple MCUs, so it can control more than one controller simultaneously without the controllers knowing about each other. You could for example plug 2 SKRs into the Klipper host via USB and then attach half your printer to one and the other half to the other, and Klipper would do all the synchronisation and run the whole printer as one.

So they tried to adapt that concept for closed loop steppers, the Klipper host sees them as external MCUs, sends movement commands to them, and gets sensor readings in return. All the motion logic is computed on the Klipper host (a Linux machine running Python, usually a Raspberry Pi), and the motor just executes commands, like "move N steps clockwise at timestamp X with speed Y". I don't know exactly how the Klipper protocol works, but essentially they have a C firmware that can be flashed on any supported chip and expose inputs/outputs.

Absolutely no need to implement that on your side, would be way too complex to support any third party protocols, but I think it's an interesting approach.

If the step/dir interface works reliably and the OLEDs work for settings, Klipper does not have to be aware that it's running closed loop steppers. Less compatibility issues, less wiring, it just works.

I am a little concerned about the heat problem though, because my S42B are very noisy in open loop mode. Maybe the current can be adjusted dynamically based on a calibration process, so that the motors run at the minimum current necessary to not lose steps, which is then increased for faster moves.

My simplest idea would be a counter which is decremented by a timer and incremented by incoming step pulses and sets the current within a given min and max range, so the motor is running at minimum current when standing still and it's ramping up the faster the moves are. If there is any disturbance, the already implemented automatic step correction would move the motor back to the wanted position.

That's an interesting idea to have dynamic current adjustment. It's something that I'll definitely have to test out. Thanks for the idea!

[CAP1Sup]

@TazerReloaded I think you'll be happy to hear that I will be adding support for Klipper soon (within a month or two). When I mean Klipper support, I mean that each of the S42BV2s will be able to be recognized as an individual mainboard, almost eliminating the need for a central mainboard. They will have stepper support, as well as a virtual endstop. You'll need a USB to CAN adapter (check with Klipper CAN page), but other than that, it's looking like a great option to have. I'll add Klipper support as a setting in the config file. Keep your eye out, it's something that I think will allow these boards to stand out.