search

grblHAL / core

grblHAL core code and master Wiki
Other
330 stars 87 forks source link

Homing giving up too early #145

Closed evanwyatt closed 1 year ago

evanwyatt commented 2 years ago

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?

terjeio commented 2 years ago

Ideas?

Noisy limit input? What is the output from the $LIM command after the alarm is raised?

evanwyatt commented 2 years ago

$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?

terjeio commented 2 years ago

Is it normal for it to perform a reset?

No, which sender are you using? Can you try with a terminal such as putty?

evanwyatt commented 2 years ago

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:,,,]

terjeio commented 2 years ago

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?

evanwyatt commented 2 years ago

image

evanwyatt commented 2 years ago

@terjeio Do you want me to move this over to the ioSender repo?

terjeio commented 2 years ago

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.

evanwyatt commented 2 years ago

Attached. grbl.txt

terjeio commented 2 years ago

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?

evanwyatt commented 2 years ago

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

evanwyatt commented 2 years ago

Also tested with UGS as the sender, same issue.

evanwyatt commented 2 years ago

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

evanwyatt commented 2 years ago

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

evanwyatt commented 2 years ago

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

evanwyatt commented 2 years ago

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...

terjeio commented 2 years ago

You have run into the random stalling present in pre v1.54 versions of Teensyduino? See the Important notice in the driver readme.

evanwyatt commented 2 years ago

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.

dresco commented 2 years ago

@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..

terjeio commented 1 year ago

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.