FR: Option for Auto-squaring with two end stops

[einencool]

Hello @terjeio , As I now finished my machine which has two motors for the Y-Axis, I start thinking about the possibility of squaring the gantry while Homing.

Do you think this would in the future possible with your GRBLHal version? That would be a great step to optimize the machine.

Now I'm just homing with one end stop and the motors are connected together to the Y Port. But maybe someday it would be possible to connect the other motor to the A or B Connection.

But for now it's just a thought 👍

With best regards Chris

[terjeio]

The core has support for dual motors and auto squaring (AFAIK yet untested), the SAM3X8E driver and cmcgrath map file has code/definitions that may be used as a starting point.

[einencool]

That sounds not so bad :-) The Problem is, that I only understand a little bit of coding, to change some Pins or something like that, that's not the Problem, but such a coding is way to hard for me, maybe in the next few month you got a little time for something unnessesary like this :-)

[terjeio]

I need some time for my own projects one of which is to move the motor drivers off a Ramps board used for my 3D printer to a separate PCB. This has two Z-axis motors that I want to auto-square, and I will make the PCB in such a way that I can use the printer as a test bed for grblHAL as well.

So I am getting there, albeit a bit slowly...

[einencool]

Like I said, thats no Problem for me. The machine is working and it's only a little extra gift for the future :-) And when you are testing your Board with auto squaring, then you know what you are doing. I have absolutely NO IDEA from coding :-)

So thank you for your great project and support 👍

[norru]

@terjeio I would like to enable autosquaring on my machine too (twin Y motors with separate switches) - I can help with testing once you're happy with your implementation.

[terjeio]

I do not yet have a machine to test in so I cannot say if I am happy with the implementation or not. Simulation seemed to be okay though.

On my todo list is making a driver board for my 3D printer with support for dual Z drivers, I can test myself when that is ready. Before that you can do the testing if you are willing to do that.

[norru]

I'm not in any rush - take your time, thanks for all your great work!

[phil-barrett]

This is also on my list to do. But before that, I have an ignorant question - how do I configure grblHAL so that 2 drivers are slaved together for a single axis?

[norru]

@phil-barrett I couldn't find an easy way to do it without tinkering with the autosquaring experimentall code, so I ended up doing it in hardware.

[terjeio]

