Ganged Motor discussion

[phil-barrett]

Preface: while I am posting this in the iMXRT1062 section, it really applies across all ports.

The changes to the way a ganged motor is allocated took me a little head scratching at first but I am coming around to seeing it as a good change. I have come up with a way to support backward compatibility (alternate map file that swaps A and B) so people upgrading do not have to rewire.

But this got me wondering why grblHAL does not show the motors as ganged.

$pins shows two sets of pins attached the ganged axis. For example, if Y and A motors are ganged as the Y axis, both Y and A pins are listed as Y. I think Y motor's pins should be listed as Y1 and A motor's pins as Y2. Or perhaps A pins as Y(A)? (by the way, the $pin command is very useful - I'm juggling multiple map files and it really helps)

In addition, with the above example, you do not see A at all in Grbl settings. In general it is OK to not be able to change A's settings because the two sets (Y and A) should always be the same, except for 1 - direction. When Y turns CW, A should turn CCW (or ACW for Queen's English speakers). This is easy enough to do with the motor wires. But, being a bit AR - I prefer to keep all my wiring the same and invert the second ganged motor in settings. Also, I think it is good to be able to see the 2nd motor in settings, it exists.

So, I am suggesting 2 things:

• The ganged motor showing up in the various settings and those that should not be different would be for information only (i.e. $nn shows the setting, $nn=xx is ignored). Maybe greyed out in ioSender?
• Making the ganged motor's direction bit in $3 settable.

Also, there is a question whether one would ever want ganged motors with different settings like steps/mm and so on. I am fairly sure the answer is no. But, I am certain that somewhere someone has thought about building such a machine.

[terjeio]

But this got me wondering why grblHAL does not show the motors as ganged.

Give me some time, the $pins report is not yet complete. It should list pins assigned to PWM, UART etc. not only plain GPIO. Should I remove it until then? (I added it initially for myself to aid testing).

I think Y motor's pins should be listed as Y1 and A motor's pins as Y2

My plan is to use Y and Y2, depending on how I implement the labeling (statically or dynamically generated).

In addition, with the above example, you do not see A at all in Grbl settings.

A is an axis label that can be used as a motor label. In a ganged configuration the second motor should, IMO, never be represented (in grblHAL) using an axis label such as A as it has nothing to do with the A-axis. If N_AXIS is set > 3 A etc. shows up in settings and in the $pins report as it should:

[PIN:2,X step]
[PIN:4,Y step]
[PIN:6,Z step]
[PIN:8,A step]

Looking at the map files you will see that motor pins are prefixed with M3, M4 and M5 depending on how many motors > 3 are available. Depending on the configuration M3 can be assigned as A, X2, Y2 or Z2, M4 as B, X2, Y2 or Z2 and M5 as C, X2 , Y2 or Z2.
Board labeling is problematic when motors can be assigned to ganged axes, perhaps M3-M5 should be used as A etc. is misleading when ganged axes are configured? Or perhaps M3(A), M4(B)... could be used?

For those who might wonder, it is possible to have all three axes (XYZ) ganged (or auto squared) when the breakout board supports six motors. And of course two axes when it supports five motors.

So, I am suggesting 2 things:
The ganged motor showing up in the various settings and those that should not be different would be for information only (i.e. $nn shows the setting, $nn=xx is ignored). Maybe greyed out in ioSender?
Making the ganged motor's direction bit in $3 settable.

It may seem simple but it is going to be a lot of work, I'll leave that to somebody else. And reason for not doing it is this:

Also, there is a question whether one would ever want ganged motors with different settings like steps/mm and so on. I am fairly sure the answer is no.

But, I am certain that somewhere someone has thought about building such a machine.

Then that someone should, IMO, write their own driver for it.

[terjeio]

Setting $8 was added a while ago for invert the direction of the second motor(s) for ganged axes.

[massiveradiation]

