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

[uncle_bob]

Yes, I am heating the bed. With the old firmware I would adjust the offset in the menu system and then put that number in the firmware. This saved a few extra steps. The issue I am having is the homing command and the bed leveling command are giving me two different nozzle heights.

Hi

The homing command is going to take you to the point that the end stops trigger. For X and Y that's probably ok. For Z ... not so much. The old approach was to use the Z probe as the Z end stop. Same probe, same height, problem solved.

Bob

[systemslave]

Is there a way to automatically issue the g28 and g29 from the firmware prior to printing? I currently have to run it from the terminal or insert it into the gcode file.

[AbuMaia]

I have Slic3r put it into the G-code for me automatically whenever I slice anything.

Printer Settings tab
Custom G-code

M190 S[first_layer_bed_temperature] ; set bed temperature, wait for it to reach target before proceeding
M117 Homing...
G28
M104 S[first_layer_temperature] ; set hotend temperature. Use M109 to set and wait
M117 Auto Bed Leveling...
G29 P4 ; auto level
G1 X99 Y99 Z1 F1500; reposition extruder
M109 S[first_layer_temperature] ; in case the hotend didn't heat up fully during ABL
M117 Printing...

[systemslave]

Thanks AbuMaia, I get that. I am doing the same with Cura. I would like to trigger it in the firmware instead of depending on the slicer to embed it. Even in the case where the leveling ran twice because it was embedded in the gcode the machine would not be hurt.

[uncle_bob]

Hi

Pretty much every slicer out there has a section for gcode to send when the printer is started and when it is stopped. It is well worth looking into *what* should best be in those sections. You can do all sorts of cute things (wipe the print head at start, move the part out of the way at end) with them. There is often a bit of fine tuning in terms of what goes first or last in the file.

Bob

[tsteever]

I am getting some inconsistent results. I have had about 50% fail rate since updating to the new firmware.

I think I have tracked my problem down to the ABL probe. It seems to over extend which results in a crash. I readjusted the extend and retract angles. I tested these by running a g28 and then a g29 and it worked. I shut down the printer.

The next day I ran a print and it failed. Looks like the ABL probe is using the old values even though the firmware has been updated with new values.

Ideas on where to start?

[dustmann]

Do you have eeprom settings enabled? It sounds like perhaps you have a conflict between your firmware and the eeprom settings for your Z probe. Try running an M502 command followed by M500 to rule it out.

[kd7eir]

I am getting some inconsistent results. I have had about 50% fail rate since updating to the new firmware.

I think I have tracked my problem down to the ABL probe. It seems to over extend which results in a crash. I readjusted the extend and retract angles. I tested these by running a g28 and then a g29 and it worked. I shut down the printer.

The next day I ran a print and it failed. Looks like the ABL probe is using the old values even though the firmware has been updated with new values.

Ideas on where to start?

Did you compile and uploaded the firmware after changing the servo endpoints?

Try testing with this, making sure the probe ends up where you expect

M401 - deploys the probe
M402 - retracts the probe

[tsteever]

What exactly do those commands do?

I have the eeprom disabled
//#define EEPROM_SETTINGS

[tsteever]

Yes, I used the M280 commands to determine to correct angles. Uploaded the changes and then used the m401 and m402 commands to check. I even did a g28 and g29 to confirm. All work well.

The next time I fired up the machine the servo angles are wonky.

Did you compile and uploaded the firmware after changing the servo endpoints?

Try testing with this, making sure the probe ends up where you expect

M401 - deploys the probe
M402 - retracts the probe