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

[orionthunter]

If you want to leave safe homing on you could follow your G28 command with G28 X0 Y0 to return to the corner before running G29

[Drone]

My LCD will go blank at random times, but always if the Z probe on the servo contacts the bed before retracting. The reason for me is the Arduino board doesn't have the voltage needed when the servo stalls momentarily if it contacts the bed during retract. Even after I installed the advanced G29 code from Roxy with the DACB fork and solved bed interference problems with servo retract since the new code does a Z raise before retract, I had a couple of isolated incidents of the Arduino rebooting due to lack of power. The solution for me was simple, just keep the USB cable connected to my laptop whenever the printer is turned on. Even with the laptop closed and sleeping it provides additional 5v through the USB to the Arduino board. It would probably be better to provide additional 5v power from another source to the Arduino, but since this works perfectly for me I just haven't bothered yet. If your LCD resets, it is likely a power to the board issue. Figure out a way to provide more power and it might solve the problem for you as well.

[printbus]

My LCD will go blank at random times, but always if the Z probe on the servo contacts the bed before retracting. The reason for me is the Arduino board doesn't have the voltage needed when the servo stalls momentarily if it contacts the bed during retract. Even after I installed the advanced G29 code from Roxy with the DACB fork and solved bed interference problems with servo retract since the new code does a Z raise before retract, I had a couple of isolated incidents of the Arduino rebooting due to lack of power. The solution for me was simple, just keep the USB cable connected to my laptop whenever the printer is turned on. Even with the laptop closed and sleeping it provides additional 5v through the USB to the Arduino board. It would probably be better to provide additional 5v power from another source to the Arduino, but since this works perfectly for me I just haven't bothered yet. If your LCD resets, it is likely a power to the board issue. Figure out a way to provide more power and it might solve the problem for you as well.

Yep. I go into the numbers starting with this post in my build thread - http://3dprintboard.com/showthread.p...ll=1#post28854. After looking at the design of the MEGA2560 board, my conclusion is that the on-board 5V regulator is pretty much maxed out with the basic LCD-equipped MakerFarm printer. If you add an ABL servo or any other 5V loads onto the printer, you should provide your own 5V source or keep the printer USB port plugged into something that can provide 5V power via USB, thereby bypassing the on-board regulator. I can't help but wonder how many ABL issues are caused by people trying to run the printer standalone off a 12V supply.

FOLLOWUP COMMENT: Stalling a servo will cause the current draw to the servo to surge, further increasing the likelihood of a problem. And my guess is the LCD going blank is likely a sign that the Arduino board is undergoing a reboot.

[RaySuave]

After some more googling, starting from a fresh version of Dacb's MakerFarm fork of Marlin firmware a few times, and using different versions of Arduino for flashing (on 1.0.5-r2 currently) I still have the issue of the servo arm rubbing the bed on retraction after the G28 command (homing). I also used Roxy's thread to invalidate the EEPROM in case this was a contributing factor. http://3dprintboard.com/showthread.p...lidate-Command Not sure what I'm doing wrong but it appears I am the only one still having this issue after using Dacb's firmware. Any other suggestions on what I could be doing wrong?

I did manage to successfully invoke the G28 command for the ABL procedure and with reading some other posts like the one above, I now understand why I was having the blank LCD issue after the servo arm rubs the bed.

After successfully running the ABL procedure, I have two more questions regarding fine tuning:

- When starting a print after ABL, my nozzle is too low, needs to raise about 0.2mm. Is bumping the "Z_PROBE_OFFSET_FROM_EXTRUDER" value up the only change to make in the firmware?

- For adjusting the probing position, how do the LEFT, RIGHT, FRONT, and BACK probe positions correlate to looking at the printer/bed head-on from the front?

Thanks in advance...

[Roxy]

After some more googling, starting from a fresh version of Dacb's MakerFarm fork of Marlin firmware a few times, and using different versions of Arduino for flashing (on 1.0.5-r2 currently) I still have the issue of the servo arm rubbing the bed on retraction after the G28 command (homing). I also used Roxy's thread to invalidate the EEPROM in case this was a contributing factor. http://3dprintboard.com/showthread.p...lidate-Command Not sure what I'm doing wrong but it appears I am the only one still having this issue after using Dacb's firmware. Any other suggestions on what I could be doing wrong?

In the Enhanced G29 thread... http://3dprintboard.com/showthread.p...ed-G29-command In the first post... It says:

This step is also optional. Because of how some people's Z-Probe is constructed, it is best to raise the nozzle prior to retracting the probe. The Enhanced G29 code handles this circumstance. But as it turns out, the stock G28 command is also guilty of this bad behavior. If you need the G28 command to raise the nozzle prior to retracting the probe, make the following changes in Marlin_Main.cpp :

Find the following code:
// Retract Servo endstop if enabled

#ifdef SERVO_ENDSTOPS
if (servo_endstops[axis] > -1) {
servos[servo_endstops[axis]].write(servo_endstop_angles[axis * 2 + 1]);
}
#endif
#if defined (ENABLE_AUTO_BED_LEVELING) && (PROBE_SERVO_DEACTIVATION_DELAY > 0)
if (axis==Z_AXIS) retract_z_probe();
#endif
add these lines of code immediately after the "// Retract Servo endstop if enabled" comment.
#if defined (ENABLE_AUTO_BED_LEVELING) && (PROBE_SERVO_DEACTIVATION_DELAY > 0)
if (axis==Z_AXIS)
do_blocking_move_relative(0, 0, Z_RAISE_BEFORE_PROBING);
#endif

