ABL problem - beckdac marlin branch/Roxy improvements - Y axis not moving during G29

Quote:

---

Originally Posted by TopJimmyCooks

Working on another i3v - Identical to my 8" except it's a 10", bought at the same time last summer. We were having problems with the G29 not working. When you run the g28, homes all axes normally. when running g29 directly after g28 using the pronterface terminal:

*x axis moves into position, but y axis stays at home position (Y0, where the probe points are at y50, 100 and 150 for a 9x9 grid in the firmware).
*probes the 3 X coordinates given in the firmware but the y axis never moves. So it probes 9 times moving back and forth in a line at y0.
*at that point the nozzle is still at y0 geographically but thinks it is at y150 per the LCD, where it would normally be at completion of successful ABL

Comments:
*This firmware works correctly on my 8".
* i checked the wiring, everything is identical. endstops are on the same ends, set up to home at the back right corner just like mine. bone stock i3V basically except the servo upgrade.
*the 10" printer works fine and prints with fixed z endstop and stock firmware when flashed.
*everything moves around fine under pronterface control.

We're stumped and appreciate any ideas. Thanks.

---

Been there. Done that. Un-comment this line:

Code:

---

//#define DISABLE_MAX_ENDSTOPS

---

I struggled through the same issue a couple of days ago on a new i3 built with a leftover frame from my i3v upgrade and cheap eBay electronics. The default config on the beckdac fork has the max endstops enabled, but without pullups enabled or anything connected to the pins, they're just floating, apparently picking up ground noise from the motors. I spent a lot of time debugging and figured out that the firmware is reading a max endstop trigger during the move away from home, usually on Y. The homing routines don't check for this, and just assume everything is fine.

I submitted a pull request to the beckdac repo to disable the max endstops by default.

Quote:

---

Originally Posted by clough42

Been there. Done that.

...

I submitted a pull request to the beckdac repo to disable the max endstops by default.

---

Would it make sense to also enable the pullups by default? The pull ups are weak and won't hurt anything if somebody screws up and leaves them enabled when they don't need to be enabled.

I passed this on and will check it out on ours (uncommenting the define). Will reply back. Thanks.

Quote:

---

Originally Posted by Roxy

TechMasterJoe: Unless you have a real need to save (and modify) your configuration settings, it is best to turn off:

#define EEPROM_SETTINGS
#define EEPROM_CHITCHAT

But that issue aside, can you move the Y-Axis back and forth in Pronterface?

---

in Pronterface, and Repetier-Host
it even prints just fine off to work be home in a few hours

thanks for the insite clough i wil try that later
my servo 1 is on my Ymax aswell so that is a light trigger every 10-20ms

turning max endstops off worked thanks
just sorting out another glitch (not taking in to account Z offset from probe)
fixed
working good

Clough42:
Haven't heard back on Disable_Max_Endstops on the other printer yet. Hoping this nails their problem.

Roxy:
>>>g28
SENDING:G28
>>>m114
SENDING:M114
X:-31.00 Y:-7.00 Z:8.57 E:0.00 Count X: -31.00 Y:-7.00 Z:8.57

the Z offset is fine, i leave it at 5.57 in firmware and very rarely make a small adjustment in z offset when slicing. The issue I have is with the X and Y being off by the firmware extruder from z probe offset distances.

Quote:

---

Originally Posted by Roxy

Would it make sense to also enable the pullups by default? The pull ups are weak and won't hurt anything if somebody screws up and leaves them enabled when they don't need to be enabled.

---

I think so. Its probably safer because it removes the intermittent case. Disconnected endstops will show as triggered if they're accidentally enabled.

This came from mwyrick. I haven't had time to check it out, but I think what he says (and did) is correct.

Y-Axis moving during Z Raise for Unsafe Home

Roxy,
I noticed you helping several people with the problem of the Y-Axis moving with the initial Z Raise during homing when Safe homing is not enabled. I have a fix for that that I have not seen in the code yet. I wanted to share it with you. It also fixes G28 finishing too high when doing a raising before retracting.

In Marlin_main.cpp in the homeaxis function, after

axis_is_at_home(axis);
destination[axis] = current_position[axis];
feedrate = 0.0;
endstops_hit_on_purpose();
axis_known_position[axis] = true;

I added: plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]);

The problem was after current_position was set to zero, the planner position was not set and the delta for the move was too large by the amount of the commanded move final to find the switch, -2*home_retract_mm. With this change I can now issue just a G28 and have to current_position correct so I don't need to run G29 if I don't want to. Or run with Z_SAFE_HOME disabled.

- Michael