search

RF1000community / Repetier-Firmware

Community version of the firmware for the Renkforce RF1000 and RF2000 3D Printers
http://www.rf1000.de
16 stars 12 forks source link

Heatbed scan abort nozzle grinding #204

Closed darenst closed 4 years ago

darenst commented 4 years ago

When heatbed scan aborts moveZ() if performed before homing to clear the nozzle from heatbed, that seems logical, but moveZ() breaks and do not move the bed if scan is aborted?

This may cause the nozzle to grind the bed. https://github.com/RF1000community/Repetier-Firmware/blob/c0cda316fb83839f31ec99d1d1dcae0fbfd7db26/Repetier/RF.cpp#L4757 https://github.com/RF1000community/Repetier-Firmware/blob/c0cda316fb83839f31ec99d1d1dcae0fbfd7db26/Repetier/RF.cpp#L503

Nibbels commented 4 years ago

Hello @darenst

thank you for your thoughts. I had to think about what you mean.

I see:

So it looks like it would actually work. Do you have some special case where your printer does not show the expected behaviour?

If you find such bugs, dont hesitate to post them here! I did the same for 2 years towards conrad :D And yes... this code is not easy to understand in many sections. I did my best to go towards more clean code however

Greetings

darenst commented 4 years ago

Hello @Nibbels

I'm sorry, this was completely wrong on my part. My error message was overwritten by SD card error and I did not realize the actual fault. I tried again and received the message about max compensation.

This is what happened: -I changed the extruder for a 1.75mm. -Updated firmware (from Conrad firmware 1.38) and run a HeatBedScan. During scan the max compensation was reached (about 50% scanned) and the XY homed without moving z, as a result the nozzle crashed hard into the bed chipping out the corner of the heatbed.

I cleared EEPROM and moved z-endstop closer to the nozzle. Now, I can't reproduce this, It's working!

Cheers!

Nibbels commented 4 years ago

Hmm weird behaviour.

I will still keep this in mind but I dont think this is normal behaviour. There should always be this spacing when the homing happens.

You did use 1.45.00 ? Versions from 1.42.xx till 1.43.99 might have some stack overflow problems because of extensive ram usage when using the Sd lib. Bugs using those versions might thus be untraceable.

Tipps about the max compensation: We have some limit on how much we can press the z button without destroying it. The button of a RF1000 is some microswitch. I dont know how much we can drive over this trigger point but we once set it to 0.8mm max. At the RF2000 and RF2000v2 there is more drive over distance possible. The RF2000 has a rather stupid pin which is supposed to slide into the optical sensor. It will press on the sensor after ~1.3mm driving in. But if you file the pins cylinder part down you can drive into the sensor 3.3mm. See here: http://www.rf1000.de/viewtopic.php?f=74&t=2318&p=23877&hilit=Z_ENDSTOP_DRIVE_OVER+3.3f#p23877 The RF2000v2 already has an improved pin. This makes >3.3mm driving possible.

The limit is configured here:

RF1000.h, RF2000.h, RF2000v2.h:

define Z_ENDSTOP_DRIVE_OVER 0.8f //mm

define Z_ENDSTOP_DRIVE_OVER 1.3f //mm

define Z_ENDSTOP_DRIVE_OVER 3.3f //mm

I always set my RF2000 to 3.3mm because I then can configure the z screw by pure eye vision.