Z-Axis Wants to Home Even When Homing is Turned Off

[hollingerc]

I'm updating the electronics in an existing machine which currently uses an old 68HC11 MPU (now virtually obsolete) and even older stepper motor drivers. The machine has a rotating head (+/-20*) that has an embedded linear Hall sensor for position. The sensor outputs 5V when the head is rotated one way, 0V when rotated the other way and 2.5V in the center. The values are approximate and vary from machine to machine but are consistent for a given machine. I need to be able to home this rotator to the middle position, but obviously grblHAL can't use this sensor as a limit switch. The electronics I've designed has two MCUs, both STM32F411, one for grbl and the other for the user interface (UI) and other functions of the machine and sends G-codes to control the machine through the grbl MCU. I want to use the UI MCU to 'manually' home the rotator (on the Z-axis) by issuing G-codes and reading the Hall sensor to step the head in the correct direction to home it at the mid-point.

If someone has a better idea to do this, I'd be happy to hear about it.

I haven't even gotten to the part of 'jogging' the rotator as I described above because of this problem:

After power up or hard reset, any G0 code sent to the Z-axis causes the rotator to move in the same direction for a certain 'distance' then stop. After this is done, G-codes sent to that axis work as expected. Unfortunately, the distance moved in this apparent 'homing' action exceeds the mechanical limits. If I send G-codes to the X or Y axes, they move as expected. This problem only occurs on the Z-axis. I have homing turned off.

This is a custom board and I'm compiling a copy of grblHAL I cloned in March 2024 (signs on as "grblHAL 1.1f"). I have modified the my_machine.h file with these changes (uncommenting these lines):

#define BOARD_MORPHO_CNC // For use with Nucleo-F411RE and F446RE boards. Work in progress.

#define TRINAMIC_ENABLE 2209 // Trinamic TMC2209 stepper driver support.

#define TRINAMIC_R_SENSE 110 // R sense resistance in milliohms, 2130 and 2209 default is 110, 5160 is 75.

I have modified the st_morpho_map.h file to reflect the pinout configuration of my board. Too big to post here, but can provide it if needed.

It seems to me grbl needs to home the Z-axis even though I have homing turned off. Not so for the X and Y axes. I have re-built the firmware and flashed the MCU a couple of times, but the problem persists. Have I configured something incorrectly or is this the way grblHAL works (or is this a bug?)?

Thanks in advance for any help.

Craig.

This is a listing of my settings:

$0=10.0
$1=25
$2=0
$3=2
$4=7
$5=1
$6=0
$9=1
$10=511
$11=0.010
$12=0.002
$13=0
$14=0
$15=0
$16=0
$17=70
$18=7
$19=0
$20=0
$21=0
$22=0
$23=7
$24=50.0
$25=500.0
$26=250
$27=1.000
$28=0.100
$29=0.0
$30=1000.000
$31=0.000
$32=0
$33=5000.0
$34=0.0
$35=0.0
$36=100.0
$37=0
$39=1
$40=0
$43=1
$44=4
$45=3
$46=0
$62=0
$63=3
$64=0
$65=0
$100=629.92126
$101=629.9126
$102=53.33332
$110=500.000
$111=500.000
$112=500.000
$120=20.000
$121=20.000
$122=10.000
$130=38.000
$131=7.000
$132=40.000
$140=500
$141=500
$142=500
$150=16
$151=16
$152=16
$180=50.0
$181=50.0
$182=50.0
$190=500.0
$191=500.0
$192=500.0
$200=22.0
$201=22.0
$22=22.0
$210=50
$211=50
$212=50
$220=22.0
$221=22.0
$222=22.0
$338=7
$339=0
$341=0
$342=30.0
$343=25.0
$344=200.0
$345=200.0
$346=1
$3700
$372=0
$384=0
$398=100
$481=0
$484=1
$486=0

[terjeio]

Is there an offset active for Z?
If you switch to relative moves by first sending G91 then the G0Z command does is still behave the same?

[hollingerc]

Thanks for the suggestion. Nearing bedtime here so I'll give it a try tomorrow.

[hollingerc]

There were no offsets active at the time. This situation with the Z-axis occurs after a power up or hard reset.

I switched to relative moves with G91 and the Z-axis moved correctly with a G0Z command and didn't race off to the distant coordinate. I can work with the Z-axis now.

It's interesting that the X and Y axes didn't need to be in the relative move state, right after reset they responded correctly with G0 commands and didn't race off.

I don't consider the discussion closed yet as there doesn't seem to be an explanation for the Z-axis behavior. I'll play with this and see what happens. Will keep you posted. Thanks for your help.

Craig.

[hollingerc]

Back to homing the Z-axis topic again.

I implemented my idea for 'jogging' the rotary head (Z-axis) to the center point but sadly it didn't work. It was way too slow as I had to poll grbl to determine when the jog move was complete. Grbl can't be polled faster than about every 10ms so a bunch of short moves took forever. I increased the size of the move, but that only resulted in missing the home position. I have given up on this method.