It should look like this when you have made the change:

// Retract Servo endstop if enabled
#if defined (ENABLE_AUTO_BED_LEVELING) && (PROBE_SERVO_DEACTIVATION_DELAY > 0)
if (axis==Z_AXIS)
do_blocking_move_relative(0, 0, Z_RAISE_BEFORE_PROBING);
#endif

#ifdef SERVO_ENDSTOPS
if (servo_endstops[axis] > -1) {
servos[servo_endstops[axis]].write(servo_endstop_angles[axis * 2 + 1]);
}
#endif
#if defined (ENABLE_AUTO_BED_LEVELING) && (PROBE_SERVO_DEACTIVATION_DELAY > 0)
if (axis==Z_AXIS) retract_z_probe();
#endif

I don't know off hand if this change is folded into the DACB fork. But if it isn't you might want to give it a try.

I did manage to successfully invoke the G28 command for the ABL procedure and with reading some other posts like the one above, I now understand why I was having the blank LCD issue after the servo arm rubs the bed.

After successfully running the ABL procedure, I have two more questions regarding fine tuning:

- When starting a print after ABL, my nozzle is too low, needs to raise about 0.2mm. Is bumping the "

Z_PROBE_OFFSET_FROM_EXTRUDER" value up the only change to make in the firmware?

There are a number of configuration settings you can play with to get it tuned for your printer. Have you tried adjusting things with:

 #define Z_RAISE_BEFORE_HOMING 9       // (in mm) Raise Z before homing (G28) for Probe Clearance.
                                        // Be sure you have this distance over your Z_MAX_POS in case
  #define Z_RAISE_BEFORE_PROBING 9     //How much the extruder will be raised before traveling to the first probing point.
  #define Z_RAISE_BETWEEN_PROBINGS 5  //How much the extruder will be raised when traveling from between next probing points

- For adjusting the probing position, how do the LEFT, RIGHT, FRONT, and BACK probe positions correlate to looking at the printer/bed head-on from the front?

Left, Right, Front and Back were the result of a long discussion on what the names should be. The problem is people have their origin in different places on the bed. This was an attempt to not confuse things by saying things like X_MAX or Y_MIN. It remains to be seen if this was a good choice of names. But if you imagine your part on the bed, the Front would be the lowest Y coordinate, Back would be the largest Y coordinate. Left and Right would be the lowest and largest X coordinate of the part.

[RaySuave]

I don't know off hand if this change is folded into the DACB fork. But if it isn't you might want to give it a try.

Left, Right, Front and Back were the result of a long discussion on what the names should be. The problem is people have their origin in different places on the bed. This was an attempt to not confuse things by saying things like X_MAX or Y_MIN. It remains to be seen if this was a good choice of names. But if you imagine your part on the bed, the Front would be the lowest Y coordinate, Back would be the largest Y coordinate. Left and Right would be the lowest and largest X coordinate of the part.

Thanks for the tips. It turns out that the code changes recommended were already in the fork so what I ended up doing was take a dremel and rounded off the micro switch case edge where it was contacting the bed since the interference was pretty small. Problem Solved!! Can post a pic if needed.

Regarding the probe position orientation, it would probably be helpful to put in some short descriptive comments after each probe position on the next fork update. Your explanation was clear and made complete sense, now I have the probe area area perfectly adjusted.

[BgHurt]

I too have the issue of the Z axis not raising after the G28 before retractions. I put some debug code into the G28 to see if it was indeed running the do_blocking_move(blah, blah, +Z_RAISE_BETWEEN_PROBINGS)

It does run the command, but it never actually does the move on my arduino. Not sure if it is already in the middle of something so the function never runs. or if the move is no good. Not sure, but regardless it never lifts the Z before it retracts.

Stock dacb, just compiled and pushed to my RAMPS. Didnt work, so I put some SERIALPGM's in to get where it was in the program loops.

[dacb]

Hi all,
I have just tested a bunch of the changes people have posted including Roxy's. I'll get them into the fork in the next couple of days after a few more prints. Stay tuned!

[Roxy]

Hi all,
I have just tested a bunch of the changes people have posted including Roxy's. I'll get them into the fork in the next couple of days after a few more prints. Stay tuned!

Darn! I wish I knew you were going to do that... I fixed a bug in the Bed Level Topology Report for the Front-Right case:

#ifdef ORIGIN_FRONT_RIGHT
for(yy=0; yy<n_points; yy++ {
for(xx=0; xx<n_points; xx++) {
SERIAL_PROTOCOLPGM(" ");
if ( eqnBVector[ (n_points*n_points)-yy-(xx*n_points)-1 ]-mean >= 0.0)
SERIAL_PROTOCOLPGM("+");
else
SERIAL_PROTOCOLPGM("-"); // we need this extra - because Proterface uses a preportional
// font and it causes the columns to not line up nice without it.
SERIAL_PROTOCOL_F( eqnBVector[ (n_points*n_points)-yy-(xx*n_points)-1 ]-mean, 5);
}
SERIAL_PROTOCOLPGM(" \n");
}
SERIAL_PROTOCOLPGM(" \n");
#endif // ORIGIN_FRONT_RIGHT

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