PID adjustment via LCD

[ChrGri]

Please provide firmware, which allows PID parameter modification via LCD screen. Without the option to adjust PID setting, running closed-loop mode (left cube, activated by DIP switch 3 on) provides much worse print quality than open-loop mode (right cube, activated by DIP switch 3 off).

My printer is Railcore II with direct drive extruder and heavy gantry. The overshoots at the cubes corners are visible. The default PID settings apparently result in too little dynamic of the closed-loop system.

Furthermore, please implement PID parameter identification. I'm thinking of issuing a chirp signal (sine wave with increasing frequency) trajectory to identify the motion system. Then optimize PID setting e.g. via Q-parametrization (https://www.google.com/url?sa=t&source=web&rct=j&url=http://web.mit.edu/6.245/www/images/ch7.pdf&ved=2ahUKEwjo6PPXpJvrAhWF-6QKHZ-tAUUQFjABegQIAhAC&usg=AOvVaw3tUTxwAj_G_qB2R07_86SD). If you need help implementing PID autotune, please let me know.

Also please see https://www.facebook.com/groups/505736576548648/?post_id=1015249378930696&comment_id=1015283328927301 for initial error report.

[hanifz-dr1]

After finding out about this issue, I tested probably over a 100 combinations of PID. I could not get rid of the overshoot without affecting the accuracy. This was with 32 microsteps. The problem becomes visible in printing small circles when trying to damp the overshoot. Setting I to zero causes undershoot. Setting too high of P and/or D results in a lot of noise and vibration probably because the driver is A4950.

I think the closed loop operation shouldn't be based on PID or at the very least the smallest stepper increment should be synchronized with the encoder position measurement. That is the smallest error from the encoder should limited to minimum the smallest stepper increment. Maybe line 89 of stm32f0xx_it.c should be rounded based on the stepangle setting. Also, the minimum input to the stepper should be the same as that used in the open loop mode based on what I'm seeing in that section of code. Otherwise, you get a non-zero input to the stepper between steps which may be causing a lot of unnecessary noise.

Not sure if there's a guide to flash the stepper board. I didn't see any. If there's an easy way to flash it I can probably try changing the code myself.

[ChrGri]

You will find the flashing instruction here:

https://github.com/bigtreetech/BIGTREETECH-S42B-V1.0/blob/master/3d%20printer%20-ender3%20closed%20loop%20driver%20module%20installation%20instructions.pdf

Please let us know, whether your controller design was an improvement.

[fjrpilot05]

@hanif89
I'm very interested if you tried your modification to the firmware's source. I'm struggling to try and make these closed loops work for me but the overshooting is unacceptable. I will second your request to be able to modify the PID values through the LCD. I don't want to give up on these just yet.
Regards.

[nhabes79]

I haven't tried to set I at 0 yet. Didn't know I could do that. I've been playing with the PID values through the UART connection and using BTT's serial port assistant. On my CoreXY printer, I have my X and Y motors set at P30 I1 D300. Yes, there is the vibration noise for the first couple of layers, but then it pretty much goes away.
For my cartesian printer, I have P50 I1 D200 for X and Y. I'm still messing with it. Anyway, I was able to achieve the same print quality I was getting before with my 2209s with exception of some salmon skin that I'm assuming is coming from the A4950s. Also, I use a little bit of linear advance. Usually in between .04 and .06. That seems to clean up the remainder of the overshoot.

I'll post some pics later when I get home to show the difference between the 2209s and A4950 closed loop setups.

[AbeFM]

3rd vote for PID values setting from LCD.

PID Values+
P
Up/Down/Set
I
Up/Down/Set
D
Up/Down/Set

That would be a big help - or write a plain-text way to set values over serial:

READ/SET kP/kI/KD/MC(motor current)/DR(direction)/EN(able)
so we don't have to do checksums and look up on charts of A1 and B4.

Either one would be a big help.

Lastly: Yeah, the I-values are too big - the PID code needs to rescale that significantly.

[Quas7]

Regarding the checksums, I assume they are in place because the noise on the lines with a powered motor is way too high to guranatee stable communication. Note, programming the board with motor enabled fails as well in almost all cases either during prog or verify.

The display programming option would be nice at least to modify the RAM values.
Saving the values to flash should maybe be set as seperate function after successfull testing.
I had twice the issue, that a interrupted calibration required a reflash of the firmware (stuck in bootloop).