Now I want to try sensorless homing but having trouble getting it to work. When I enabled sensorless homing ($339=4, for the Z-axis only) and sent the homing command ($HZ) the axis did not move. Grbl sent these messages:

$HZ
<Home|MPos:0.000,0.000,-15.000|Bf:100,1023|FS:0,0|Pn:P>
ok

When status is requested (?) this is the message:

?<Idle|MPos:0.000,0.000,-15.000|Bf:100,1023|FS:0,0|Pn:P>

So it seems that grbl thought it did the homing move.

If I disable sensorless homing with the $339 command, and send $HZ again, the axis now moves (crashes into the endstop as there is no working home switch).

From the reading I've done it seems pretty straight forward to setup sensorless homing except for the tuning. Do I have the StallGuard settings too sensitive (they are at the defaults) and the controller detects a stall just as the axis moves? I didn't see any movement at all. Am I missing something?

Craig.

Here are the settings and the output from the M122 command:

$$
$0=5.0
$1=25
$2=0
$3=2
$4=7
$5=1
$6=0
$9=1
$10=511
$11=0.010
$12=0.002
$13=0
$14=0
$15=0
$16=0
$17=70
$18=7
$19=0
$20=0
$21=0
$22=43
$23=7
$24=110.0
$25=1100.0
$26=35
$27=0.500
$28=0.100
$29=0.0
$30=1000.000
$31=0.000
$32=0
$33=5000.0
$34=0.0
$35=0.0
$36=100.0
$37=3
$39=1
$40=0
$43=1
$44=2
$45=1
$46=4
$62=0
$63=3
$64=0
$65=0
$100=629.92126
$101=629.92126
$102=53.33300
$110=1100.000
$111=900.00
$112=900.000
$120=80.000
$121=65.000
$122=65.000
$130=38.000
$131=10.160
$132=10.000
$140=1000
$141=1000
$142=500
$150=16
$151=16
$152=16
$180=110.0
$181=110.0
$182=110.0
$190=110.0
$191=900.0
$192=900.0
$200=22.0
$201=22.0
$202=22.0
$210=12
$211=12
$212=12
$220=22.0
$221=22.0
$222=22.0
$338=7
$339=1
$341=0
$342=30.0
$343=25.0
$344=00.0
$345=200.0
$346=1
$370=0
$372=0
$384=0
$398=100
$481=0
$484=1
$486=0

M122
[TRINAMIC]
X Y Z
Driver TMC2209 TMC2209 TMC2209
Set current 1000 1000 500
RMS current 994 994 489
Peak current 1405 1405 691
Run current 17/31 17/31 15/31
Hold current 2/31 2/31 1/31
CS actual 2/31 2/31 1/31
PWM scale 4 26 2
vsene 0=0.325 0=0.325 1=0.180
stealthChop true true true
msteps 16 16 16
tstep 104875 1048575 1048575
pwm
threshold 0 0 0
[mm/s] 0 0 0
OT prewarn false false false
OT prewarn has
been trigered false false false
off time 3 3 3
blank time 1 1 1
hysteresis
-end -1 -1 -1
-start 1 1
Stallguard thrs 0 0 0
DRIVER STATUS:
stallguard
sg_result 48 78 166
fsactive
stst * * *
olb
ola
s2gb
s2ga
otpw
ot
STATUS REGISTERS:
X = 0xC0:02:00:00
Y = 0xC0:02:00:00
Z = 0xC0:01:00:00

[terjeio]

I need to be able to home this rotator to the middle position, but obviously grblHAL can't use this sensor as a limit switch.

Why not? If you add some electronics (e.g. an analog window comparator) it should be possible?

I implemented my idea for 'jogging' the rotary head (Z-axis) to the center point but sadly it didn't work. It was way too slow as I had to poll grbl to determine when the jog move was complete.

What is the input used to determine the center point? Via a sensor or via human observation?

From the reading I've done it seems pretty straight forward to setup sensorless homing except for the tuning.

The tuning is the biggest hurdle, for one off machines I cannot recommend sensorless homing. I guess it is ok for mass produced machines if the manufacturer is willing to spend time to tune it up. FYI you may enable further tuning parameters uncommenting this line. Currently these will be applied to all motors.

Do I have the StallGuard settings too sensitive (they are at the defaults) and the controller detects a stall just as the axis moves?

Perhaps. FYI there is an untested compile time option that allows reducing the acceleration during homing.

ioSender has a Trinamic tab that can be used for tuning the stallguard setting.

BTW which version (build date) are you using now?

[hollingerc]

Thanks for the quick response.

A comparator is another option I was planning to explore. Will go that route if sensorless homing proves to be too difficult.

