I’m running latest grbl-mega 1.1g on a PCB mill using a Mega256 on a RAMPS1.4 board.
I have endstop switches for XYZ which report fine:
The MAX-Z endstop is new and works during homing as expected: I lift to max, then to X and Y homing together.
I want to use MIN-Z to probe autolevel my PCB which was working using a simple
G38.2 Z-10 F10
before.
However, no matter what I set for $6=0/$6=1 I always get an ALARM:4 or ALARM:5
I measured the pins of my crocodile leads to the PCB and they show the 5V pullup I’m expecting and 0V when I short the pins on the PCB (as expected). GRBL then reports:
I assume, that’s also to be expected as a Z switch was triggered.
However, after homing, I set my machine to X5Y5 and run
G38.2 Z-10 F10
which is immediately killed with ALARM:4
Any idea why this is not working anymore:
!image
评论 (3)
#2 – fra589 于 2022-01-04
Hi @McNugget6750
As we can see in cpu_map.h (line 252 to 257), the probe have his own pin to work:
“
// Define probe switch input pin.
#define PROBE_DDR DDRK
#define PROBE_PIN PINK
#define PROBE_PORT PORTK
#define PROBE_BIT 7 // MEGA2560 Analog Pin 15
#define PROBEMASK (1<
`Pn:
The proble pin input state is reported in the field of the ? reply.$#` command (see https://github.com/gnea/grbl/wiki/Grbl-v1.1-Interface).
The probe result is send by Grbl immediately at the end of probing, the last probe can be retrieved in the reply of the
@++;
Gauthier.
#3 – McNugget6750 于 2022-01-04
Thank you Gauthier!
I did miss that during my transition from 0.9 to 1.1… Thank you for pointing this out. I soldered a new pin and it reports properly now. I used the default pin A15 aka PORTK7.
#1 – McNugget6750 于 2022-01-03
Using $6=0, the probe moves in the right direction (down), however, it does not react to any pin change on MIN-Z – even though, as stated above, GRBL understands my probing pin.