Only one motor per axis moving about grbl_esp32_mpcnc_controller HOT 17 CLOSED

OK, I am happy to help in real time via Slack as well.

from grbl_esp32_mpcnc_controller.

My first guess is you are using the wrong cpu_map. You need to use CPU_MAP_MPCNC.

See this page about that.

from grbl_esp32_mpcnc_controller.

Thanks for he quick reply. I unfortunately followed those instructions when I recompiled the firmware.

from grbl_esp32_mpcnc_controller.

I just checked the latest firmware to make sure there are no issues no issues crept in recent updates.

It works fine for me. Can you double check all to solder joints?

You could try swapping the pins in cpu_map.h on the x axis motors to see if it is a firmware or hardware issue, like this....

#define X_STEP_PIN GPIO_NUM_22 // was GPIO_NUM_12
#define X_STEP_B_PIN GPIO_NUM_12 // was GPIO_NUM_22

If only one motors spins, but it is now the other one, it would appear to be a firmware issue.
If the same motors as before spins, it is likely a hardware issue.

from grbl_esp32_mpcnc_controller.

That's a good idea, I will try that when I get home today.

from grbl_esp32_mpcnc_controller.

So I have reconfigured the pins and uploaded the firmware like you suggested. I checked before and after and both times the same motor moved.

Here is the relevant code

config.h

#ifndef config_h
#define config_h
#include "grbl.h" // For Arduino IDE compatibility.

//#define ESP_DEBUG

// Define CPU pin map and default settings.
// NOTE: OEMs can avoid the need to maintain/update the defaults.h and cpu_map.h files and use only
// one configuration file by placing their specific defaults and pin map at the bottom of this file.
// If doing so, simply comment out these two defines and see instructions below.
#define DEFAULTS_GENERIC

//#define CPU_MAP_ESP32 // these are defined in cpu_map.h
#define CPU_MAP_MPCNC

#define VERBOSE_HELP // adds addition help info, but could confuse some senders

cpu_map.h

#define USE_GANGED_AXES // allow two motors on an axis 
	  
//#define X_STEP_PIN      GPIO_NUM_12
//#define X_STEP_B_PIN    GPIO_NUM_22	 // ganged motor
#define X_STEP_PIN GPIO_NUM_22 // was GPIO_NUM_12
#define X_STEP_B_PIN GPIO_NUM_12 // was GPIO_NUM_22

#define X_AXIS_SQUARING

I have also confirmed the the other motor works if i swap them as well as the drivers. The soldering looks well done, you sent a really nice board. I am not sure what is going on.

from grbl_esp32_mpcnc_controller.

Thanks for doing that. It helps narrow things down. Does the non moving motor lock (resist manual turning) when the other motor moves?

Make sure $1=255 to keep it locked.

from grbl_esp32_mpcnc_controller.

Ok so interesting results. I verified $1 == 255. I also unplugged the good motors and told the board to move the X and Y axis. Like usual I got no movement but I can verify the other motors are energised. I am able to move them by hand but they have significant resistance compared to the unplugged motors and you can feel the skipping steps when you force them.

from grbl_esp32_mpcnc_controller.

I wrote a test program that stepped gpio 22 and it would spin the motor attached just fine. When I change it to pin 12, it does not.

from grbl_esp32_mpcnc_controller.

Do you have a volt meter? Can you slowly toggle the pins while looking at the pins? Measure at the ESP32 and the motor driver

You could have some dead pins on the ESP32. Is there a chance a motor driver was ever installed backwards or off a pin? Was the ESP32 ever used on another project?

from grbl_esp32_mpcnc_controller.

I got the ESP32 with the board so I assume it was new. I also made sure I put the drivers in properly each time.

I'll try to measure the voltage in a bit and let you know how it works. I was also thinking I might grab one of my ramps boards and jumper the step and direction pins to the grbl board. That should also tell us if it's the ESP32 or not.

from grbl_esp32_mpcnc_controller.

I found the issue. These 2 rows of pins are supposed to be connected, but I found an open circuit between these 2.

Here is the Gerber

I am not sure how this happened, but I probably made a mistake somewhere at the last revision when I made the gerber files.

I have been testing using the narrower ESP32 and assumed the connections were OK.

If you could solder a wire vertically between the pins, that should fix it. I can replace the board with a repaired board if you would rather have me do it.

from grbl_esp32_mpcnc_controller.

Removing the ESP32 seems to have killed it, it no longer registers as a device in my system so I am unable to access it. I'll have to use another board like my ramps to test out the carrier board.

from grbl_esp32_mpcnc_controller.

Ok, I'll confirm the open traces and fix them on my board. I'll then carry on with my test to verify.

Good find.

from grbl_esp32_mpcnc_controller.

I decided to run the ESP32 under my hot air reflow and it fixed whatever bad connection there was so we are back in business.

I reflashed the firmware onto the ESP32 and then added the soldering bridges as you said. Plugged the ESP32 back into the board and powered it all up. The light comes on but no web interface or serial data on the monitor. If I take the ESP32 out of the carrier board I can get the web interface and serial data on the monitor but the moment I plug it into the carrier again, nothing.

I went ahead and removed the solder bridges that I made but now I am having the same issue again where I can't get the web interface or data on the serial monitor. Interestingly though, I get this error when trying to flash the ESP32 in the carrier:

Changing baud rate to 512000
Changed.
Configuring flash size...
Warning: Could not auto-detect Flash size (FlashID=0xffffff, SizeID=0xff), defaulting to 4MB
Compressed 16848 bytes to 10928...

A fatal error occurred: Timed out waiting for packet content

Searching Warning: Could not auto-detect Flash size brought me to this answer on another issue espressif/esptool#305 (comment)

Apparently GPIO12 can cause issues with the internal flash if it is pulled high. I can't see any reason it should be high and I have re-soldered all the pins on the carrier board to make sure there is no short but I still can't get it to run properly on the carrier board any more.

here is the flashing working when pulled out of the carrier board for reference

Changing baud rate to 512000
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 16848 bytes to 10928...
Wrote 16848 bytes (10928 compressed) at 0x00001000 in 0.2 seconds (effective 575.5 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 143...
Wrote 3072 bytes (143 compressed) at 0x00008000 in 0.0 seconds (effective 3225.7 kbit/s)...
Hash of data verified.
Compressed 8192 bytes to 47...
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.0 seconds (effective 11874.8 kbit/s)...
Hash of data verified.
Compressed 1778384 bytes to 1055467...
Wrote 1778384 bytes (1055467 compressed) at 0x00010000 in 23.0 seconds (effective 618.6 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

from grbl_esp32_mpcnc_controller.

I have done dozens of ESP32 projects using both the narrow and wide version.

With the narrow version I almost always get the issue where I have to hold the boot button to load firmware.

With the wide version, I never have to hold the boot button, but I have seen the issue where it won't program in the socket, but runs fine.

I prefer the wide version because the problem is rare and I tend to wirelessly upload firmware after the first load. I always do the first load out of the socket for IO safety.

The wide version also does not have the LED on IO2 which makes that pin easier to use.

from grbl_esp32_mpcnc_controller.

Ok I'll have to order a new ESP32 DEVKITC V4 module then. It just will not run in the board any more. I guess we can close this and I'll open a new issue if the new ESP32 gets here and has the same issue.

from grbl_esp32_mpcnc_controller.