Reference switch not at limit possible?
-
From the M208 documentation:
[quote]
The values specified set the software limits for axis travel in the specified direction. The axis limits you set are also the positions assumed when an endstop is triggered.
[/quote]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?
-
Hi,
I use G92 with a slotted optical beam break detector.
Seems an OK approach to me.
If you use M208 to set the axis minimum you would still have to set it once for 18 and again for 0, assuming the minimum is 0 on your machine.
The values for min/max and in this case "ref" have to be entered into the configuration somewhere.
Frederick
-
Yes, I suppose I could use M208 to stretch the limits once the switch is hit. But I will keep the G92. Seems to work fine.
Still, I think that a homing sequence along the lines of LinuxCNC/Mach3/EdingCNC/whatever might benefit 3D printers also. But that might be just me being new to all this.
-
@DaBit You can use limit switches in addition to homing switches. That's what I do with axes maxima.
In my case, it's just there as a "belt and braces" measure for when I do something stupid. The way to do it is to connect the switch or switches to unused end stops and use M581 to take action when the switch triggers. Those actions can be to initiate an emergency stop or pause the print but if you don't like either of those option, you can call a macro and use that to take whatever action you want. https://duet3d.dozuki.com/Wiki/Gcode#Section_M581_Configure_external_trigger
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.
-
@deckingman: Are you that guy toying around with 3 stacked CoreXY stages and a diamond hotend? Just read through your blog posts, quite a bit of solid gold in them. Thanks!
I might indeed want a Zmax endstop. On the X and Y there are mechanical hard stops that prevent the carriages from running over the end of the rails. At Zmax not yet.
Hard to figure out if hard mechanical stops will suffice for the occasional 'oops' BTW. The motors can produce 150-200N of pulling force to the 12mm 2GT belts before skipping steps. I am not afraid of the structure; that handles 200N plus impact spike without the slightest bit of sweat. The (Gates 2GT 12mm, bought at E3D) belts, well, hard to find information about maximum operating and breaking tension.
-
@DaBit I am the original and AFAIK the only "deckingman" so yes, that me.
I wasn't actually proposing that you use Z max end stops, merely using that as an example of how you could have limit switches that separate to reference/homing switches. Maybe I misread your OP but I thought that was what you were looking to do.
-
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.
