Reference switch not at limit possible?

dc42

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

Thus, I can do an M208 X0:264 to setup the limits. Then I can use M574 to choose the endstop location, e.g. M574 X1
I don't see how I can set the location of the reference switches, except at minimum or maximum?
So, how do I set up, for example, an X axis ranging from machine coordinates (G53) X=0 to X=264 with a home/reference switch at X=18?

Does your homing switch remain triggered for all values of X between 0 and 18?

fcwilt

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

but I would like to see a home move deacceleration phase at least

Since the firmware must assume nothing about the starting position during home how would it determine when to decelerate?

I tested a system that worked well using two slotted beam-break detectors. One was at the actual "home" position, the "early warning" was 25 cm before that.

Homing worked by moving at high speed until the "early warning" detector was triggered, then switching to slow speed until the "home" detector was triggered.

Frederick

DaBit

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

That's why most controllers "Keep it Simple" with a limit/home at one end only, and nowhere near the repeatability of CNC style homing (and maybe something to more precisely set Z).

This all works, even on "high end" printers. Don't overthink it.

It is not about precision. Precision is a function of the repeatibility of the reference switch and the jitter in the software loop that processes the trigger.
And you don't need precision because you cannot use it. A few months ago I was toying with the idea of milling a scaffold instead of printing supports on the bed. Might be worth the effort if you need to print multiple copies of the same part, and then repeatability of the homing locations becomes more important.

It is about having the flexibility to locate the reference switches anywhere along the axis, having the ability to tune the squareness of dual-motor axes by simply altering a number, etcetera.
I can set the trigger height with a Z probe too (G31 Z parameter), why not with the other axes/motors?

Also, a switch at the mechanical end makes it necessary to go slowly since otherwise it is close to impossible to decelerate before the axis hits the mechanical limit. Locate it 20mm before the mechanical limit, and the first homing pass can be done at maximum velocity. Then back off and try again at a low speed. It's what I did when LinuxCNC controlled my printer; homing was a few-seconds process.
But on the other hand: heating up the bed and hotends and doing the actual printing takes so much time that homing speed is not that important.

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

Does your homing switch remain triggered for all values of X between 0 and 18?

Yes, it does. Otherwise the software would not know at which end of the switch it currently is.

(offtopic: my CNC-ed lathe is fairly slow in Z-movements, so I setup homing as half-of-travel inactive, half-of-travel active. The largest distance that must be traveled for homing is therefore half of the total stroke. And in reality it is much faster than a switch close at the end since the carriage is likely quite close to the half-travel location)

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.