Welcome! Log In Create A New Profile

Advanced

X or Y movement after homing, towers exceeding endstops

Posted by maddog7 
X or Y movement after homing, towers exceeding endstops
February 16, 2015 04:02PM
Hi all,
I've built a Rostock after having only previous experience of building cartesians. I've begun the calibration stage and I'm finding that if I home the printer (which works fine) then jog the x or y axis, this allows the individual towers to exceed their limit switches. Just wondering if there is something I'm missing?

I'm using Ramps 1.4 and Rich Cats Marlin.

Any ideas?
Cheers
D
smiling smiley
Re: X or Y movement after homing, towers exceeding endstops
February 16, 2015 06:24PM
On a delta, you should always lower the head sufficiently after homing before moving the head in the X or Y direction. In RepRapFirmware for Duet electronics, the head is lowered a little automatically at the end of the homing sequence; but I don't think other firmwares do that.



Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: X or Y movement after homing, towers exceeding endstops
February 16, 2015 09:01PM
Zmax height on deltas can be misleading. Other than 0, you can't have any other X or Y value when it is on Z max. Trying to jog it in X or Y will raise one or two of the carriages past the endstops. And I don't think the Rich Cattell's firmware has a safety feature to prevent the carriage going past the endstops.

On other going-past-endstop issue, I'm having random homing problems. It often happens when the effector is far off the center of the bed. For example, after retracting the Z probe, homing from that position would make one of the carriages go past the endstops and the motor would screetch. I have to do an emergency stop when this happens. I'm using braddo99's Marlin which is a variant of Rich's.

Edited 5 time(s). Last edit at 02/17/2015 02:04AM by boksbox.
Re: X or Y movement after homing, towers exceeding endstops
February 17, 2015 04:48AM
Quote
dc42
On a delta, you should always lower the head sufficiently after homing before moving the head in the X or Y direction. In RepRapFirmware for Duet electronics, the head is lowered a little automatically at the end of the homing sequence; but I don't think other firmwares do that.

Repetier's ENDSTOP_Z_BACK_ON_HOME can probably be used this way. It's intention is different but I guess it would work as way to move away from endstops too.
Re: X or Y movement after homing, towers exceeding endstops
February 17, 2015 04:53AM
Quote
boksbox
Zmax height on deltas can be misleading. Other than 0, you can't have any other X or Y value when it is on Z max. Trying to jog it in X or Y will raise one or two of the carriages past the endstops. And I don't think the Rich Cattell's firmware has a safety feature to prevent the carriage going past the endstops.

Rich's firmware is Marlin derived so it probably has ENDSTOPS_ONLY_FOR_HOMING define. Do not define it (comment the line out). Then firmware will not try to move a carriage past an endstop. It will still probably screw up relationship between cartesian and delta ... leading to wrong movements later but at least it will not try to ram past endstops.
Re: X or Y movement after homing, towers exceeding endstops
February 17, 2015 06:32AM
Quote
hercek

Rich's firmware is Marlin derived so it probably has ENDSTOPS_ONLY_FOR_HOMING define. Do not define it (comment the line out). Then firmware will not try to move a carriage past an endstop. It will still probably screw up relationship between cartesian and delta ... leading to wrong movements later but at least it will not try to ram past endstops.

I tried this and it really messed up. After homing, all the carriages repeatedly kept pushing through the endstops. sad smiley

Edited 1 time(s). Last edit at 02/17/2015 06:35AM by boksbox.
Re: X or Y movement after homing, towers exceeding endstops
February 17, 2015 09:21AM
I did look at the ENDSTOPS_ONLY_FOR_HOMING define and thought about rem'ing it out but was not sure if something else was the cause of the issue first. I mistakenly thought that the endstops would be absolute and stop the machine if triggered for any reason.
I suppose as long as I know not to move x or y until all 3 towers are low enough then it's all ok.

I've been a little confused by the endstop stuff in Marlin.......(easy done, I'm no programmer)
After crashing through the stops again, I got sick and made some spacers that prevent the towers moving far enough to damage the sensors but allow them close enough to trigger them.

Thanks to everyone for your replies.

Cheers
D
smiling smiley

Edited 1 time(s). Last edit at 02/17/2015 09:22AM by maddog7.
Re: X or Y movement after homing, towers exceeding endstops
February 17, 2015 01:06PM
Quote
boksbox
I tried this and it really messed up. After homing, all the carriages repeatedly kept pushing through the endstops. sad smiley

That is probably because of delta segmentation. One move is segmented to a lot of small moves. Each small move tries to to move through endstop and should immediately find out it cannot move and should stop trying. Anyway, there may be a bug in firmware because even the first micro-step through endstop should not happen. In other words: my guess is that the code checks endstop status after it does the first microstep of a delta segment and not before it. One other option is that it backs a bit from endstop after it is hit ... but I think only Repetier can do this.

It still should ram into endstop less than when ENDSTOPS_ONLY_FOR_HOMING is defined.

This never bothered me. I just do not move sideways after homing.
Sorry, only registered users may post in this forum.

Click here to login