Reference switch not at limit possible?
-
No, the current issue is/was 'single switch per axis, but not located at exactly min or max'.
Using G92 to stretch the machine limits a bit beyond the switch trigger point seems to work fine, redefining axis limits after succesfull homing using M208 is another workaround.
I do not consider either of them a clean solution, especially not since the for the Z axis it is possible to set the trigger point of the switch/probe. But oh well, it works.
-
@DaBit said in Reference switch not at limit possible?:
CNC-controls differentiate between limit switches and reference/home switches. Limit/endstop switches are there to prevent damage only. Reference switches are usually not at the end so you can home with maximum speed, fly past the switch, back a little, and do it slowly once more.
CNC homing (generally) needs to be pretty darn accurate. Offset between machine coordinates to a given work coordinate for a fixture, you want that to be repeatable to within .01mm or even better.
3d printers? Homing accuracy repeatability is not very important for X and Y. More important on Z (and certain Deltas). Back to XY homing: If it varies by .1mm each time, who cares? The print will start on the table in a slightly different location. So what? The entire print will be 'relative' to that start point.
Z is different, which is why many printers use a different probe (maybe in addition to a homing switch) to get it much more precisely set relative to the bed.
Delta? maybe important to be very repeatable on all 3 towers, because this ultimately sets Z... or, if the printer is set to "calibrate" (not mesh) the bed at the start of every print, then the top-of-tower homing switches need not be all that precise.
This is a long topic, and the above just scratches the surface... but if we summarize: Homing on 3D printers is VERY different from homing on a CNC. 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.
-
I agree that more granularity when homing would be very useful.
Even a 3D printer with a heavy XY stage will suffer a bit when homing at anything but very low speeds, as my understanding is the firmware abruptly stops motion (without de-acceleration) when the home switch is triggered.
This is okay for very lightweight 3d printer stages, but less than optimal for heavier stages including CNC machines, as it means homing feedrates have to be fairly low to avoid shaking the machine excessively.
An expansion of M574 or M208 (or a new code) could add a provision for some amount of allowed overtravel past the switch for deacceleration and/or a non-0 home switch position. This would allow much more rapid home feedrates with space to ramp down the move after triggering.
I personally think the G92 setting in the home.g is an acceptable solution, but I would like to see a home move deacceleration phase at least. Adding native (non-trigger-based) support for both 'limit' and 'homing' switches on the same axis would be an added bonus.
-
@nhof I home my 5Kg of moving mass by doing a fast first pass, backing off a few mm, then do a slow second pass. That makes it both fast and precise. The other thing I do is start heating the bed, then when it gets to about 40 deg C, commence the homing sequence so it's always completed during the time it takes for the bed to reach print temparture.
-
@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?
-
@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
-
@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)
-
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.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
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.
-
This post is deleted! -
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! -
@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
-
@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.
-
@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.
-
@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.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@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.
-
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
-
@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.
