core
core copied to clipboard
grblHAL
Homing giving up too early
When homing my machine (teensy 4.1 + T41U5XBB board), it appears to be giving up too early and throwing an alarm 9.
For example requesting a home of X ($H X), moves X towards the endstop for ~20-30mm then stops and alarms. My understanding is it should attempt to travel 1.5*max travel before giving up
X Max travel: $130 = 330.00
I've verified my steps/mm settings, ie jogging 20mm moves the axis 20mm.
Ideas?
Ideas?
Noisy limit input?
What is the output from the $LIM command after the alarm is raised?
$H X ALARM:9 GrblHAL 1.1f ['$' or '$HELP' for help] [MSG:'$H'|'$X' to unlock] [VER:1.1f.20220325:] [OPT:VNMHSL,35,1024,3,0] [NEWOPT:ENUMS,RT+,HOME,ES,TC,SED] [FIRMWARE:grblHAL] [NVS STORAGE:*FLASH] [DRIVER:iMXRT1062] [DRIVER VERSION:220325] [DRIVER OPTIONS:USB.2] [BOARD:T41U5XBB] [AUX IO:4,3,0,0] [PLUGIN:MODBUS v0.12] [PLUGIN:HUANYANG VFD v0.07] [G54:-278.500,11.670,-1.500] [G55:0.000,0.000,0.000] [G56:0.000,0.000,0.000] [G57:0.000,0.000,0.000] [G58:0.000,0.000,0.000] [G59:0.000,0.000,0.000] [G59.1:0.000,0.000,0.000] [G59.2:0.000,0.000,0.000] [G59.3:0.000,0.000,0.000] [G28:0.000,29.000,0.000] [G30:0.000,0.000,0.000] [G92:0.000,0.000,0.000] [HOME:0.000,0.000,0.000:0] [TLO:0.000,0.000,0.000] [PRB:0.000,0.000,0.000:0] $LIM [LIMITS:,,,]
Is it normal for it to perform a reset?
Is it normal for it to perform a reset?
No, which sender are you using? Can you try with a terminal such as putty?
Is it normal for it to perform a reset?
No, which sender are you using? Can you try with a terminal such as putty?
ioSender.
Interesting, directly through putty it homes just fine.
<Idle|MPos:-14.430,11.670,-1.500|Bf:35,1023|FS:0,0,0|Pn:PHS> <Home|MPos:-14.430,11.670,-1.500|Bf:35,1023|FS:0,0,0|Pn:PHS> [MSG:] ok [LIMITS:,,,]
ioSender.
Ok, ioSender sends a reset on alarms to simplify handling. But odd that the alarm is triggered when using it. Which version do you have?
Do you want me to move this over to the ioSender repo?
No, it is likely a controller issue as alarm 9 is raised. What I would like is your controller settings pasted to a file and attached here. Use the To Clipboard button in the About dialog above to get them.
I have tested with your settings (and my simulator) and I do not get alarm 9 and homing completes as it should. Is homing for Y and Z also generating alarm 9 for you?
I have tested with your settings (and my simulator) and I do not get alarm 9 and homing completes as it should. Is homing for Y and Z also generating alarm 9 for you?
Same issue with Y and Z
Not sure if its related, but certainly doesn't seem right.
Performing a move through iosender or UGS like G1 X200 F500 might stop a few times during the move for a second, then continue on. Doing it directly through putty has no such stutters.
Edit: This might be the teensyduino issue. I'll fix that up and report back
Ok, looks like the spindle/modbus enables were causing the issue. Commenting them out in my_machine.h and reflashing results in successful homing and moves.
Looking at: https://github.com/grblHAL/iMXRT1062/issues/15
I then removed the version lock on the teensy library in platformio: [env:teensy41] board = teensy41 platform = ${common_teensy.platform} #platform = ${common_teensy.platform}@4.12
This also worked fine, as did re-enabling spindle/modbus. So I guess this was the known teensyduino issue?
Thanks for your help @terjeio
Spoke too soon. Having random stalls still, which appear to be effecting (causing?) the homing alarm. I've noticed that the tx/rx lights on the ttl rs485 adapter stop blinking while the stall is happening
Spend last night working on this. Seems to be related to the teensyduino issue. I didn't clean the project last time, so I was still pulling in v4.12. Cleaning it properly and now I was getting the compilation error from issue 15, so I just removed the dependencies on uSDFS, MSC and teensy41_ethernet. This builds fine and appears to be working fine...
You have run into the random stalling present in pre v1.54 versions of Teensyduino? See the Important notice in the driver readme.
I did read that before starting all of this, I just didn't realise the default configuration of platform.ini would pull it in. Which is understandable as that is what allows the SD library to build.
@terjeio Has been a while since iMXRT1062 issue #15 was updated.
What about changing the default platformio.ini config to bump the teensyduino version & disable SD card support (until a fix for the SD card issue is agreed)? Would probably be a better starting point for new users..
The default platformio.ini has been fixed, and the new Web Builder is another option for compiling that does not require installation of a toolchain.