xerootg Help

[xerootg]

I've got a couple of these S42B's running an all leadscrew printer, and I'd really like a better firmware than stock. You have taken the jump where others have not. Do you have things you'd like help with?

[CAP1Sup]

What kind of help were you thinking? What kind of experience do you have with STM32s and Arduino?

[xerootg]

I'm okay with firmware bits and pieces. I've dug pretty deep into other MCUs (esp-idf, lpcxpresso, freertos on some random atmel chip, etc) and I'm comfortable with platformio and its environment, just not specifically the stm32. I'm not gonna be your miracle helper, but I'd happily take a swag at something you wanted to have someone else take a swag at.

[xerootg]

I guess, more clearly, do you have a 'wish list'?

[CAP1Sup]

I do actually. It's under the projects tab. As of right now, I'm currently working on moving all of the CMSIS commands to Arduino commands. As of right now, the biggest thing looming on the horizon for me to do is figure out PID tuning. I have the base framework written (all of the math for calculating outputs) but nothing for PID tuning. I'd like to have an automatic tuner (there's a fair amount online about tuning automatically) and possibly a manual utility that could act as a tuner with nice graphs of the motor feedback. If you wanted to work on something, that would probably be your best bet. I'm currently reimplementing all of the code, so I won't get in your way. I'd like to use forks, that way we don't have to worry about getting in each others way. Assume that the provided functions work as intended. They should by the time that you finish it

[CAP1Sup]

Does that sound like something you'd be interested in?

[xerootg]

Yeah! I've got a stlink in the mail and I'll see what I can do in regards to auto-tune. Personally, I'd like to see configuration driven by canbus or other methodology (serial/spi/i2c), possibly via marlin. With a real communications mechanism, we can do cool stuff like block the scheduler to prevent new steps from running over incomplete moves. On top of that, I have zero interest in using the LCDs and buttons long term on my applications of these steppers, so I look forward to your move to a more friendly SDK!

[xerootg]

I'll fork your repo and PR into it if I get anything worth your time 😄

[CAP1Sup]

Yup, there's a reason why I redid the serial with gcode commands. I'm going to move the parser to it's own file soon, that way we can pass both serial and CAN to the parser. Long term, CAN is the best option (requires the least wiring), but Marlin doesn't support a CAN bus like this yet. I was going to implement all of the commands, then see if anyone was interested in Marlin implementation.

[CAP1Sup]

I'll fork your repo and PR into it if I get anything worth your time 😄

Sounds good. I'll be keeping an eye out to see how it goes

[xerootg]

Maybe we should move the party here from #6 since it's basically what I volunteered to take on 😉
So basically I haven't found an autotune algorithm that is well suited to the purposes of 3d printing. Infact, the pid tuning that I started implementing was effectively what was chosen for the open firmware for the v1.0 boards, and it seems to be extremely hard to dial in. I've poked around at several other pid inplementations out there, and they just don't seem well adapted for our use case. Mechaduino and nano stepper are the other bigger players out there. The only one that struck me as something useful for 3d printing was the "simple pid" as described in the docs for nano stepper.

https://github.com/Misfittech/nano_stepper/blob/master/documentation/Smart%20Stepper%20Manual.pdf

Being that it's open source, it might be a good reference for what you seek?

[CAP1Sup]

Wow, that's exactly what we want to do, just at a higher price point. I think that we can easily use a fair amount of their stepping code and join it with ours. If you were willing, I'd love to see how the combination would turn out.

[xerootg]

It's gonna be a month at soonest, I'm out of town on business, but I'd happily use a chainsaw to make it fit once I have my extra board infront of me. The thing about the nano stepper project that makes porting stuff over is the processor specific bits. The author of that code really squeezed every bit of perf out of that samd that they could. I'm kind of hoping that we get good enough perf out of this f103 to be able to get away with using c. Apparently the original closed loop steppers from mks stole parts of that codebase and the s42a v1.0 boards were ripped off from mks's designs. So there's a bit of legacy here, and us implementing this would bring the whole thing full circle 😂

…

On Tue, Mar 23, 2021, 22:42 Christian Piper ***@***.***> wrote: Wow, that's exactly what we want to do, just at a higher price point. I think that we can easily use a fair amount of their stepping code and join it with ours. If you were willing, I'd love to see how the combination would turn out. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA6S6SXKPEPYD6R5NY67LP3TFFUSRANCNFSM4YFQQZPA> .

[CAP1Sup]

Sounds good. I'll probably implement the open loop awhile and fix the other functions. Open loop should be enough for the time being until the boards can use PID position control

[GhostlyCrowd]

Since were talking about getting motion working here, some interesting finds on how the stepping works can be found here bigtreetech/BIGTREETECH-S42B-V1.0#53

[lav8org]

I'd like to have an automatic tuner (there's a fair amount online about tuning automatically) and possibly a manual utility that could act as a tuner with nice graphs of the motor feedback.

For the latter all that's needed is a way to set up a movement routine and execute with datalogging, with the rest taken care of by https://pidtuner.com @pidtuner
To be of maximum generality the movement generation routine would accept parameters to make movement that accommodates the transmission mechanism/accurately simulate actual use. Ex: steps/mm & safe range limit, max feed, acceleration. Maybe this has already been thought of because afaict the same would be needed for autotuning a 3DP; those parameters differ significantly on every axis of my mendelmax. To offer an extreme example, my engraver has about 11mm range on Z with max feed at 850, and infinite range on Y at 1500 (granted I doubt I'll still be able to reach those speeds without TMC5160s on 35v)

So basically I haven't found an autotune algorithm that is well suited to the purposes of 3d printing. Infact, the pid tuning that I started implementing was effectively what was chosen for the open firmware for the v1.0 boards, and it seems to be extremely hard to dial in.

It seems like datalogging/dump for manual tuning would be easier to implement, more reliable, less specialized, and lay some of the groundwork for autotune. Autotune is a worthwhile goal, but walk before run as they say.

[CAP1Sup]

For the current moment, I was going to attempt to use a basic correction that would be checked at regular intervals by a timed interrupt. However, PID control is definitely a possibility for the future

[lav8org]

For the current moment, I was going to attempt to use a basic correction that would be checked at regular intervals by a timed interrupt. However, PID control is definitely a possibility for the future

huh, I don't know much about control theory so I'm interested to see how you get a stable correction under load at a resolution much beyond whole step without PID control's approach by successive approximation + soft landing. I suppose if you're only after whole step correction it may be straightforward, although my experience has been that losing whole steps--however infrequently--isn't a fluke but due to some underlying problem.