I used an MCU analog input and read the voltage output of the Hall sensor. I determined the analog reading of the center of rotation manually then used that value with hysteresis to stop the seeking. It turned out to be too difficult (slow) to determine from grbl when the move had completed so the next ADC reading could be taken while movement was stopped. This is the method used in the current, but outdated machines, but the MCU in them had direct control over the stepper motor. It knew exactly when the motor had made a step. I may revisit this method, but for now I believe I've exhausted that approach.

This is a production machine, several being built each year (not sure of the numbers, I don't work for the company, just a contract engineer). If I get sensorless homing to work, I'll have to figure out a range of tuning, then work with production to teach them how to fine tune it.

I'll check out the compile time option and IoSender.

Here is the information output, I haven't checked recently if there is a newer version of grbl or the Trinamic plug-in.

$I
[VER:1.1f.20240228:]
[OPT:VNMZHSL,100,1024,3,0]
[AXS:3:XYZ]
[NEWOPT:ENUMS,RT+,HOME,ES,SED,PID,TMC=7]
[FIRMWARE:grblHAL]
[SIGNALS:HSEP]
[NVS STORAGE:*FLASH]
[FREE MEMORY:92K]
[DRIVER:STM32F411]
[DRIVER VERSION:240217]
[BOARD:Nucleo-64 CNC Breakout]
[AUX IO:6,6,0,0]
[PLUGIN:Trinamic v0.15]
ok

Not using the Nucleo-64 CNC breakout board, just hijacked that board file. Using a custom board I designed.

Craig.

[terjeio]

I haven't checked recently if there is a newer version of grbl or the Trinamic plug-in.

There are.

While homing limit switch status is polled at a very high frequency, plugin code may insert itself into the HAL limit switch status call and modify the returned value as it sees fit. Checking an interrupt or DMA aquired ADC value and returning switch triggered status is possible.
An example, it redirects the Z-limit input to the second Y or X side when homing Y (or X) in an auto squared machine.

[hollingerc]

Would the new versions of grbl and the Trinamic plugin make any difference to what I'm doing?

Would checking an interrupt or DMA require modifying grbl or the Trinamic plugin? I don't want to put effort into modifying either of those, I'll leave that up to the original developers.

Redirecting the Z-limit input into the X or Y input wouldn't do anything. The problem I'm trying to solve is giving grbl a limit switch signal it can identify, either a snap voltage transition or a stall condition. The linear output of the Hall sensor won't work without modification. An it looks like sensorless homing would be cumbersome to implement, especially in a production environment.

Beginning to look like using a comparitor on the Hall sensor output is the better option.

Thanks for your input, I think you have given me the direction to go in.

Craig.

[terjeio]

Would the new versions of grbl and the Trinamic plugin make any difference to what I'm doing?

Default stepper mode has been changed so possibly yes.

Would checking an interrupt or DMA require modifying grbl or the Trinamic plugin?

No.

Redirecting the Z-limit input into the X or Y input wouldn't do anything.

The example I provided can be used as a basis for a new plugin: add the ADC code to it, rename the init function to my_plugin_init() and put the renamend file in the Src directory. And of course modify the code that modifies the limit switch status return to suit you. Then just recompile and reflash. my_plugin_init() is defined as a weak function in the core and your version will override it, allowing you to add or override functionality without touching any other source code.

[hollingerc]

Thanks, I'll have a look at this.

I don't understand how it works so it'll take a while for me to figure it out and I don't have a lot of time to put into it.

[hollingerc]

Getting back to the reason I started this discussion on Sept 26, I think I've found the answer. After some more investigation I found that after going through a homing cycle the machine coordinates were all set to zero. Not so for the work coordinates which set X and Y to zero but Z to 75. It now makes sense that any absolute move less than 75 on the Z axis would cause the runaway move I was seeing. I was making move much less than 75. When I sent a G92X0Y0Z0 command after homing, the work coordinates were all set to zero and the runaway move problem no longer occurred. Grbl is now responding as I would expect and my machine is making the correct motions.

Is the setting of the Z axis to 75 in the work coordinates by grbl intentional? I assume this may be so that the spindle is moved away from the work piece to avoid collisions. Have I possibly caused further problems by sending this G92 command?

Please forgive my ignorance, I have virtually no experience with grbl, G-codes and the CNC machine world.

[terjeio]

Is the setting of the Z axis to 75 in the work coordinates by grbl intentional?

You must have set it yourself at some point since the initial default for all offsets are 0. Note that grblHAL differs from legacy Grbl though, G92 offsets are by default persistent (grblHAL behaves like LinuxCNC) - you may disable this by setting $384=1.

[hollingerc]

OK. I don't know how I managed to set the offsets, certainly wasn't intentional. I looked through config.h but couldn't find anywhere to set the offsets. How is this done?

[terjeio]

G10L2, G10L20 and G92. More here. grblHAL does not support G52.

[hollingerc]

Thanks.