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

[AbuMaia]

Roxy, there's a new update to the EricZalm Marlin addressing something about the M0/M1. https://github.com/ErikZalm/Marlin/pull/1159 Think this might have something to do with the occasional "wait for user"?

[Roxy]

Roxy, there's a new update to the EricZalm Marlin addressing something about the M0/M1. https://github.com/ErikZalm/Marlin/pull/1159 Think this might have something to do with the occasional "wait for user"?

Thanks! I guess I better get these changes! I wonder which path I should go? I really should get DACB's fork ported to my machine. But I want the M0/M1 changes.

DACB, are you going to re-merge with the latest code soon? If so, I'll wait so I don't have to do the port twice. (I normally wouldn't be trying to get out of a merge / port, but I'm too busy with other things right now.)

[clough42]

Has anyone else had any trouble with the auto-bed-level sometimes not running or not completing?

My custom start gcode in Slic3r heats the bed, starts the hot ends heating and then runs G28 followed by G29 to home and auto-level. After the G29, it moves the extruder tips just off the front edge of the bed (Y=215, Z=0), primes them and then wipes them onto the glass.

Sometimes, the G28 runs, and it homes in the center, but the G29 sequence doesn't run and the printer is left with the Z level off by about 6mm. Those first layers don't adhere to the bed real well when they're applied from 6mm up.

I haven't figured out how to reproduce it at will yet, but it seems to happen if I've already run one print job and haven't reset the printer. Or maybe it's just happening when the Z axis is high (90mm or more) and it takes a long time for the G28 Z probe.

Ideas?

[printbus]

Roxy, there's a new update to the EricZalm Marlin addressing something about the M0/M1. https://github.com/ErikZalm/Marlin/pull/1159 Think this might have something to do with the occasional "wait for user"?

Has anyone looked at the change to understand what it does? At just a glance, I couldn't tell if was changing how M0/M1 might be falsely detected, or changing how the M0/M1 command string is parsed when it is received.

Has anyone else had any trouble with the auto-bed-level sometimes not running or not completing?

Rather than let the question linger, I'll add my take even though I don't have ABL. Multiple people seem to observed quirky issues with an ABL firmware build, including the M0/M1 issue here where for some reason Marlin thinks an command has been received that says to wait for a user prompt. The possibility of stack or variable space corruption has came up. There's a concern that whatever the problem is, it may be related to having a build that includes both the ABL code and the LCD code. One user has recently been fighting issues with a reprap based on an I2C LCD interface. I2C adds considerably more software overhead than the more common REPRAP/ULTIPANEL LCD, so this raises the possibility that maybe Marlin is running into timing constraints that can't always be met with the processor cycles it has to work with. On the hardware side, it has also been determined that the 5V regulator on the MEGA2560 board can't always handle the extra load of the ABL servo, and running the printer standalone presents a risk of the 5V power cutting out or perhaps dropping off. ABL printers should either have a dedicated 5V source added in to provide 5V to RAMPS for the servo, or at least always have the printer connected to a USB source.

[AbuMaia]

Has anyone else had any trouble with the auto-bed-level sometimes not running or not completing?

Sometimes, the G28 runs, and it homes in the center, but the G29 sequence doesn't run and the printer is left with the Z level off by about 6mm. Those first layers don't adhere to the bed real well when they're applied from 6mm up.

I haven't figured out how to reproduce it at will yet, but it seems to happen if I've already run one print job and haven't reset the printer. Or maybe it's just happening when the Z axis is high (90mm or more) and it takes a long time for the G28 Z probe.

Ideas?

I used to have that problem. And yes, it was because I had finished a tall print, and it took the printer too long to home the Z axis that the X and Y steppers timed out and were deactivated, losing the X and Y home position. G29 will not run in this case, so I changed the stepper deactivating delay from (I think it was) 40 to 150. I haven't had the problem since. Sorry, I cannot remember where the setting is in the firmware.

edit: configuration_adv.h
//default stepper release if idle
#define DEFAULT_STEPPER_DEACTIVE_TIME 60

I changed the 60 to 150.

[jtice]

Has anyone else had any trouble with the auto-bed-level sometimes not running or not completing?

My custom start gcode in Slic3r heats the bed, starts the hot ends heating and then runs G28 followed by G29 to home and auto-level. After the G29, it moves the extruder tips just off the front edge of the bed (Y=215, Z=0), primes them and then wipes them onto the glass.

Sometimes, the G28 runs, and it homes in the center, but the G29 sequence doesn't run and the printer is left with the Z level off by about 6mm. Those first layers don't adhere to the bed real well when they're applied from 6mm up.

I haven't figured out how to reproduce it at will yet, but it seems to happen if I've already run one print job and haven't reset the printer. Or maybe it's just happening when the Z axis is high (90mm or more) and it takes a long time for the G28 Z probe.

Ideas?

For the most part, mine works well, but I have alot of random times it fails.
Sometimes auto homing will not safe home in the middle, just homes in the corner, if it does this, then the 9 bed leveling test locations are all shifted more toward the homing corner.
There area also times it will skip the bed leveling completely, and often if that happens, bad things follow, the printer will do odd things like try to start the print 5" off the print bed,
so the belts will slip while the printer tries to go out of range, I have to kill the power to stop it.
I have found no pattern to any of this, I can usually just start the print again, and its fine.
I have noticed that I think it helps if I push the bed and extruder to the extruder is near centered before I start the print.
If the extruder is near homed before I start the print, it tends to fail more often.

[Roxy]

This is scary... There is some problem causing flakey behavior that we don't understand!

[AbuMaia]

A test to see if you're affected by the XY stepper motors timing out and preventing a G29, move your Z axis to its max position, then do a G28 followed by a G29. You may be able to hear during the Z leg of the G28 the X and Y motors deactivating, and the G29 may not work. It may tell you to "Home X and Y before homing Z" or something like that.

Or your printer may be fast enough to home the entire distance of Z in less than 1 minute and beat the stepper deactivation, and not be affected by this.

[MiniMadRyan]

This is scary... There is some problem causing flakey behavior that we don't understand!

Agreed. For myself, even after some fiddling around, there were still inconsistencies. I absolutely love what Roxy and Dacb have put together, and I still fully support their progress, but for the time being I've returned to the stock firmware and manual levelling just to get projects done before the holidays! Maybe this is a good reason to justify a 3rd printer to experiment with!

[dacb]

I have merged to the upstream Marlin_v1 with this commit: https://github.com/beckdac/Marlin/co...29b5184dab6fd0
and added the topology report fix, previously mentioned.

It is on a new branch: https://github.com/beckdac/Marlin/tr..._merge_11_2014

This is for the adventurous. I've only done a handful of prints so far.