End stop does not trigger after first homing

jgude

Hi!
I have a weird issue. When I home my x or y it is fine...but if I home for a second time..or begin a print etc.. the end stop is not triggered and my printhead crashes at my frame.

Even after a first home the m119 command gives the correct values.

Any ideas?

Repetier

During print you might have it disabled (ALWAYS_CHECK_ENDSTOPS) but during second and third homing endstops will always be tested. Also M119 will always show current endstop state. So if you manually trigger/untigger and test with M119 it should change state correctly. Does that happen?

jgude

Yes manual trigger always gives the correct values. The problem is not during print.. allready when I hit home for a second time.. it will just ignore the endstop.. it worked fine but one of the hall-e endstops broke. I changed it with a mechanical endstop and changed the firmware accordingly..but now I have this issue :s

jgude

I also go back 15mm after homing to untrigger the mechanical endstop

Repetier

Did you enable pullup when you are now using mechanical endstops. Without the signal is not stable I think. But that is all and since it works on first home it is strange to not work any more.

What printer type is that on which board? Memory problems can be an issue with strange behaviour as well. Especially on deltas memory gets often an issue. Make sure on connection it reports around 1000 free bytes of ram on 8 bit boards.

jgude

I use core xy with radds/due board. But if first homing works all should be ok right? Home all works 1 time.. but home X and then y works only for x and it crashes in Y ...

jgude

I probably screwed things up when updating the firmware... I went back to an older version and it worked again... so my bad sorry

Repetier

On corexy you must ensure to untrigger endstops by going back a bit. Otherwise you get easy in troubles due to motor split on 2 motors that can confuse firmware.
But good to hear that old config worked.

ziegelstein

Hi, i 've got a simular problem.

with manual tiggering the endstops and checking the result wirth M119 L/H works fine.

But homing first x which is ok but than homing y ends in a crash, ignoring my hall e endstops. Or the other way around.

First homing one axis seems to be good, but the second go wrong.

Yesterday everything works well.

No idea. A few days earlyer same issue. Next day no problems, today again..

(ALWAYS_CHECK_ENDSTOPS) = 0

For Homing i used : the display linked to the radds, as well the repetier host, connectet with repetier server, and same issue with homing in web front end from the server.

Thats wy i think the problem is the repetier firmware or the hardware maybe?? the confusing point is, that for me there is no system visible.

Any ideas?

Repetier

Yes, it is firmware or hardware. In all cases the same function in firmware executes the homing, so it does not matter where you start homing.
Could it be that pullup for sensor is missing to get defined signals? Otherwise the cable to y endstop might be broken and work only sometimes depending on bending at broken position? You can also try a different endstop pin like ymax just tell firmware to use that instead for ymin. As it works sometimes I would think that it is either pullup or hardware related if it is so wanky.

ziegelstein

What i also did Yesterday evening to Home Just one Axis twice. The First homing was OK, the Seconds homing of Same Axis Crashes.. so i think it is more Software related.

To bei Sure that it is no issue from Stepper Signals: how should the shield of the Wire are connected to? At this time there ist no shield because i installed For x and y smart Stepper. The cable from Steppermotor to the smart Stepper Board ist very Short.

ziegelstein

Update:

I de and reinstalled Arduino IDE

I compiled the same version of my config.h again and for this moment everything ist working fine again..

--> Arduino Due issue?

ziegelstein

again, new update.

due to updated firmware as i wrote i enabled z-correction. And now homing is again in trouble.

In my opinion there is a direkt link with homing and z-correction. I enabled both: autoleve and Z correction.

There is a possible mistake in the firmware..using 1.03.

@repetier: Could you please check that ?

Repetier

I only test 1.0.4dev which is where all corrections go into and where all known bugs are fixed.
So you have autoleveling and distortion correction enabled. Can you check if disabling only one or both makes them work again. Not that the endstop check is anyhow related to these features. Only for z there might be chance if z probe is active.

What kind of printer do you have? Cartesian, core xy, dual x, delta ... as they have all different homing routines. Also which homing order and settings do you have, just to be sure.

ziegelstein

to answer:

#define DRIVE_SYSTEM 1 / z axis + xy H-gantry/core XY (x_motor=x+y...)