@phil-barrett, @norru It is a matter of assigning a pins (add #defines for that) and output the required signals in set_step_outputs() and set_dir_outputs() functions.

E.g for slaving another X motor just add

DIGITAL_OUT(stepX2, step_outbits.x);

to set_step_outputs() and do it in the same way for setting the direction.

The pins needs to be configured as outputs, this is done in driver_setup(), e.g:

pinModeOutput(&stepX2, X2_STEP_PIN);

If a separate enable signal is required that has to be added too. IMO the enable signal should not be used to disable a motor when auto squaring, I use a mask for "routing" the step signals in the SAM3X8E driver.

The SAM3X8E (Due) driver already has #defines for slaving motors, the #define names should preferably follow the same naming scheme?

Example for set_step_outputs():

https://github.com/terjeio/grblHAL/blob/b6e74c1011e4b716d58668ec55eec9eae6b0d7e5/drivers/SAM3X8E/main/driver.c#L245-L273

It can fast get a bit messy with all the #defines needed if flexibility is required, but it is doable. And it surely adds to the testing required, the main reason I have not added this for all drivers.

[phil-barrett]

Thanks. I think this is a fairly common configuration for a lot of low to mid range CNC routers. The Avid Pro series is a prime example - 2 steppers for the Y Axis.

It is my belief that grblHAL can make significant penetration into that market segment. And there are a lot of Chinese machines that ship with terrible electronics so there is a ready upgrade segment as well.

By the way, I will probably add HW configuration for slaving A to X or Y using solder jumpers on the bottom of the board. Lots of space there and it is truly a zero cost feature.

[einencool]

Reopened like mentioned in #82

[terjeio]

This is the relvant comment for what should be tested.

Code changes are required - there is at least one edge case when one limit switch is asserted when homing starts. The opposite side motor is moved until the its related limit switch is asserted or the soft limit is reached. IMO homing for auto-squared axes should not be allowed if one of the limit switches is asserted, or at least be limited to one try. However, limiting homing to one try is impossible ensure over a reboot without storing the attempt in non-volatile memory.

[einencool]

Hi @terjeio I think that when the Option „two Limit switches on one axis“ is enabled, it means, that the Limit switch has to be moved free, before the Homing routine will start, else it will throw an error.

But, you‘re absolutely right, when booting or something else, the mentioned axis has to be off of both limit switches.

[terjeio]

I think that when the Option „two Limit switches on one axis“ is enabled, it means, that the Limit switch has to be moved free, before the Homing routine will start, else it will throw an error.

No, this is for when there is a limit switch at either end of the axis. If one is asserted it is impossible to know in which direction to home. In fact using the limit switches for homing is logically not correct, there should really be separate homing switches (or the limit switch at the homing end only doubling up as a homing switch). I guess this is due to the hobby origins of grbl and limited capabilities of the 8-bit Arduinos. I have been thinking of adding an option for homing switches inputs to grblHAL for a long time, at least the core should be able to handle that. They could be "wired" in driver code to the limit switches if physical switches or input pins are not available.

Anyway, I have decided to try a move off the limit switches for auto squared axes if one is asserted (by the pull-of distance * 5). If still asserted homing will fail. This should ensure that the two motors are not getting too far out of sync. I am testing this now.

[einencool]

Yes, you‘re right, that the limit switches shouldn‘t be used as the reference switches...

But I think on a hobby machine it‘s ok.

In my case, I have two limit switches on each axis and use one of them for homing. Now with the Autosquaring Option for the Y-Axis, I‘ll use two for each End (Y- and Y+) and on the other one for the A or B Motor I‘ll only use one Limit switch for homing/squaring

Both Switches for Squaring are these „TriPod“ Endstops, which should be very precise and repeatable.

[phil-barrett]

Anyway, I have decided to try a move off the limit switches for auto squared axes if one is asserted (by the pull-of distance * 5). If still asserted homing will fail. This should ensure that the two motors are not getting too far out of sync. I am testing this now.

This makes a lot of sense to me. What is the error message/code that the user sees? Is is it suitably specific to the problem?

I understand the logical distinction between limit and home switches. Is there ever a case that they would exist at different locations? (not arguing, I really want to understand)

[phil-barrett]

TriPod“ Endstops

do you have a link? Google gives me physical stops for photo gear.

[einencool]

Hi Phil,

It‘s like the 3D-Finder, which I‘m using for measuring my parts on the cnc, but these are a little bit cheaper, but they are really good. They were made by a friend of me.

This link is only to show how it‘s working :-) https://www.thingiverse.com/thing:31927

[terjeio]

This makes a lot of sense to me. What is the error message/code that the user sees? Is is it suitably specific to the problem?

It is the Hard Limit alarm (1) that gets triggered. I believe that is suitable.

I understand the logical distinction between limit and home switches. Is there ever a case that they would exist at different locations? (not arguing, I really want to understand)

Is there ever a case when they could not? Photointerrupters could be used for homing, or a mechanical switch not triggered "head on". The work area of a machine could be different from the reachable area? And it could be useful to go outside of the work area without triggering limit switches. An example from the Mach3 documentation:

It is sometimes not convenient to have the Home switch at a limit of travel. Consider a large moving column floor mill or a big planer-mill. The Z travel on the column might be 8 feet and could be quite slow without affecting the overall cutting performance of the machine. If, however, the Home position is the top of the column, then referencing might involve nearly 16 feet of slow Z travel. If the reference position was chosen half way up the column, then this time can be halved. Such a machine would have a separate Home switch for the Z axis (thus requiring another input on the parallel port, but still only four inputs in a three axis machine) and would use the ability of Mach3 to set any value for an axis DRO, after referencing, to make machine-Z zero to be the top of the column.

