ServoEasing VS Marlin

Hi, all. titles not a 100% accurate. i was able to take the threeServos code example off the library's github(https://github.com/ArminJo/ServoEasing/blob/master/examples/ThreeServos/ThreeServos.ino) and butcher it to my purposes. but now i'm not able to change the motor speed, no matter what number i use for the setSpeedForAllServos() function the motors always move at the same speed. but frankly i dont even understand how the code i have here works.

I have a robot that looks similar to yours and I can stop an issue with your current software. The reason your entire arm is flexing when the servo stops is of course realated the weak first link between the upper part oft the arm and the socket. But an easy way to fix it (get around it) is by utilizing easing. When the servo should go from 0 to 90 degrees, make it go really slowy from 0 to 20 maybe and then reallt fast from 70 to 90 make it go slowly again. Of course you can use cubic easing to get a velocity near zero before the servo stops. A great library that you can use us ServoEasing. https://www.arduino.cc/reference/en/libraries/servoeasing/ GitHub: https://github.com/ArminJo/ServoEasing

There is _a lot_ wrong with Marlin. It is a complex codebase, full with ancient artefacts, litterred with preprocessor ifdefs every 2-3 lines of code, dynamic includes in the middle of CPP files, etc[1]. It's about as unreadable as C++ code gets--well, I guess it's not template metaprogramming.

Klipper by contrast is a breeze to read through[2].

I am very grateful for Marlin, for all of reprap, and everyone who has contributed to it. But saying there is nothing wrong with it is straight up misguided.

[1]: https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.1.x/M...

[2]: https://github.com/Klipper3d/klipper/blob/master/src/lcd_hd4...

I think you are mistaken. I can't speak for implementations preceding the Ender 3 V2, so what you're saying may have been true at some point for other machines. However, here you can see Marlin developers confirm that there is an EEPROM on the stock E2V2 board using diagrams from Creality and photographic confirmation. Here is the datasheet for the EEPROM. Here is a thread discussing this Marlin release, and also the then-recent release of official Creality firmware which resolved the same issue. Since the stock firmware is based on Marlin, and at the time Marlin did not support this type of EEPROM, the EEPROM was not usable at launch. Any mainstream firmware (official or third-party) from the last three years will be using the onboard EEPROM unless the user intentionally specified otherwise.

pull latest Marlin from github: https://github.com/MarlinFirmware/Marlin

Also, checked the following discussion but seems like I need to update the firmware to be able to comment that like right? Temperature variance monitor tweaks by zeleps · Pull Request #23571 · MarlinFirmware/Marlin · GitHub

i spent some time and successfully rebased Kobra 2.8.2 OG firmware from an unknown Marlin ~2.0.8 frankenstein to a clean latest (as of now) release (not bugfix) 2.1.x -- v2.1.2.1 + 1 commit

As an example, check the macropocalypse in Marlin - but the actual trigger for me to start was Reprap firmware doing a floating point divide in interrupt context while targeting AVR8 core…

Any change of thermistor or to a PT100/PT1000 will require recompiling the firmware, because every type has different characteristics. Marlin uses an internal table to calculate the temperature for whatever reading it gets from the CPU's analogue-to-digital converter. It has many tables for different thermistors, but only one is ever incorporated at compile time. So you have to specify which type you're using. You can see the commonly-used types in the list in Marlin's Configuration.h file, in the section headed // @section temperature. The tables themselves are in Marlin/src/module/thermistor.

FWIW It IS open source but the GNU General Public License v3.0 rules apply. https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.1.x/LICENSE