Ender 5 Pro with CR Touch bed adhesion issues

[Corley]

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 in advance for any help.

[Ender5r]

Here's a link to my process: https://forum.makewithtech.com/forum...1530#post11530

I find the squares are a really good way to get just the right amount of Z Offset. And I find Dimafix to be a fantastic adhesive and release agent.

[Corley]

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.

Thanks again for the help.

[Ender5r]

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.

[[email protected]]

I found this looking through the posts. Once you go Klipper you never go back. I have not bumped my speed much, but have almost 100% successful prints.

[Ender5r]

Have you done the Input Shaping and Pressure Advance?

[[email protected]]

I have. I mounted an ADXL345 on each of my printers and have it wired to the Pi. That way I can run input shaper at any time. I need to do it again - just to check. There are some good documents on how to do it. I run a ringing tower before and after - just to see the change.

[Corley]

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.

Thanks again for the help.

[Ender5r]

Here's a video from a guy who lives and breathes Klipper: https://www.youtube.com/watch?v=iNHta6zljoM.

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.

[Corley]

I am intrigued by this. I will be trying it out with my Octopi install.

[Ender5r]

Remember, OctoPrint adds quite a bit of overhead. Not saying it's wrong; just that fluiddPi and Mainsail have much lower overhead.

[Alan]

Remember, OctoPrint adds quite a bit of overhead. Not saying it's wrong; just that fluiddPi and Mainsail have much lower overhead.

I'm surprised. Is feeding ASCII to the motherboard that much extra overhead? The CPU in my Pi 4b is currently ~6% peak.

Thanks!

P.S. -- I wish I had a printer that I could convert to Klipper. ☹

[Ender5r]

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.

[Alan]

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.

Cheers!

[Ender5r]

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.

[Alan]

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.

Cheers

[Ender5r]

My bad. Maybe I should have said, "OctoPrint doesn't reduce the burden on the MCU the way Klipper does".

[Corley]

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.

Thanks again everyone.