For grblHAL it would be easy to separate the switches in the core, add a new entry point in the HAL for reading the switch statuses - if not set by the driver just copy the limit switch function pointer to it...

[einencool]

But when the Homing switch is, let‘s say in the middle of the travel way, how does the machine know, in which direction it has to move? Has it to move into the + or - direction?

[terjeio]

But when the Homing switch is, let‘s say in the middle of the travel way, how does the machine know, in which direction it has to move?

You have told the controller about which way to travel in settings. $23 - Homing direction invert.

[phil-barrett]

Maybe I asked the question poorly. Why would I need to have home be in a different location from one of the limits? Is there a benefit?

[terjeio]

Maybe I asked the question poorly. Why would I need to have home be in a different location from one of the limits? Is there a benefit?

A poor answer too? The Mach 3 documentation snippet I quoted is one reason? Not likely a grblHAL candidate though.

Separating the inputs logically and "wiring" them together could be useful though, especially for machines having two limit switches per axis wired to different inputs. There is no way for knowing which has been triggered in the current core. Having the homing input "wired" to one of them would avoid the "Two switches shares one input pin" problem for homing.

[einencool]

especially for machines having two limit switches per axis wired to different inputs. There is no way for knowing which has been triggered in the current core. Having the homing input "wired" to one of them would avoid the "Two switches shares one input pin" problem for homing.

In theory that's right, but then I think you need 3 switches in this mentioned case. Because then one homing switch is also a limit switch and not independent from each other.

Having two connectors for each end of the axis would be great, because it would make the wiring much more easy, but they are limit switches.

[terjeio]

In theory that's right, but then I think you need 3 switches in this mentioned case. Because then one homing switch is also a limit switch and not independent from each other.

The limit switch on one end can double up as a home switch so for a non auto-squared axis two inputs is the minimum. For an auto-squared one three is needed as a minimum, four if the homing and limit switches are all separate.

BTW I have added a HAL entry point for getting homing switches status and "wired" it to the limit switches. Tests with my simulator looks good, I'll likely commit an update later today.

[terjeio]

Changes for this is now committed to the test branch. Be careful when testing!

[dresco]

Hi, I'm currently setting up an OpenBuilds LEAD clone with dual motors on the Y axis, so following this with interest (have just tied the inputs to the two stepper drivers together for starters)..

Just wondering, do you have any thoughts on supporting a 'pull-off offset' for the 2nd axis? Not sure if that is the best term to describe it, but basically a way to apply a minor correction to the pull off distance, in order to really square things up if the two switches aren't perfectly aligned?

[terjeio]

Just wondering, do you have any thoughts on supporting a 'pull-off offset' for the 2nd axis?

I believe that would be useful, even neccesary? I want to move the DUAL_AXIS_HOMINGFAIL* defines to $-settings, I could add offset settings too when I do that.

[terjeio]

Test branch now updated with $-settings for DUAL_AXIS_HOMINGFAIL* parameters and offset setting(s) for switch offset compensation.

[dresco]

Thanks Terje! I will aim to build and perform some initial tests this week..

Incidentally, I've just been setting up platformio to build and upload for Phil's Teensy 4.1 breakout board. Would you be interested in a wiki page describing the steps? If so, I'll try and pull one together..

[terjeio]

@dresco : A wiki page would be great!

[dresco]

Hi @terjeio

Initial testing has been promising. Have built the 20201115 test branch, configured with ganged Y axis and auto-squaring, and tweaked the $171 setting for alignment. All working as expected.

Am not sure whether it's possible to submit pull requests for wiki edits? I've put my platformio build notes in a markdown file, if I can get that to you somehow.. (could just open a new issue and attach if there's not a better way?)

[terjeio]

@dresco Thanks for feedback, good to hear it works for you.

Am not sure whether it's possible to submit pull requests for wiki edits?

I'll give you write access to the Wiki - however the github security page failed to open now, will try later.

[einencool]

That sounds great, thank you both for making this trials :-)

