Reference switch not at limit possible?

[DaBit]

OK, new guy here. Let's do a short introduction first.

I built my CNC mill and CNC lathe a couple of years ago, both running LinuxCNC. LinuxCNC turned out to be an exptremely capable swiss army knife and I have also used it to control a coiple of machines that had no relation to CNC at all. The old name Enhanced Machine Controller/EMC suits the package much more.

I never had much interest in 'those pesky plastic poopers only capaply of producing endless Marvin the Martian copies'. But somewhere in 2017 I found myself with some aluminium profile I got for free and it was eating up space so I was considering using it or throwing/giving it away. Then I got a Geetech extruder, which ended on the already crowded shelf too. Then I got interested in 'run LinuxCNC on a Pi' exercise. 1+1+1=3: I decided to build a 3D printer as an exercise, running LinuxCNC on a Pi with L6470 SPI stepper drives as the controller, not expecting to use it for 'real things'. I just needed a goal to be able to complete a project.

I was wrong. It turned out to be a very useful tool. I kept using it until the belts were really at their last few strands and the idlers were crispier than a bag of popato chips. This was a few weeks ago.

Time to do a rebuild. Since I want to compare LinuxCNC with the regular 3D-printer electronics I decided I wanted to try one of the higher end controllers, and chose the Duet 2 Wifi. I also bought a BMG-X2, E3D Chimera, Gates 12mm belts and idlers, BLTouch, etc.
All that ended on the shelf too, taking apart all the blood, sweat and tears is painful and I needed to print this and that. 'I will do that next week'. Until even printing simple ornaments for my son's birthday presents went wrong. That evening I disassembled the thing and started the upgrade process.

Thus, at this moment I am left with an empty frame and a rebuilt CoreXY stage that is close to completion. Baby's first steps:

https://www.youtube.com/watch?v=P0TNgffWlrU

And of course there are things different from the 'CNC-controls' I am more used to. Two that come up are:

• 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.
  I re-used the reference switches from the existing design. These are NPN inductive proximity switches, and the X-axis switch is located at machine-coordinate X=18. With a diode in series for safety these work fine when hooked up to the Duet's endstop switch inputs.
  But there seems to be no way to tell the controller that the switch is located at X=18?

Currenly I solved it with a G92, like this:

; homex.g
; called to home the X axis

M98 Phomey.g			; BvH: Always home Y first to bring the carriage near the X home switch
M98 Plowmotorcurrents.g		; BvH: switch to low motor currents. Prevents mechanical damage when a limit switch fails
G91               		; relative positioning
G1 Z5 F6000 H2    		; lift Z relative to current position
G1 H1 X-265 F5000 		; move quickly to X axis endstop and stop there (first pass)
G1 X19 F6000       		; go back a few mm
G1 H1 X-20 F360  		; move slowly to X axis endstop once more (second pass)
G92 X18				; BvH: homeswitch triggers 19mm from hard mechanical stop. Leave 1mm safety clearance
G1 X1				; Move slightly away from homeswitch
G1 Z-5 F6000 H2   		; lower Z again
G90               		; absolute positioning
M98 Phighmotorcurrents.g	; BvH: back to regular/high motor currents again

(note, this is all under construction).

The G92 is dirty. There should be a better way, right?
I searched, but did not find. G1 documentation explicitely mentions M208 coordinates.

• I need to move the Y to the maximum machine coordinate to be able to home X. Which is why there is an M98 Phomey.g in the homex.g script.
  I would love to have some conditional logic like:

if (ishomed(Y)) then
G53 G0 Y[#maxlimit]
else
HomeY()
endif
HomeX()

Is that possible?

[T3P3Tony]

@DaBit check out the M208 gcode. That lets the printer know the position of your endstops

[DaBit]

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?

[fcwilt]

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

[DaBit]

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.

[deckingman]

@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.

[DaBit]

@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.

[deckingman]

@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.

[DaBit]

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.

[Danal]

@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.

[nhof]

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.

[deckingman]

@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.

[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