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

[clough42]

Recv: -0.24115 -0.06140 +0.05835 +0.12860 +0.13910
Recv: -0.20715 -0.00765 +0.10510 +0.17160 +0.15835
Recv: -0.27265 -0.02565 +0.08585 +0.16560 +0.20235
Recv: -0.34990 -0.09965 +0.03785 +0.13285 +0.15435
Recv: -0.39390 -0.15590 +0.00960 +0.11010 +0.15535

That's interesting... I didn't know there was a Corrected Bed Height vs. Bed Topology:
section to the report. That is new. I'll have to look at the code to see what that is doing. But if the report is orientated correctly for your bed it is saying the front left is almost .4mm below the mean and the front right is .15mm above the mean. Going diagonally, you have .5mm of difference from front left to back right. And .4mm difference from back left to front right. That is a lot. The Auto Bed Leveling should be able to adjust for that, but you will get better prints if you physically adjust out some of that error.

At this point if you manually adjust your bed to bring all those numbers closer to zero, you will be able to see if there is a warp or a bulge in the bed. What will happen in the case of a warp or bulge is you will see a row or column start off +, go to - and then flip back to +. (or start -, goto +, and then back to -) If you see that on any column or row, you have a non-flat bed and there is some kind of warp. If you see that happen in both a row and a column, it will be likely the intersection of the two is the location of the bulge. But that will only show up on the Topological Map if you have it adjusted closer to level.

Just realized I never came back with an update. I eventually got the bed shimmed to within .06mm of flat and it's good enough if I split the difference on the Z height.

After talking with a mechanical engineer at work, it seems that this is typical. Flat glass really isn't very rigid. It tends to take a bow, usually across the diagonal. Once it takes this bow, it becomes very rigid and stable, but it's very tricky to keep it entirely flat.

[dacb]

Just realized I never came back with an update. I eventually got the bed shimmed to within .06mm of flat and it's good enough if I split the difference on the Z height.

After talking with a mechanical engineer at work, it seems that this is typical. Flat glass really isn't very rigid. It tends to take a bow, usually across the diagonal. Once it takes this bow, it becomes very rigid and stable, but it's very tricky to keep it entirely flat.

This is almost certainly why borosilicate glass is preferred for the application. I'd be curious to hear from someone who has used it.

[clough42]

This is almost certainly why borosilicate glass is preferred for the application. I'd be curious to hear from someone who has used it.

You're hearing from one now.

This is what I'm using:

http://rover.ebay.com/rover/1/711-53...mtid=824&kw=lg

I have a high-power silicone bed heater, and I was exploding ordinary window glass. It turns out I was going a little too hot (140C) due to a thermistor configuration problem, but the heater was getting there so fast that the glass couldn't take the thermal stress and it was shattering. The borosilicate glass takes it just fine. I have since fixed my thermistor issue, but I still use the borosilicate glass.

[dacb]

You're hearing from one now.

This is what I'm using:

http://rover.ebay.com/rover/1/711-53...mtid=824&kw=lg

I have a high-power silicone bed heater, and I was exploding ordinary window glass. It turns out I was going a little too hot (140C) due to a thermistor configuration problem, but the heater was getting there so fast that the glass couldn't take the thermal stress and it was shattering. The borosilicate glass takes it just fine. I have since fixed my thermistor issue, but I still use the borosilicate glass.

Terrific information. So even with the borosilicate you see deformation of the glass plane? Interesting.

[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

[Roxy]

That doesn't sound right. Whether the GCode comes from the host control program or from the SD Memory card, the commands get handled the same way.

I think there is something else going on here.

[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.

[Roxy]

As a side note to all the MakerFarm people running the BeckDac fork at: https://github.com/beckdac/Marlin

Here are my thoughts: This branch was very helpful and was extremely stable for the last 18 months. People with MakerFarm machines could just load it and use it. And for sure... It would just plain work. It was very stable! (Good job BeckDac!!!!)

Probably what makes sense now is if anybody with a MakerFarm machine has moved over to RC-7 of Marlin, we should set up a directory with your Configuration.h files and make it easy for people to get their machines running RC-7 too. If you have Configuration.h, Configuration_adv.h and a Pins.h file that are working with MakerFarm hardware, please let me know. I'll make a directory in the examples folder and people will be able to duplicate your setup very easily.