Marlin firmware fork for MakerFarm i3v w/ auto bed level & Roxy's enhancements

[systemslave]

My weekend project was updating my Makerfarm i3v12 with Marlin and ABL. G28 and G29 work great from the terminal, but when I tried to run my bed leveling gcode from the sd card the printer tries to probe the Z at X0, Y0. I have Z_SAFE_HOMING set as follows, so I am confused. Can you give me a quick pointer where I have gone astray?

#define Z_SAFE_HOMING // This feature is meant to avoid Z homing with probe outside the bed area.
// When defined, it will:
// - Allow Z homing only after X and Y homing AND stepper drivers still enabled
// - If stepper drivers timeout, it will need X and Y homing again before Z homing
// - Position the probe in a defined XY point before Z Homing when homing all axis (G28)
// - Block Z homing only when the probe is outside bed area.

#ifdef Z_SAFE_HOMING

#define Z_SAFE_HOMING_X_POINT (X_MAX_LENGTH/2) // X point for Z homing when homing all axis (G28)
#define Z_SAFE_HOMING_Y_POINT (Y_MAX_LENGTH/2) // Y point for Z homing when homing all axis (G28)

#endif

[clough42]

My weekend project was updating my Makerfarm i3v12 with Marlin and ABL. G28 and G29 work great from the terminal, but when I tried to run my bed leveling gcode from the sd card the printer tries to probe the Z at X0, Y0. I have Z_SAFE_HOMING set as follows, so I am confused. Can you give me a quick pointer where I have gone astray?

#define Z_SAFE_HOMING // This feature is meant to avoid Z homing with probe outside the bed area.
// When defined, it will:
// - Allow Z homing only after X and Y homing AND stepper drivers still enabled
// - If stepper drivers timeout, it will need X and Y homing again before Z homing
// - Position the probe in a defined XY point before Z Homing when homing all axis (G28)
// - Block Z homing only when the probe is outside bed area.

#ifdef Z_SAFE_HOMING

#define Z_SAFE_HOMING_X_POINT (X_MAX_LENGTH/2) // X point for Z homing when homing all axis (G28)
#define Z_SAFE_HOMING_Y_POINT (Y_MAX_LENGTH/2) // Y point for Z homing when homing all axis (G28)

#endif

I have seen situations where the current draw of the probe servo causes the Ardunio to reset. This could get you different results between the host program and the SD card because the SD interpretation would stop, but the host would keep going once the firmware rebooted.

You could try putting the servo on a separate 5V supply, or even just unplug the servo and extend the probe manually to see if it makes a difference.

[Roxy]

I have seen situations where the current draw of the probe servo causes the Ardunio to reset. This could get you different results between the host program and the SD card because the SD interpretation would stop, but the host would keep going once the firmware rebooted.

You could try putting the servo on a separate 5V supply, or even just unplug the servo and extend the probe manually to see if it makes a difference.

Good thinking! That is a good thing to ask: How are you powering your servo?

[systemslave]

Thank you Roxy and clough42 for the quick response. I actually built an off board power supply to compensate for current draw. I am using a RUMBA board and it did not source enough power to run the servo. I really liked the servo headers and power jumper on a RAMPS board, so I built a daughter board for my RUMBA. I am picking up the PWM signal from pin 5. I pull 12v from main and regulate it to 5v on the sweet little daughter board where I have two servo headers plus three extra power pin sets. Pins 5 and 6 (PWM) get pulled into the daughter board and routed to the servo pin headers. I have been running a pi3 running octopi on one of the power sets so that I have WiFi control of the printer. I pulled the pi off the first time this happened because I figured (like clough42) that I was short juice. It didn't help. The servo isn't drawing current from the Board. The probe draws the same current whether it is on the swing arm or not. By the way clough42, it is your swing arm design. Thank you for that.

And as an aside, I print on borosilicate glass with PEI surface. I use the peel and stick PEI sheets.

[clough42]

Thank you Roxy and clough42 for the quick response. I actually built an off board power supply to compensate for current draw. I am using a RUMBA board and it did not source enough power to run the servo. I really liked the servo headers and power jumper on a RAMPS board, so I built a daughter board for my RUMBA. I am picking up the PWM signal from pin 5. I pull 12v from main and regulate it to 5v on the sweet little daughter board where I have two servo headers plus three extra power pin sets. Pins 5 and 6 (PWM) get pulled into the daughter board and routed to the servo pin headers. I have been running a pi3 running octopi on one of the power sets so that I have WiFi control of the printer. I pulled the pi off the first time this happened because I figured (like clough42) that I was short juice. It didn't help. The servo isn't drawing current from the Board. The probe draws the same current whether it is on the swing arm or not. By the way clough42, it is your swing arm design. Thank you for that.

And as an aside, I print on borosilicate glass with PEI surface. I use the peel and stick PEI sheets.

You're welcome.

I run all of my printers with used HP DPS-600PB server power supplies. I power a Raspberry Pi, the RAMPS board (VCC) and the RAMPS servo bus (+5V) direct from the 5VSB on the power supply, with three separate wires back to the source. This way, the electronics are always on. I switch the power supply on and off using the PS_ON line from the RAMPS power header, so the 12V bus for the motors and heaters is only on when needed.

I'm running an industrial silicone heater pad under borosilicate glass on my 12", and it delivers a lot of power. I have to use borosilicate because ordinary glass explodes during the fast warmup cycle.