I have to do some bigger work on my machine so that I‘ll have to recalibrate all axis, but with this step I‘ll also add the two needed Endstops for the Auto-Squaring Option an then I can make some Test only with the sides from the gantry, so the Portal Axis is not mounted and when there will be an issue, that doesn‘t matter, because they can move freely.

But for this I have to make some parts with the mill now and I think it may take some weeks till it will be done.

@dresco A wiki for this would be very helpfully for users like me :-)

[dresco]

@terjeio @einencool Have just created a wiki page for the PlatformIO configuration. Took me quite a while to work out the little quirks, so will hopefully be helpful to others.. ;)

[frdfsnlght]

So I'm not 100% sure what the status of autosquaring is after reading these comments. Can anyone clear that up?

I'm getting ready to build a MPCNC and I'm considering using Phil's Teensy board. I'm trying to understand how to achieve autosquaring. It seems the discussion above is leading to "a lot" of limit inputs and I don't think Phil's Teensy board has that many available.

Here's my understanding of how autosquaring is done with a "traditional" MPCNC and a limited number of limit inputs. Maybe there's something useful in here. Traditionally, the hardware is configured for autosquaring like this:

• Both X and Y axis have 2 independent steppers each (4 total)
• Both X and Y axis have a pair of limit switches on the "min" side of the rails. Assuming NC switches, each pair for an axis is wired in series (if NO switches, wire them in parallel) and connected to the "min" limit switch on the controller. So a single limit input is used for each axis. The position of the limit switches must be accurate as they are used to zero the axis.

To square an axis, for example X, both X steppers are moved toward "min" until the limit input is triggered. Since there's a switch for each motor and they're both wired to a single input, the controller doesn't yet know which motor hit it's limit. It then backs off both motors until the limit switch untriggers (is that a word?). Then, while holding one motor in position, it moves the other in the "min" direction until the limit input triggers. Then it backs off and repeats for the second motor. It then knows how many steps away from the switches each motor is. The controller uses the difference to move one of the motors so that the axis is now square and considers this the machine zero. Repeat for the Y axis.

Once squared, the limit switches are not used during the operation of the machine. The controller will refuse to move to a negative coordinate on either of the squared axis. Though, I don't think there's any reason the controller couldn't use the switches as a "min" limit while running, but I believe none of the firmwares for the various boards in use do.

In my build, I don't think I'd need limit switches on the "max" side of the axis, but it would be nice to know I could if I wanted. Those limit switches could also be wired together and use a single input for each axis (but separate from the "min" inputs).

Does any of that make sense? It seems like a nice way to make use of the a limited number of inputs.

[einencool]

In my understanding of this feature it is that two motors from one axis are connected to two independent Ports and Limit switches. I don‘t know if anybody has tested it with two ganged axis, but lets say you have 2 Motors for X and two for Y then you should configure and wire them maybe as followed (it‘s only an example, and I don‘t know if it works...)

• X1 Motor connected to X and the Limit switches for X-Min and X-Max to Limit input (like you said every Switch is Normally Closed)

• X2 Motor connected to A and the Limit switch to A-Min (only Min Switch on this side)

• Y1 Motor to Y

• and Y2 Motor to B-Axis

That‘s the way I think it should work, so that every Motor has it‘s own „Reference Limit Switch“ Hope that it is correct, because that would only be my understanding...

[frdfsnlght]

It can certainly work that way, but then each axis requires 3 limit inputs. A controller can quickly run out of inputs. For instance, Phil's Teensy board only has 5 limit inputs.

That's not the way it works for typical MPCNC installs.

• X1 motor connected to X, X2 motor connected to A
• X1 min limit switch (NC) wired in series with X2 min limit switch (NC), connected to X min limit input
• If you have/want X max limit detection, put in on the X1 motor side (or X2) and wire to X max limit input

