[Grbl_Esp32 Issue#432] Can’t invert limit switches state with $5 About GRBL HAL

Issue #432 | 状态: 已关闭 | 作者: blaisebarrette | 创建时间: 2020-06-13

标签: bug

When I send the question mark via MDI when no limit switches are activated, I get “Pn:XYZ“.
If I activate the X axis limit switch, I get “Pn:YZ” so I know that my limit switch is working. It’s the same for all limit switches. They all work ok but they show as activated when they’re not. So I set the $5 setting to 1 ($5=1) but nothing changes. I always get “Pn:XYZ” with $5 set to 1 or to 0.

My limit switches are NO and are connected to the following GPIO:
X -> GPIO17
Y -> GPIO4
Z -> GPIO15

Any help would be greatly appreciated.

#1 – MitchBradley 于 2020-06-13

Which machine file did you use? What is the value of LIMIT_MASK in that configuration?

#2 – ghost 于 2020-06-13

In config.h –
“// By default, Grbl sets all input pins to normal-high operation with their internal pull-up resistors // enabled. This simplifies the wiring for users by requiring only a switch connected to ground, // although its recommended that users take the extra step of wiring in low-pass filter to reduce // electrical noise detected by the pin. If the user inverts the pin in Grbl settings, this just flips // which high or low reading indicates an active signal. In normal operation, this means the user // needs to connect a normal-open switch, but if inverted, this means the user should connect a // normal-closed switch. // The following options disable the internal pull-up resistors, sets the pins to a normal-low // operation, and switches must be now connect to Vcc instead of ground. This also flips the meaning // of the invert pin Grbl setting, where an inverted setting now means the user should connect a // normal-open switch and vice versa. // NOTE: All pins associated with the feature are disabled, i.e. XYZ limit pins, not individual axes. // WARNING: When the pull-ups are disabled, this requires additional wiring with pull-down resistors! //#define DISABLELIMITPINPULLUP //#define DISABLEPROBEPINPULLUP //#define DISABLECONTROLPINPULLUP“
My GRBL $5 = 1… if I change it to 0 I get Pn:XYZ That is without any switches attached. ie. N/O

#3 – MitchBradley 于 2020-06-13

I said machine file, not config file. And I also asked the value of LIMIT_MASK.

#4 – ghost 于 2020-06-13

And the person asking the questions didn’t answer you. My LIMIT_MASK is B0 and I am using v1.2a but then again, my limit switches work fine.

#5 – blaisebarrette 于 2020-06-13

> Which machine file did you use? What is the value of LIMIT_MASK in that configuration?

I made my own PCB so I created a custom machine file to match.

Here is the code of my machine file:
“#define MACHINE_NAME "Cyclone PCB Factory"


   #define XSTEPPIN              GPIONUM12

   #define XDIRECTIONPIN         GPIONUM14

   #define YSTEPPIN              GPIONUM27

   #define YDIRECTIONPIN         GPIONUM26

   #define ZSTEPPIN              GPIONUM25

   #define ZDIRECTIONPIN         GPIONUM33
   #define XLIMITPIN             GPIONUM17

   #define YLIMITPIN             GPIONUM4

   #define ZLIMITPIN             GPIONUM15
   #define STEPPERSDISABLEPIN    GPIONUM32
   #define SPINDLEOUTPUTPIN      GPIONUM2   // labeled SpinPWM

   #define PROBEPIN               GPIONUM_35  // labeled Probe

#define CONTROLRESETPIN GPIONUM34 // labeled Reset, needs external pullup #define CONTROLFEEDHOLDPIN GPIONUM_36 // labeled Hold, needs external pullup #define CONTROLCYCLESTARTPIN GPIONUM_39 // labeled Start, needs external pullup“

If the “LIMIT_MASK” is supposed to be defined in the machine file, I must have deleted that setting by mistake.

I also have attached the schematic of my custom “Shield” in case so you have all the info.

#6 – MitchBradley 于 2020-06-13

If you do not have LIMIT_MASK defined in your machine file it defaults to 0 meaning no limit switches. That would cause your problem. Look at the description in Machines/template.h . It seems pretty clear to me.

#7 – blaisebarrette 于 2020-06-13

I tried setting LIMIT_MASK to “B111” and I see no change.

#8 – MitchBradley 于 2020-06-14

You could add some “grblsendf” debugging code to grbllimits.cpp, near line 366, so it looks like this.
“grblsendf(CLIENTSERIAL, "before %x\r\n", pin); if (bitistrue(settings.flags, BITFLAGINVERTLIMITPINS)) pin ^= LIMIT_MASK; grblsendf(CLIENTSERIAL, "after %x\r\n", pin); if (pin) { uint8_t idx; for (idx = 0; idx < N_AXIS; idx++) { if (pin & getlimitpin_mask(idx)) limit_state |= (1 << idx); } } grblsendf(CLIENTSERIAL, "limit %x\r\n", limit_state); return (limit_state);“

#9 – blaisebarrette 于 2020-06-14

Ok. I’ll have a look and let you know.

THanks!

#10 – blaisebarrette 于 2020-06-14

I did as you suggested and here are my results:
If none of the 3 switches are activated I get “7”
X activated = 6
Y activated = 5
Z activated = 3
X + Z activated = 2
X + Y activated = 4
Y + Z activated = 1
X + Y + Z activated = 0

And it’s always the same for all three lines (before, after and limit)

Hop this helps.

#11 – blaisebarrette 于 2020-06-14

Now I seem to have an even worst problem! As soon as I try to jog or send an M3 to enable the spindle the ESP32 reboots and gives me the following:

“Guru Meditation Error: Core 1 panic'ed (IntegerDivideByZero). Exception was unhandled. Core 1 register dump: PC : 0x4021eb3f PS : 0x00060b30 A0 : 0x800d2dff A1 : 0x3ffd0cb0 A2 : 0x00000000 A3 : 0x00000001 A4 : 0x00000000 A5 : 0x00000000 A6 : 0x00002000 A7 : 0x3ffcf000 A8 : 0x00000000 A9 : 0x00000000 A10 : 0x00000000 A11 : 0x3ffba868 A12 : 0x00000005 A13 : 0x00000020 A14 : 0x00000020 A15 : 0x00000000 SAR : 0x00000014 EXCCAUSE: 0x00000006 EXCVADDR: 0x00000000 LBEG : 0x4000c46c LEND : 0x4000c477 LCOUNT : 0xffffffff


Backtrace: 0x4021eb3f:0x3ffd0cb0 0x400d2dfc:0x3ffd0cd0 0x400d2f5a:0x3ffd0cf0 0x400d2d0b:0x3ffd0d10 0x400db308:0x3ffd0d30 0x400de7e0:0x3ffd0db0 0x400d3617:0x3ffd0f30 0x400fa79d:0x3ffd0f50 0x4008f3f1:0x3ffd0f70
Rebooting...

ets Jun  8 2016 00:22:57
rst:0xc (SWCPURESET),boot:0x13 (SPIFASTFLASH_BOOT)

configsip: 0, SPIWP:0xee

clkdrv:0x00,qdrv:0x00,ddrv:0x00,cs0drv:0x00,hddrv:0x00,wpdrv:0x00

mode:DIO, clock div:2

load:0x3fff0018,len:4

load:0x3fff001c,len:1044

load:0x40078000,len:8896

load:0x40080400,len:5828

entry 0x400806ac
[MSG:Grbl_ESP32 Ver 1.2a Date 20200613]

[MSG:Compiled with ESP32 SDK:v3.2.3-14-gd3e562907]

[MSG:Using machine:Cyclone PCB Factory]

[MSG:Axis count 3]

[MSG:RMT Steps]

[MSG:PWM spindle Output:2, Enbl:-1, Dir:-1, Freq:5000Hz, Res:13bits]
[MSG:Client Started]

[MSG:Connecting Principale]

[MSG:Connecting.]

[MSG:Connected with 192.168.1.75]

[MSG:Start mDNS with hostname:http://cyclone.local/]

[MSG:SSDP Started]

[MSG:HTTP Started]

[MSG:TELNET Started 23]

Grbl 1.2a ['$' for help]“

#12 – blaisebarrette 于 2020-06-14

OK, Last update before I go to bed…
I erased the flash and did a “Clean” on the ESP32 and redid every settings and it starred behaving.
Limit switches inverting as expected with the $5=1.

I can jog, control the spindle, probe etc…

The only funky things now is that it only connects over WiFi, no USB and the homing of the z axis is homing before touching the limit switch.

Looks like my setup has a bit of a temper! Hahah!

Thanks for your support!

– Blaise

#13 – blaisebarrette 于 2020-06-15

Just to let you know that everything is working perfectly. Unfortunately, I don’t really know what I did to make it work. I am not sure but I think erasing the flash on the ESP32 is what fixed it.

Remains to see how stable it will be.

Thanks for your precious help!

– Blaise

原始Issue: https://github.com/bdring/Grbl_Esp32/issues/432

评论 (13)