auto Square issue

[pachucristo]

Hi everyone, I'm working with a blackbox X32 I usualy work with cartesian machines (XYYZ) and I needed the autosquare function. with default firmware(installed with OB CONTROL), when I do a home cycle, Y limitSw stops both motors without moving one at a time once detected at least one of 2 NC switches wired in series to the Y limit. I assumed that I needed to change the firmware, and I found the web "wizzard" to configure a bin file to flash firmware, I configured as usualy. flashed it, and started configuring again the motors and switches.

first I noted that the Probe Pin now act as a Y2 limit so I re wired every limit sw to a dedicated port in the blackbox. BUT... when I ask for a $HY homing cycle, the switches act as they were independent only if the Y2 Switch is Triggered first and Y1 second. and if I ask for a $HY again, and press Y1 Limit first and then press Y2, both motors keep running until I touch the Y2 limit. if the motors where attached to the machine, the autosquare would only work if Y2 motor is ahead of Y1, if they where the other way arround the machine would crash Y1motor until Y2 reach Y2 limit. the independent movement of Y1-2 motors is only effective if Y2 limit is triggered first.

i would appreciate any advise on this, thanks!

firmware blackboxX32.zip

[terjeio]

Homing works ok with my CNC machine simulator. Note that performing a successful homing cycle by manually triggering switches is hard for a single motor axis, for a dual motor axis close to impossible?

[pachucristo]

here is my setup, from left to right: X Y1 Y2 Z although I can set a % when homing to trip an alarm, in some cases the Y1 motor is going to crash with the end of the machine.

https://user-images.githubusercontent.com/19658139/228560285-f3705ee1-5f05-45c5-a2c0-32acc88ef333.mp4

[pachucristo]

Homing works ok with my CNC machine simulator. Note that performing a successful homing cycle by manually triggering switches is hard for a single motor axis, for a dual motor axis close to impossible?

GRBL 1.1f you can home even 3 motors at the same time, every one of them stoping right where the switches are in the machine space. ( thats because usualy the Y2 switch is wired parallel to the Z switch, so home Z first, then X, Y1and Y2 at the same time, because in that cycle the 3 limit pins are available to react and stop where it should. in this case, the home cycle only reacts stoping the motor when Y2 trigger first. if Y1 trigger first it keeps turning towards the Y1 switch and only stops when Y2 is triggered. its like the homing routine only keep going if one(exclusive) of the 2 ganged switch triggers first, and not either of the 2 ganged switch like should it be. like in 1.1f.

I hope i was clear with this observation, Thanks!

[terjeio]

thats because usualy the Y2 switch is wired parallel to the Z switch

This is not supported by grblHAL - each limit switch has its own input. $pins lists which:

if Y1 trigger first it keeps turning towards the Y1 switch and only stops when Y2 is triggered.

Oops - this is a regression from last year - a line was commented out that should not be.

Tip: you may use the $lim command to check which switches are triggered - see this discussion for details.

[terjeio]

Fix committed.

[pachucristo]

This is not supported by grblHAL - each limit switch has its own input. $pins lists which:

yes indeed, I looked up in $pins to check where that default 22 pin for Y2 limit goes. the probe socket, perfect.

if now I use the web tool to compile a new firmware, would now be fixed? thanks a lot!

[terjeio]

if now I use the web tool to compile a new firmware, would now be fixed?

Yes.

[petervanderwalt]

Yes, Probe is currently mapped as the "4th" endstop (you do lose probing) - ie for Auto Square and 4th axes configs - in our default pinmap.

his is not supported by grblHAL - each limit switch has its own input

Could pin sharing be made possible? Due to physical space constraints we can't (couldn't) add more input ports,

grbl could handle multiple homing switches on a single pin (See https://github.com/gnea/grbl/blob/master/grbl/config.h#L622-L624)

to handle Auto Squaring without giving up Probing

It also opens the door to slave A-axis off Z or X, and still maintain access to the Probe Port

The concept was pretty cool, relying on the homing sequence to differentiate, if its moving Y only, but sees a trigger on Z - it knew that was actually Y2 then.

[terjeio]

A plugin or board specific code can do this, a bit similar to what I did when I hijacked the Z limit input for the embroidery plugin. There might be one snag though, if the limit input is asserted when homing starts which axis to back off? And there should be a check for the user attempting to home both axes, that share the input, at the same time?

[terjeio]

Here is an attempt at modifying the reported limit switch state in board specific code:

BlackBoxX32.zip

Can somebody verify it and if it works as indented give feedback if I should change the master.

Note that BlackBoxX32.c has to be added to CMakeLists.txt in the SRCS list for it to compile correctly.

Z is rerouted for X or Y auto squaring, X for Z. And Z for homing A. Switches has to be wired in series or parallell depending on type (NC vs. NO).

Edit: updated zip for correct A-axis handling.

[petervanderwalt]

Ahhh sorry - missed it

Gotta spin a build environment - don't currently have one (oh how Web Builder has us spoiled!)

If you could drop a binary with 4-axes enabled - I have a customer who could check it out right away: https://openbuilds.com/threads/4-axis-cnc-hot-wire-foam-cutter.20176/#post-133908

[petervanderwalt]

Can somebody verify it and if it works as indented give feedback if I should change the master.

Customer reports its working great! customer tested https://openbuilds.com/threads/4-axis-cnc-hot-wire-foam-cutter.20176/page-2#post-133954

Todo @openbuilds - update binary in our firmware flasher tool https://github.com/OpenBuilds/OpenBuilds-CONTROL/issues/306 and also a docs page with the parallel switch wiring and other details