Reference switch not at limit possible?

dc42

One way to achieve what you want is to set the M208 minimum to be 0 but immediately after the G1 H1 X move in homex.g (or the second such move if doing coarse then fine homing, insert G92 X18. Similarly for the final X homing move in homeall.g. A slight disadvantage of doing this is that it will set the X axis position and flag the axis as homed even if the G1 H1 X move was not stopped by the homing switch.

A Former User

could maybe avoid unwanted G92 by moving the G92 command to a trigger that is created/M581, checked/M582 and removed/M581 in the homing file? not sure how it'll deal with the range x=0->18,but it could make the G92 conditional while we eagerly await support for conditional g-code.

Danal

This post is deleted!

DaBit

The G92 after G1 H1 is what I am doing now, see start post.
Is it the G92 that flags the axis as homed when executed? In that case, would starting with an M208 X18:264 and execute an M208 X0:264 after the G1 H1 be a better solution?

Regarding the triggers: that would be a great workaround to handle the 'X is between 0 and 18 during startup' case. Check the level on the input, and if the homeswitch is already activated, execute G91 G0 X18.
Thanks for the tip!

fcwilt

@DaBit said in Reference switch not at limit possible?:

Is it the G92 that flags the axis as homed

Anything that tells the firmware the current position of an axis marks the axis as homed even if the position is bogus.

So a G92 X### will mark the X axis as homed.

And a G0 X### H1 will set the current position to the min/max value specified in M208 for that axis when the endstop for that axis is triggered and the axis will be marked as homed.

Those are the two situations I know of.

Frederick

dc42

@DaBit said in Reference switch not at limit possible?:

Is it the G92 that flags the axis as homed when executed? In that case, would starting with an M208 X18:264 and execute an M208 X0:264 after the G1 H1 be a better solution?

Yes and yes.

DocTrucker

@deckingman said in Reference switch not at limit possible?:

BTW, once the machine has been homed, the firmware will respect the axis limits that you define in M208. So if you try to move outside those limits once the machine has been homes, it won't do it.

Not always the case. Despite there being a gcode switch to put the printer in delta mode the limits on occasion are ignored, I believe for delta calibration. I think comands ran by g32 from bed.g are an example of this.

dc42

@DocTrucker said in Reference switch not at limit possible?:

@deckingman said in Reference switch not at limit possible?:

BTW, once the machine has been homed, the firmware will respect the axis limits that you define in M208. So if you try to move outside those limits once the machine has been homes, it won't do it.

Not always the case. Despite there being a gcode switch to put the printer in delta mode the limits on occasion are ignored, I believe for delta calibration. I think comands ran by g32 from bed.g are an example of this.

Correct, the coordinates you put in G30 commands in bed.g are allowed to be outside the printable area.

DocTrucker

@dc42 said in Reference switch not at limit possible?:

Correct, the coordinates you put in G30 commands in bed.g are allowed to be outside the printable area.

Is there already some way of handling printable area vs machine limits? Is it already on the wish list? Nozzle wipes and filament dumps for example may be beyond the area that gcode commands in a build should take you to, but accessible by macro or flagged G1.

fcwilt

Hi,

M564 can be used to allow moves beyond the min/max limits.

Perhaps two sets of min/max limits could be implemented.

One set for the print area and the other for the absolute limits.

Frederick

DocTrucker

@fcwilt with the M564 and the switch for delta mode I'm not sure why delta calibration needed to bend the rules. Perhaps M564 came after delta calibration.