[swanepoeljan]

Was also thinking another reason could be due to the fact that the MCU is using the internal RC oscillator which is not always the most accurate for sampling bits.

I think it's anyway a good idea to have checksums, it's just not so nice if you have to manually calculate them. On my fork of this repo I completely rewrote the handling of the UART, modified the packet structure and included an 8bit CRC checksum. Then I also wrote a small C# program to communicate through the UART, in this case the program calculates the checksum automatically. If I find time over the next days I could maybe also adapt it to work with the original version...

Another modification I made was rewriting the OLED menu and this time I included the option to adjust the PID gains in RAM (as Till also mentioned). Then there is also a Save option which stores the gains to flash memory.

If anybody wanted to try it out, just keep in mind that it's still work in progress with limited testing being done so far.

[Quas7]

@swanepoeljan this is great! I directly pulled your fork to a branch.
BTW, nice new name creation. 👍
And you already have your own promotion video for that: https://www.youtube.com/watch?v=zL2DP2p8xSg&ab_channel=TrueSteppersVEVO ;-D

edit:
your c# program would maybe be an easy start to test autotuning via Ziegler-Nichols methode (https://www.youtube.com/watch?v=n829SwSUZ_c&ab_channel=ChristopherLum).
We just need to get the free running oszillation frequency for a P=(just high enough for oszillation), I=D=0 measured via the TLE and reported back the values to the terminal with some timestamp and values with ~2x the frequency of the oszillation.

And the very low hanging fruit - "tested it": compiles and runs... ;)

[swanepoeljan]

@Quas7 Thanks for giving it a try! Its good to hear that at least it could also compile and run on your side.

Haha... nice video ;-D

Good idea to use it for tuning, think it should not be that hard to implement. So in the firmware I could just add an option to start streaming angle values at a constant rate. Then as a first step just capture and write the reported values back to a csv file for manual processing. Then maybe later perform the processing/calculating of gains in the terminal and even add a graph control to display the result directly in the terminal...
I have a faint memory of Ziegler-Nichols method from Control System class but would have to take a look at the video you posted as a refresher.

[swanepoeljan]

Made a little bit of progress, added a UART command to stream the angle values at 5ms intervals(200Hz). Then I also added a function in the terminal program to write these values to a text file (TuneLog.txt) so that we can use a spreadsheet for the initial manual calculations. (To convert the logged values to degrees, multiply them by 0.021972)

Trying the Ziegler Nichols approach (as proposed by Till) but having a hard time to get neutral oscillation state with my test setup (which is just a 100mm lever with a weight on the end). If I make Ki=1 then I can get it to oscillate but think its more due to "windup" when P is too low (slow) so not really a P only undamped response.
Just to illustrate the logging:

I am trying to assemble an printer bed assembly to test it on there but might take a couple of days until that setup is ready...

Just for interest sake, here is a response from pulling the 100mm lever (without the extra weight) back and releasing it (kind of step impulse) with the stock gains:

[Quas7]

That looks really promising!
I guess, you already tried to point the leaver just vertically down for the free running P-based oszillation? Or just remove the leaver to get a baseline? I am also not sure, how one could calibrate PID for such an "uneven" load scenario.

This "humming" sound for bad calibrated setups is like 3-4kHz by ear.
Just figured, that measuring this via an audio spectrum app might also be a quick way forward. ;P

[swanepoeljan]

Haven't tried it with the lever down yet, will also give that a try.
At least we can now see the response so should be easier to evaluate if certain gain changes improves the system or not.

Good idea to measure the humming through audio! The PID control loop runs at 10kHz, maybe when oscillating between two angles we get something close to a 5kHz tone...

[AbeFM]

I think it's anyway a good idea to have checksums, it's just not so nice if you have to manually calculate them. On my fork of this repo I completely rewrote the handling of the UART, modified the packet structure and included an 8bit CRC checksum. Then I also wrote a small C# program to communicate through the UART, in this case the program calculates the checksum automatically. If I find time over the next days I could maybe also adapt it to work with the original version...

This was my thinking exactly, I was all hot to write a program like that but I got busy with other stuff and I wasn't super sure how to approach it.
I found your compiled EXE on github, but I would love to see the source for it. Is that something you have posted, or would be willing to post?