Hello folks,
Not to step on toes, but I wanted to suggest a better way to autosquare. I've been using FluidNC for a while now and the auto squaring is really great. If you have Y steppers on separate axis (Y1, Y2/A), you can set the pulloff distance from each Y limit switch in the config file. This is a very precise way of doing it and eliminates the need to physically adjust limit switches on the machine. I'm thinking of setting up my new machine with grblHAL, but I am reticent to give up this feature.
Has anyone implemented this approach to auto squaring in the grblHAL camp? Only one parameter would have to be added, Y2 pulloff distance. In case you're not familiar with the homing sequence in FluidNC, both Y axis motors travel until the limits on both are triggered, then Y1 and Y2 pulloff the distances set in the config.yaml file.
To calibrate squareness, I make sure my XY stepper calibration is accurate first. Then run a 3-4-5 triangle with a pointy bit in the spindle and measure the distance of the hypotenuse. If the angle is obtuse/accute, I tweak the pulloff distance from Y2 limit switch until it's perfect, done.
Thoughts?

[terjeio]

Use $17n to specify the offset where n is the axis id (0 = X, 1 = Y, 2 = Z), e.g. $171 is for Y.

[phil-barrett]

Came here to say that. Make sure you have build your firmware with Auto-squared axis (not just ganged). My blog on auto-squaring predates this - I should update it.

[massiveradiation]

Oh yes, please do update! Thanks Phil.

…

On Tue, Sep 17, 2024, 05:58 phil-barrett ***@***.***> wrote: Came here to say that. Make sure you have build your firmware with Auto-squared axis (not just ganged). My blog on auto-squaring <https://www.grbl.org/single-post/it-s-hip-to-be-auto-square> predates this - I should update it. — Reply to this email directly, view it on GitHub <#9 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGUKYUWNJYPJDLTIXFTXBUDZW74L7AVCNFSM6AAAAABOJ6D3NSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANRWHA3TIOI> . You are receiving this because you commented.Message ID: ***@***.***>

[phil-barrett]

Thanks, Terje. I have updated the auto-squaring post to reflect that.

[phil-barrett]

I posted a method for determining the dual axis offset value from the diagonals.

[massiveradiation]

Hey folks,
Quick question regarding autosquare setup and the term "ganged." Assuming that Y1 and Y2 steppers are on separate drivers, the term "ganged" means that whatever positional signals are sent to Y1, identical signals are sent to Y2. If this is the case, they should never move independently, hence the definition of the word, "ganged."
However, after reading the above and Phil's page Hip to be auto square, I'm still a bit confused. Y1 and Y2 need to be set as ganged and autosquare set to on. Once this is done, when the value of $171 is changed to 1, it would mean that after homing an additional pulloff from Y1 of 1mm. And $171=-1 would mean an additional pulloff from Y2 of 1mm. Do I have this correct? If so, the term "ganged" is a bit misleading? Or it could be me.
Clarification would be much appreciated.
Also, in case want to setup autoquare and ganged Y axis steppers from the config files themselves vs using the grblHAL builder page, what needs to be changed and in which configuration files?
Cheers!

[terjeio]

Auto-squared axes are ganged when not homing. If configured as only ganged means that auto squaring is disabled.
Internally in the code if an axis is defined as auto-squared it is automatically defined as ganged as well, only auto-square or ganged needs to be enabled.

Configuration is in my_machine.h, for the iMXRT1062 here.

[phil-barrett]

Yes, you have it correct. There are a number of moving parts that can lead to some confusion. The web builder is fairly straightforward - select ganged or auto-square. Pull-off is a function of $17x only if auto-square is selected and is basically an aspect of system tuning.

The term ganged is used in place of the older term "slaved". Some decry it as being "woke". However, slaved is incorrect in that one driver/motor is not subservient to the other - they are treated equally. As you point out, the same signals are sent to both drivers/motors.

[massiveradiation]

Thanks gents! This clears it up. The part I didn't understand is that they're ganged except for when executing the auto square function, post homing.