Similar for Y. With the method I described above, there's no need for multiple min limit inputs on a single axis. So only 2 inputs per axis.

And just to really fry your brain, you could wire the max limit switches in series (assuming NC) with the mins and only use a single limit input per axis. If the limit input triggers, you know which limit you've reached based on the direction you were travelling. The only trick with this is that you must disable limit inputs for a short distance when the machine tries to move off the triggered limit switch. Basically, after hitting a limit, move in the opposite direction until you're no longer "at the limit", then you're back in "machine space".

[phil-barrett]

I believe that 3 limit per axis thing is not a requirement. In fact, one limit input per axis works just fine - exactly as you mention in your last paragraph. Homing switch pull-off distance is specified in $27.

[frdfsnlght]

That's good to know. Since autosquaring requires limit switches in some arrangement, the conversation about autosquaring always seems to devolve into limit switch details. It would be nice to support multiple arrangements and be able to autosquare no matter what arrangement you have, as long as the switch arrangement meets some set of minimum requirements. It may take different algorithms to autosquare depending on the switch arrangement.

So, back to one of original questions: what's the current state of autosquaring support and what switch arrangement(s) does it require? And are there plans for adding more support for other arrangements?

[terjeio]

To square an axis, for example X, both X steppers are moved toward "min" until the limit input is triggered. Since there's a switch for each motor and they're both wired to a single input, the controller doesn't yet know which motor hit it's limit. It then backs off both motors until the limit switch untriggers (is that a word?). Then, while holding one motor in position, it moves the other in the "min" direction until the limit input triggers. Then it backs off and repeats for the second motor. It then knows how many steps away from the switches each motor is. The controller uses the difference to move one of the motors so that the axis is now square and considers this the machine zero. Repeat for the Y axis.

For grblHAL this is not entirely correct. Both limit switches are logically "or"ed together when both motors are enabled. When one is triggered which one of the two is detected by "disabling" the motors in turn. "Disabling" a motor will remove the corresponding limit switch from the logical "or" and thus which side is triggered can be found. The other motor is then moved until the corresponding switch is triggered. After that both motors are enabled and backed off in tandem and a new sequence with the locate feed rate is performed. If configured the secondary motor is finally moved the configured distance to compensate for any switch misalignment.

So, back to one of original questions: what's the current state of autosquaring support and what switch arrangement(s) does it require?

Two limit switch inputs per auto-squared axis at the min end (home target) is the minimum required for auto-squaring. If a max (NC) limit switch is connected in series with a min (or home target) switch then homing cannot be safely performed as there is no way to tell which one is triggered (if one is), and therefore the pull-off direction cannot be determined. However, there is a setting flag, $22 - "Two switches shares one input pin" that can be used to ensure safe operation, this should be enabled if max and min is connected. If either one is triggered when homing is called for it will then result in a hard limit alarm. It is possible that "Two switches shares one input pin" should be a per axis setting - to be considered.

The only trick with this is that you must disable limit inputs for a short distance when the machine tries to move off the triggered limit switch. Basically, after hitting a limit, move in the opposite direction until you're no longer "at the limit", then you're back in "machine space".

At least one driver has an override limit switches input - when this is asserted limit switches signals are ignored until it is deasserted. On my Mach3 based router I have a push button for this purpose - I push that while manually pulling off the triggered switch.

And are there plans for adding more support for other arrangements?

I belive, as explained above, that both auto squaring and hard limits can be safely enabled with three limit switches connected to two inputs. There are currently no plans for other arrangements. However, one change could be implemented for those drivers/cards that already has separate min and max inputs - disabling the logical "or"ing of the max with min inputs when homing is possible for those (unless the max input is used as the min input for the secondary motor).

[frdfsnlght]

I think I understand. So "MPCNC" style autosquaring (as I described it) is not supported and there are no plans to support it.

So, if I were to use the Teensy 4.x board for my MPCNC with the currently released version of grblHAL, I could:

• Wire X1 motor to X, X2 motor to A
• Wire Y1 motor to Y, Y2 motor to B
• Wire X1 min switch to limit input X, X2 min switch to limit input A
• Wire Y1 min switch to limit input Y, Y2 min switch to limit input B

That gets me autosquaring assuming grblHAL is configured correctly.

And if I want X/Y max limit switches:

• Wire X1 max switch in series (assuming NC) with the X1 min switch
• Wire Y1 max switch in series (assuming NC) with the Y1 min switch
• Turn on setting $22 to allow 2 switches wired per limit input
• Make sure the gantry is off the limit switches before calling a homing cycle

Does that sound right?

But I'm wondering about this:

... If a max (NC) limit switch is connected in series with a min (or home target) switch then homing cannot be safely performed as there is no way to tell which one is triggered (if one is), and therefore the pull-off direction cannot be determined.

Is there a reason you can't take into account the direction you were last moving when the limit input triggered? If you were moving towards X min and the limit was triggered isn't it safe to assume you're at the min limit? And vice-versa for X max? Couldn't that be saved as the "state of the limit switches"? Don't know if I can make this clear, but the limit switches can be virtualized so there's always a virtual min and max limit input state for each axis, no matter what the hardware actually has. When a real input is triggered, using whatever logic necessary, set the state of the virtual limit input. Perhaps this is decided by the driver and how it's configured during build. (I'm not familiar with the architecture yet so I don't know if that's possible or if I'm using the right terms).

At least one driver has an override limit switches input - when this is asserted limit switches signals are ignored until it is deasserted. On my Mach3 based router I have a push button for this purpose - I push that while manually pulling off the triggered switch.

Perhaps that could be added to the Teensy driver some day. Seems like a handy option to have.

I really appreciate the time you've taken to respond. I'm trying to wrap my head around the available options as I work out the details of my design. I'm a hardware/software person myself, so if I get far enough into this, I might be able to actually contribute something, someday, rather than harass you with questions.

[terjeio]

@frdfsnlght

Does that sound right?

It does.

Perhaps the safety door input could serve as an override limit switches input? The safety door option is disabled by default and I believe most users do not need or use that.

[einencool]

@terjeio But then please make it configurable, because I use the safety door as a „pause Option“ with spindle stop :-)

[terjeio]

But then please make it configurable, because I use the safety door as a „pause Option“ with spindle stop :-)

Sure will, if the safety door option is enabled it will have priority. Repurposing the door pin would be a workaround until boards/drivers can get a dedicated override pin. There are other inputs that could be added too - probe connected, block delete, optional stop... These would require board and driver support. The core is already (partly) ready to handle them.

[frdfsnlght]

I could live with all that. I'm not planning an enclosure, so as long as the driver/grblHAL supports reassigning the door input to "override limit switches", I'm happy.

As an aside, I'm scrapping my plans for an MPCNC. I'm now thinking an OpenBuilds LEAD design (aluminum extrusion), but with the Teensy board running grblHAL.

You can close this "issue" if you'd like. I think my questions have been answered. Thanks for all the help.

[einencool]

Hi @terjeio At first i wish you all a merry Christmas 🎄:-) In these days I’m going to update my machine with the auto squaring feature. I configured the newest test branch from today with this feature, but in the moment I’m not finished with the electric. But i uploaded the source to the board and startet the gcode sender. Would it be possible to get the two end stop signals in two different show boxes? Now it dhows only Y-Axis endstop in „red“ , but it would be great to have Y1 or Y2 or something like that shown in the sender. I hope in the next days I’m able to try it.

[phil-barrett]

That, indeed, would be useful. I think the request might be a little better in the ioSender issues section.

And, a Merry Christmas to you all, too.

[terjeio]

A Merry Christmas to all!

Would it be possible to get the two end stop signals in two different show boxes?

It is possible but not without breaking sender compatibility.

I have been thinking about adding a $-command for telling the controller about sender capabilities. With that in place it will be possible to add this and other advanced features down the line.