homing order: in settings i set to: x,y then z but mostly i home manually each axis z at last.

when i send M323 S1 (enabling distortion) then the homing gets in trouble. with S0 homing works - so the distortion algorithm enables the problem.

what i also discoverd is, that adjusting Z to get it to 0 with distortion disabled manually with "babystepps" and later activate distortion correction afer homing then z gets an offset and i have to set Z to 0 with babystepps again.

A new issue now: i have communication timeout and Error :Wrong checksum

But this is an other topic.

do you need my configuration.h as well?

Repetier

That makes a bit of sense. Homing with enabled distortion correction does not work. Looking into 1.0.4dev code for homing in Printer.cpp line 2019 you see

void Printer::homeAxis(bool xaxis, bool yaxis, bool zaxis) { // home non-delta printer

unparkSafety();

bool nocheck = isNoDestinationCheck();

setNoDestinationCheck(true);

#if defined(SUPPORT_LASER) && SUPPORT_LASER

bool oldLaser = LaserDriver::laserOn;

LaserDriver::laserOn = false;

#endif

float startX, startY, startZ;

realPosition(startX, startY, startZ);

#if DISTORTION_CORRECTION

bool distOn = Printer::distortion.isEnabled();

Printer::distortion.disable(false);

#endif

As you see distortion correction is disabled first before anything is done. Printer::distortion.disable(false); is same as M323 S0 does. Can you update to 1.0.4dev to be sure fixed bugs are not a reason. I also see in code that you should see in log a message that distortion was disabled when you home. Do you see that?

Are you using fast core xy or regular version? Unfortunately I have no core xy for testing my self.

ziegelstein

Yes sir, with 1.0.4dev the homing with previous enabled distortion correction works.

also the log message disableing/enabling distortion comes up.

Further more the "communication timeout and Error :Wrong checksum" seems to be reduced as well. For this moment.

But:

with distortion enabled, my leveld z-to 0 doesn`t work.

What i did in display first:

adjust z with distortion disabled to 0. Printing in a "good" bed area works well.

But with enabling distortion same g code ends in jammed nozzel and extruder looses steps due to wrong hights - not only the first layer but second and more.

For the first layer i always need to adjust with distortion enabled the high again with babystepps about _1mm..

In past when i worked with 1.03 and enabled distortion correction there was always noise from my 3 z-motors when moving the nozzel near Z at 0.

It seems to me, that there is no physicaly correction. Only something in calculation for next layer.

Repetier

Ok, first good to hear that the problem is already fixed in 1.0.4dev. So I can make it stable soon.

You should run G33 always after G32 S2 so both use same z position as reference. If you check values with G33 L0 they should swing around 0. Also I assume zmin homing with z probe is used here? If you are too close you need to descrease z probe height so after homing you have more space to bed.
G33 only works on a limited Z range defined in configuration. At higher Z you will see no z correction.
For testing I always put some higher card box at one measurement point. When I the move with low Z over that point (with removed card) I can clearly see it move up/down at that point. Regular correction is hard to see as it is so small.
For non fast core xy the correction is computed at 10mm distances of each move.

Rossini

Hmm,
tried today https://www.repetier.com/firmware/dev
with my corexy+z radds/due with disabled z-correction (distortion correction)
Alway check endstop true
Fast_corexyz 1

and now homing the x-axis does not work. Y/Z are fine.
X homing is crashing for half a minute and then it stops.

Gone back to firmware from last year with same config ... everything is fine.

Repetier

With fast corexy you have to be careful to reduce segments per second to fit the homing move in one list of subsegments. This depends on homing speed and 2 * x length. So you need 2 * x_length/homing_speed_in_mmps seconds. If you have 10 subsegments per move that must fit into it. So with 10 updates per second homing would need to be done in one second.
On the other side subsegments per second must be high enough that at maximum speed a segment only contains at max. 32000 steps.
Any violation could cause a stopped move to continue. Also I would expect it to get stopped again by the end stop trigger, but I have no core xy printer to prove that.

A good test would be to disable fast corexy first to see if everything is ok with pins etc. Then you know the problem comes from nonlinear handling.

Fortunately in V2 firmware these problems are gone due to different motion handling.