I just installed the Creality CR-Touch on my Ender 5 Pro, along with a new main board to support it. Both were purchased from Creality. After having issued with the extruder running backwards with the newest official firmware, I had to use an older official firmware.
I have added the Z-Axis offset in the settings, but I was still having issues with adhesion on just one corner of my print bed. I manually leveled the bed and check the Z-Offset again. Now I am having issues with adhesion on the entire print bed. I though the ABL would make things easier, but it hasn’t been so far.
I am looking for recommendations as to what I can do next for my bed adhesion problem. I would also like to know what others are using for firmware, since it seems Creality’s firmware is a bit suspect.
Thanks for the link to your other post and the video. It does help to see what the effects are to the print if the bed is too low or high. I did the manual leveling again and it’s getting better. It was acting like the ABL isn’t doing anything. The first test print gcode I was using had the ABL gcode in it. I decided to use the test squares from the video to test again and that print failed hard. I discovered that it didn’t have ABL gcode. Once I added that to the slicer, it worked, but I still needed to adjust the Z-Offset.
I believe I am all good now. A Cali-Cat print is running now, since that was the only thing I had handy to print.
I am still interesting in figuring out how to get better firmware and need to look into that more.
My Ender 5 Pro is now running Klipper firmware on a Raspberry Pi (a 4 in my case). By utilizing the Input Shaping and Pressure Advance capabilities of Klipper, I have not only improved the quality of prints, I can now print faster, in many cases more than twice as fast.
On top of that, many firmware changes can be made by simply changing a printer.cfg file. No need to recompile and reflash firmware for many changes. I don’t see me going back to Marlin.
While that might be above my level of skill at the moment, I will look into Klipper. From what I am reading, it controls the printer via the USB port, so I’ assuming the main board I have in the printer will be the microcontroller that is used. I have a spare Pi model 4 laying around. Maybe this will be my next project.
Klipper works by turning the printer’s onboard control board (MCU) into, basically, a slave that just drives the physical hardware. The real work of the print job happens on the Pi. That’s where Klipper runs, where it reads the gcode files, interprets them, turns the gcodes into actual processor instructions, and sends them to the MCU. This actually makes it possible to keep running printers on lower end 8-bit control boards.
I’m trying to think whether, a couple of years ago, whether I would have been able to handle getting Klipper up and running. With Nero 3D’s videos I think I could have, and I could have saved myself a bunch of grief in dealing with Marlin firmware.
Please please correct me if I’m wrong, but I thought OctoPrint sends the gcodes to the control board as gcode, which is why you don’t need special firmware on the printer to run OctoPrint.
AIUI, Klipper interprets gcode commands and sends the interpreted machine code to the MCU, relieving the MCU from the overhead of interpretation. Perhaps I’m mistaken, but the fact you have to flash Klipper-specific firmware to the printer seems to me to indicate otherwise.
l’m surprised you can’t run Klipper, but I have to admit I don’t recall what printer you have.
That is also my understanding of how Klipper and OctoPrint each work. So, OctoPrint simply sends ASCII g-code to the controller board, a process that sounds like less overhead than Klipper’s interpreting g-code and then sending the machine code to the printer. Or, am I missing something?
re:not running Klipper … ignorance is bliss until … oh, well. The delta is run by a Lerdge board and the other runs a proprietary version of Marlin. Now that you’ve made me think, I’ll have to check to see if its ARM processor is compatible.
Ah, the thing you are missing ???: the difference is that the printer’s control board (MCU) doesn’t have to do the interpreting (the Pi, with it’s much more powerful CPU, handles that job). This greatly reduces the processing burden on the MCU.
Ahh, Ok. I read “Remember, OctoPrint adds quite a bit of overhead” as referring to the Raspberry Pi, not as “Remember, OctoPrint adds quite a bit of overhead” to the MCU.
Well, after getting my printer working with @Ender5r 's recommendations, I have now decided to break my printer again. I have started down the Klipper path. I am going to start a new thread with a problem I am having with move errors.