[swanepoeljan]

Sure, I just added it to the utils folder.

Was done in C# using VS Studio Community Edition 2019.

[Quas7]

@swanepoeljan damn, now I have to check out how to C# as well. ;)

[swanepoeljan]

:-) I am sure you will pick it up quickly.
It's really a very nice and powerful programming language!

[caesar1111]

@swanepoeljan : thks for the gread job on the firmware. I have the same issues like kookaburra88 and this helps a lot with tuning the PID.
..another thing...
Since you are already following the issue Error in OLED initialization code #16, you know about the problem with the OLED. While I am trying to test the frequency settings on my installed S42B and Quas7 helped a lot in trying to solve it with an alternative firmware, we got no solution so far. I bought some S42B directly at the BIQU store and I am haunting down the [email protected] support to give us a solution (right now they are tracking for a bad lot shipped).
But here is an additional request:
Can you add a configuration line in the menue where you can also alter the OLED frequency.... this would help us a lot to find a solution for those who suffer from the OLED issue. This would allow us to choose the frequency without having to flash the S42B all the time.
thks in advance....

[Quas7]

as discussed over in issue #16 the OLED frequency does not fix it at least not on its own. Please test #20 as a workaround for now.

[swanepoeljan]

@caesar1111 Glad to hear that it is helpful. As for the extra menu item, should be easy enough to add, I have some minor changes on my local repo that I planned to push to github over the weekend. I could then also add this option in there.

During the last days I also added an optioned to the terminal program that allows it to work with the original BTT firmware. It is limited to the functions provided by original firmware but should at least also help with PID adjustment. Will also upload this version (both the exe and source) over the weekend.

[swanepoeljan]

@caesar1111 Added the OLED frequency change option to the menu and quickly tested it, seems to work. It's now also updated on my repo. For the moment it does not save the value to flash so if you reset then it starts again with the default decimal value 0. If it helps to solve your issue then I can make the value also saveable in flash (like for the PID gains). Keeping my fingers crossed that it helps!

[swanepoeljan]

Just pushed the updated terminal program to my repo (zip in root and source in utils), there is now a checkbox ("Use BTT protocol") which allows it to work with the original firmware:

This should make it easier to change the parameters, compared to the originally provided terminal program. No need to calculate checksums or things like that, just read the current values, modify them and write them back again. Just note that every write operation writes to flash memory (unlike the TS version, the original firmware has no command for changing parameters in RAM only).

[Pampinho1]

@swanepoeljan Any chance you can upload the compiled firmware to your fork? I am very interested on trying it out myself, but I am unable to compile it because PlatformIO complains about missing dependencies (In particular they seem to point to "stm32f0xx_hal.h" but I don't know enough to venture into that territory...)

[swanepoeljan]

I have added a bin folder with the compiled firmware.

[Pampinho1]

I have added a bin folder with the compiled firmware.

Thank you so much for that. I have however found the fix to the errors compiling the firmware in #38 and combined your changes with that and it worked. Now I am just trying to figure out a change on the behavior in what seems to be the number of micro-steps. In Marlin I have it configured as running with 32 microsteps, but if I set the same value on the board it only moves half of the distance.

[GhostlyCrowd]

@swanepoeljan Any chance you can get your fork working with the V2.0 S42B from BTT, they haven't posted source which isn't surprising and it uses the STM32F1 MCU now

[swanepoeljan]

Sounds very tempting and I actually have a V2.0 driver to even test it on! If I can just find the time...

Regarding the V2 source code, have a look here.

[TazerReloaded]

I have two V2 drivers on my printer for X and Y, they work quite well out of the box, so maybe they reworked the default settings (or my printer just matches them and I was lucky).
But of course I'm in for some tuning, so a version that works on 2.0 would be much appreciated! So far it's awesome that I don't have to worry about layer shifts anymore.

[GhostlyCrowd]

Sounds very tempting and I actually have a V2.0 driver to even test it on! If I can just find the time...

Regarding the V2 source code, have a look here.

Thanks for the link! I'm following you on github so I'll keep an eye out if you happen to get the 2.0 project going :)

[linewallker]

Hi There, do yo have any experience with configuration of pid in use with grbl? I actualy using Last version of fluid NC but I am experiencing some overshots in inner edging of engraved area, can somebody help please?