ESPduino, Bootup, CNC shield, Endstops

[JeffHank1]

Grbl_ESP32 Ver 1.1f Date 20200319 I am using an ESPDuino, CNC Shield and ESP32_Grbl successfully with an MPCNC, Grblgru and 4 axes. Both USB and BT work well. I soldered wires to the ESPDuino pins 15 and 32 on the board and ran them to the Shield A Step/Dir pins.

I had to change Z Limit pin to 23 (was the same as Spindle Pwm = 19) and reassigned Probe to Pin 18 instead of 39 hoping to avoid a pullup resistor since 39 is a input only type pin.

Without a Arduino CNC shield attached ESPduino boots and registers Grbl as functioning with both USB and BT connections. When the Shield is attached it usually won't start up properly and may indicate that the port is busy. If I start the ESP32 then plug in the CNC shield it runs normally (I know, this is a bad thing to do).

I have read that a repeated bootup state can be fixed by removing the resistor near the Endstops (Issue #314). However I also want to use the endstops if possible and wonder if this hardware change will take the endstop use out?

Thanks again for a great port.

[just-jason]

The resistor will not affect the endstops. It has a function to do with the Enable pin for the stepper drivers. It basically enables them permanently unless the controller says otherwise. Unfortunately the CNC shield was designed for the pin layout on the UNO and the pin used on the ESPduino for Enable is involved in the boot sequence so that the effect of the resistor stops the ESPduino from booting. This is no problem after it has been removed, your ESPduino will take care of the stepper Enable on its own.

[bdring]

If you get everything working fine can you update the machine file and add notes about the rework?

[JeffHank1]

Thanks a lot for the prompt replies.

just-jason - I removed the offending resistor and my bootup problems went away as promised. Both USB and Bluetooth boot up promptly in Grblgru and my MPCNC moves smoothly.

bdring - The changes I've made work really well. I will describe the changes below and attach my revised espduino.h file. I have used the Laser with 255 for the Spindle_PWM max limit. I don't know if the timer on Pin 19 could support a higher number, I just assumed 8 bit.

I am using a particular variety of ESP32 control board, the CANAduino. Search for:

CANADUINO WEMOS TTgo D1 R32 ESPDuino-32 WiFi Bluetooth BLE with ESP32 Dual-Core Processor I found it on both Amazon.com and Amazon.ca but this search term finds it quickly.

I described above the Pin changes I've made to get my laser, probe, and Z limit working. I added a 4th axis 'A' in the Espduino.h machine file with the Pins described above. The soldering was an easy operation. Otherwise I didn't make any changes to Barton's Pin selections. I don't used a Spindle so that frees up the Spindle Dir pins for my probe.

I've attached the espduino.h file here I hope: espduino.txt

Change the .txt to .h and paste into the machines folder to use.

I hope this is what you are looking for Bart. If more details are needed let me know.

[bdring]

Yes. Could you add a picture highlighting the exact resistor you removed to this issue? Add your name to the authors section at the top and submit a pull request. Help grow the community of contributors.

The number of bits you can use for the PWM precision depends on the frequency See this wiki page regarding precision.

TLDR: If you are using the default frequency of 5000, you could increase up to 13 bit precision.

[JeffHank1]

Here's a picture of the kind of Arduino CNC Shield I am using - before and after pictures. Either unsolder or just snip it out with pointed wire cutters. That's all that has to be done - 5 second job.

As far as Pull requests etc go, I don't know much about how that all works in Github. More learning to do. Sigh... Over to the Hello World Github page.

It sounds like I could define my Spindle_PWM to a range of 0 to 1000 easily then with $30=1000 and the firmware would scale it appropriately.

I am still having trouble convincing the Endstops to work. Traditionally Grbl prefers a NO switch however I was not able to convince those to work for XYZ Max. The Grbl feedback I get with $5=0 or $5=1 is either an alarm state or the switch doesn't trigger when challenged. Does ESP32 handle switches differently, ie preferring NC?

[JeffHank1]

A very compact arrangement on the test bench:

[bdring]

The default for Grbl_ESP32 is N.O. (close on touch) switches. Undo any changes you made to the $$ settings for the switches and check the states with the ? command. See this wiki post (testing section).

[JeffHank1]

I've got the Endstops working. Looks like this Canaduino prefers N.C. switches. (I had changed them to NO when I started with this board, they were NC, too funny)

So that solves the usual safety concern of NO switches. I guess someone was thinking ahead when designing this Canaduino Board.

I do get an axis that only moves a little then thinks it has homed but that is probably because my wiring = UTP only so I'm probably getting some interference. I will look into the endstop style that has a couple of resistors and capacitors and needs some voltage eventually. I usually don't bother with endstops but with the 4th/5th axis projects I have in mind I'll need accurate positioning in space so a functioning Homing sequence.

[bdring]

Are all switches properly reporting in the open and closed state?

[JeffHank1]

I have wired the XYZ Max switches, NC, They home correctly (up and away) and with a ? report: <Idle|WPos:0.000,0.000,0.000,0.000|FS:0,0> I am homing all to the Max position. I'll probably cannibalize one of those 3 wire Endstop switches this afternoon and try to get that to work properly. I think I just need to energize it with 3.3V and hook it to my existing endstop to cut down EM interference and false readings (I hope ha ha)

I'm working on the Probe now. This seems to register with a NO switch in my software but doesn't report a position back yet. In other words, when I start a probe function in Grblgru, the Z probe seeks down slowly, clicks at contact and retracts. All normal, but no position is fed back to the software.

[MitchBradley]

Usually, the way that Z probing works is as follows. The machine moves toward the work until the probe activates, then backs off a specified amount (ignoring the fast-then-slow cycle that gives you more precision). At that point, instead of "reporting" the current position relative to a previously-homed position, what you do is to set the work coordinate system to, say, Z=0 plus the know backoff distance. The GCode command to reestablish a new WCS is usually the last step in the probing macro.

If you have grbl configured to report machine coordinates, you could determine the probed position in machine space relative to the homed zero, but in general that is only indirectly interesting. The desired effect is the establishment of a new WCS zero.

Based on the fact that your position reports are in work coordinates (WPos:), I suspect that the distinction between machine and work coordinates could be the source of confusion.

[JeffHank1]

Thanks Mitch. It's all a mystery to me ha ha. I am using Grblgru to control things and it works well with regular Grbl and Grbl-Mega-5X. It's probe function is part of the package however he has programmed it. He is using the G38.2 function I believe. I would normally get a set of coordinates reported back point by point and be shown on a table.

They can be taken and turn into a STL for example with the click on a button

It's pretty cool actually. I can then apply a design to the virtual copy of a real bowl, create a Job in Grblgru and implement it on the real bowl. All for free! I haven't seen another program to match this.

I'm going to see if I have a few 100uf capacitors for my Endstop cables. Christian Knull (of Estlcam fame) recommends it to cut down on EM interference.

[bdring]

Here is a typical gcode sequence for a Z probe. There are other ways, but this one I feel is the most accurate.

• Send...G38.2 Z-5.0 F50 This tells Grbl to probe a maximum Z distance of -5mm at a speed of 50mm/min
• Receive...[PRB: 0.000, 0.000, -15.621] This is a typical response after touching the plate. This was the machine space location when it touched. The current location is probably a tiny bit lower due to the deceleration.
• Send...G53 G0 Z-15.621 This tells Grbl to move to the actual probe location in machine space. This corrects for the overshoot.
• Send...G10 L20 P0 Z3.00 This tells Grbl to zero the current work coordinate system (P0) to the thickness of your touch plate (3.00mm).

[JeffHank1]

I'll try it this afternoon with the Arduino IDE Serial Monitor

[bdring]

Note: The WebUI has this all built in and automates it completely.

[MitchBradley]

Ok, so I see where the disconnect is. There are two different kinds of probing. The first is intended to set up for a milling operation. You probe one point and use that as the reference Z for a milling setup. You are just looking for the top of the stock which is typically flat.

The second is where you are using the probe to make a map of an existing part whose top is not flat. That is a completely different UI situation. I'm not sure how well the WebUI handles that usage, if at all.

[bdring]

Senders that probe the surface typically post process gcode to compensate for the profile. The WebUI does not do that.

[MitchBradley]

Try sending the command "$10=1" to Grbl_ESP32 via the serial port. That will make Grbl send position reports in machine coordinates. Perhaps, after you do that, GrblGru will work correctly.

[bdring]

$# will send all of the current machine locations including the last PRB.

[G54:0.000,0.000,0.000]
[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]
[G28:0.000,0.000,0.000]
[G30:0.000,0.000,0.000]
[G92:0.000,0.000,0.000]
[TLO:0.000]
[PRB:0.000,0.000,0.000:0]

[JeffHank1]

This is with $10=0 <Run|WPos:-109.935,-144.315,-68.894,0.000|FS:100,0> <Run|WPos:-109.935,-144.315,-69.012,0.000|FS:100,0> <Run|WPos:-109.935,-144.315,-69.191,0.000|FS:100,0> [PRB:-114.935,-149.315,-74.246,0.000:1] ok

This is with $10=1 <Run|MPos:-114.935,-149.315,-74.070,0.000|FS:100,0> <Run|MPos:-114.935,-149.315,-74.155,0.000|FS:100,0> <Run|MPos:-114.935,-149.315,-74.256,0.000|FS:0,0|Pn:P> [PRB:-114.935,-149.315,-74.196,0.000:1] ok

The probe information is there, but Grblgru isn't seeing it the way it wants to : ( I may have to ask the author about that. He is currently mired in another question I asked about why my 4th/5th axis machine is not Probing properly. Poor guy. I think that one Is complicated...

I don't have any small capacitors so that endstop fix will have to wait for Mr Amazon.

[JeffHank1]

I also tried Probe with my plain bread boarded ESP32 running your 4 axis external driver machine. Probe is Pin 32 with that but G38.2 Z-5.0 F50 just made the Z axis retract up a little and nothing else. It reported a postition but it didn't make any contact via the NO switch. I don't have a resistor in that circuit. Otherwise that ESP32 board works well for movements, etc.

[bdring]

A short retract is the classic symptom of a switch already pushed. It is trying to back off to clear the switch.

Please paste the response to a ? command with Z pushed and unpushed. Both Responses Please

[JeffHank1]

Sorry to confuse things Bart. The non moving Z was with a brief experiment with a Breadboarded ESP32 (running 4x external Driver pinout) Not the Canaduino we've been discussing. I can go back to that if you like. Just a matter of swapping Stepper plugs. Let me know.

Canaduino: I also did a brief trial of switching the Probe pin back to 39 in espduino.h and reprogramming the Canaduino but that really didn't work out. I guess it still needs a Resistor and connection to 3.3V

Back to where I was a while ago with the Canaduino with Pin 18 as the Probe pin. The Z axis moves up and down normally with a Grblgru probe: Canaduino

Probe switch open <Idle|WPos:0.000,0.000,-13.316,0.000|FS:0,0|Pn:X>

Probe switch closed <Idle|WPos:0.000,0.000,-20.556,0.000|FS:0,0|Pn:PX>

$# returns: [G54:0.000,0.000,0.000,0.000] [G55:0.000,0.000,0.000,0.000] [G56:0.000,0.000,0.000,0.000] [G57:0.000,0.000,0.000,0.000] [G58:0.000,0.000,0.000,0.000] [G59:0.000,0.000,0.000,0.000] [G28:0.000,0.000,0.000,0.000] [G30:0.000,0.000,0.000,0.000] [G92:0.000,0.000,0.000,0.000] [TLO:0.000] [PRB:0.000,0.000,-18.231,0.000:1]

I did put an email to Grblgru but since he's in Germany it's nighttime...

I did find my small capacitors after an extensive search. They are in a tiny bag. I'll try those a little later to see if I can quiet the EM noise in my Endstop lines.

[JeffHank1]

I rewired my endstops with better Dupont type connectors and included a 100nF capacitor across the leads within about 8 inches of the control board. The false triggering of X and Y homing was eliminated! (I tried a capacitor near an Endstop switch just 'cause it was easier but it didn't work... Worth a try I figured)

Homing works properly now.

Since the Z and Probe are moving normally I didn't bother with them

[bdring]

Seems like you are using DIY hardware and a sender with issues. I'll step back until a Grbl_ESP32 issue comes up.

[JeffHank1]

l agree. The issues that have come up today are more my problems than ESP32 Grbl problems. Since Grblgru is much more than a sender I expected some of the problems to be in his realm. I am pleased that the small capacitors work so well with the Endstop EM issues. I'm also pleased at how painless a changeover to a CNC shield is. Simple solutions to common problems.

It seems that your Espduino machine works very well with a Canaduino varient of a ESP32. Not so experimental now I think.

If there are any firmware issues that come up with my discussions with Grblgru I will let you know. I'll also let you know if the Probe issue is resolved for that program. I will also continue to play with my Dev board ESP32 as I want to use it with another DIY machine with 5 axes.

Thanks again for a great port. Many thanks to you and Mitch for all the suggestions and education over the last couple of days.

Thanks again for a great port

[MilkLogger]

Hey guys I bought a EspDuíno (Esp32) and I want to insert it into the CNC Shield just like you do with the arduino board. I did all the GRBL-ESP32 installation procedure, it is running fine, but every time I insert the CNC Shield, ESPDuíno cuts off the wifi signal that it emits and also cuts off the USB Serial communication with the program I use to machine the pieces called bCNC. If ESPDuíno is without the Shield attached, it works, that is, it emits the wifi signal and also the bCNC shows that it is connected.

Can you help me please?

cnc shield Espduino

[JeffHank1]

Hard to say why. I didn’t have that problem. Try using Bluetooth instead of WIFI.

Good luck

On Wed, Apr 21, 2021 at 4:37 AM MilkLogger @.***> wrote:

Hey guys I bought a EspDuíno (Esp32) and I want to insert it into the CNC Shield just like you do with the arduino board. I did all the GRBL-ESP32 installation procedure, it is running fine, but every time I insert the CNC Shield, ESPDuíno cuts off the wifi signal that it emits and also cuts off the USB Serial communication with the program I use to machine the pieces called bCNC. If ESPDuíno is without the Shield attached, it works, that is, it emits the wifi signal and also the bCNC shows that it is connected.

Can you help me please?

cnc shield Espduino

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bdring/Grbl_Esp32/issues/369#issuecomment-823961342, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM2XK2RCEOZFH5GATNBJXWLTJ2TIBANCNFSM4L5FR4JQ .

-- Looking to find, Finding to know, Knowing to learn, Learning to grow, wiser. JH

[guestisp]

hi. simple question: did you notice that Y endstop is always powered by 3v3 ? X and Z endstop are set to GND, but Y not. Even forcing a PULLDOWN state in a simple test firmware, it stay UP.

Any idea ?

[antwal]

i constantly get this error in loop:

Guru Meditation Error: Core  0 panic'ed (IllegalInstruction). Exception was unhandled.
Memory dump at 0x40133c9c: 05e502ad 7ffed43b b500a9e8
Core  0 register dump:
PC      : 0x40133ca2  PS      : 0x00060d30  A0      : 0x80189f68  A1      : 0x3ffd8cc0  
A2      : 0x3ffe2a39  A3      : 0x00000018  A4      : 0x3ffd8d10  A5      : 0x0000ff00  
A6      : 0x00ff0000  A7      : 0xff000000  A8      : 0x80163fe8  A9      : 0x00000000  
A10     : 0x3ffe2a39  A11     : 0x00000018  A12     : 0x3ffd8cc0  A13     : 0x3ffd8d13  
A14     : 0x3ffc1a90  A15     : 0x3ffda25c  SAR     : 0x00000010  EXCCAUSE: 0x00000000  
EXCVADDR: 0x00000000  LBEG    : 0x4008d58d  LEND    : 0x4008d59e  LCOUNT  : 0xfffffffd  

Backtrace:0x40133c9f:0x3ffd8cc00x40189f65:0x3ffd8d00 0x4018a211:0x3ffd8d60 0x4018b247:0x3ffd8da0 0x4018d955:0x3ffd8e20 0x401e3576:0x3ffd8f00 0x401e35d9:0x3ffd8f50 0x401e5219:0x3ffd8f70 0x401e220c:0x3ffd8f90 

ELF file SHA256: 0000000000000000

Rebooting...
ets Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x33 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1184
load:0x40078000,len:12812
load:0x40080400,len:3032
entry 0x400805e4

[MitchBradley]

We are not supporting Grbl_Esp32 anymore. All of our development and support efforts have shifted to FluidNC.

[antwal]

We are not supporting Grbl_Esp32 anymore. All of our development and support efforts have shifted to FluidNC.

yes i installed fluidnc but using the same boards and shields that error is generated

[Stewie-040882]

JeffHank1 i have a simlar set up ive not implemented yet, and you may of resolved the issue by now. However, working with my 3d printer it sounds like your previous issue :

"I also tried Probe with my plain bread boarded ESP32 running your 4 axis external driver machine. Probe is Pin 32 with that but G38.2 Z-5.0 F50 just made the Z axis retract up a little and nothing else"

It is to do with the "probe limit switch" being setup as either "normally open/normally closed, HIGH/LOW". eg, if the machine is expecting a normally open switch, but is soldered in the "normally closed" position - the machine thinks it is already on the switch, and moves up to get away from the switch, but it can never get away from it as it been soldered that way, also the machine wont lower the z-axis, as it thinks its still on the switch and wont damage its self by pressing the spindle/nozzle into the bed.

You tell it to probe > Probe says "no your at 0" > Z backs off > you tell it to probe again > Probe says "your still at 0" > Z backs off again, and its a never ending cycle as its never going to be a open/closed circuit (which the system is expecting to see when it backs off)

change the probe setup to "normally open" or "normally closed" (or solder if needed) and this will hopefully fix your issue