Would anyone have any experience on using a cnc shield v3 with esp32 board and using a limit switch? Seems like motors are nice but with limit/end switches calibration could be a lot easier. There seem dedicated ports on the cnc shield for these switches (which makes sense), did anyone ever try these and integrate them into uc2-rest?
Many thanks
Hey Tom, thanks for reaching out again. Indeed there is a function that is called home which can move the motor in a certain direction with an unstop with certain polarity which is then reversing the direction when it reaches the end stop and then stopping when it’s free again footstep I’m walking right now but there is a documentation in the firmware. You should look for home_act this is possible for access one two three. There’s a funny back in the fastl stepper motor library which may cause random direction changes when call for the first time, but in principle it should work
Thanks! I found the code, motor starts homing! But how should I wire the end switch on a CNC shield v3? I am trying this:
Many thanks for the help!
Oh, interesting. I’ve never tried the CNC shield - actually it’S the other firmware
const int PIN_DEF_END_X = GPIO_NUM_13;
const int PIN_DEF_END_Y = GPIO_NUM_5;
const int PIN_DEF_END_Z = GPIO_NUM_23;
If those are the ones from the endstops, it should be ok. You would need to use pull-ups since the internal ones behave weirdly if I’m not mistaking
Hello again, I finally had some time to test.
So the gpio pins from the cnc shield to the esp32 correspond to the arduino equivalent used in the code, so that should be okay. I am using a pull-up configuration but can’t seem to get it working.
Using ESP32.home.home_x(speed=500) start homing, but does not respond to any of the ports. I tried both 3 way and 2 way switches, the common connected to ground, and the NO connected to a 10k resistor which is connected to the cnc shield 5V and before the resistor to X+ (which should be connected to the gpio pin). I tried both X-, X+, Y- etc, but it does not respond. I also tried connecting to X+ and GND through the switch but that also does not respond. Am I missing something?
Many thanks again for the assistance.
can you try this page openUC2 WebSERIAL Demonstration and paste the following line (after connecting to the board):
{"task":"/digitalin_get"}
By changing the pins and polling the result, you should see a variation in its response from 0…1
I must admit that the firmware available through openUC2 WebSERIAL Demonstration for the WEMOS is already fairly old. I could initiate a rebuild - should work without major complications, but i haven’T used this PCB for a while now. We only use our UC2v3 PCBs provided by @christiankuttke
Thank you for the speedy response I understand that you use the uc2v3 boards.
Using the command prints:
{“task”:“/digitalin_get”}
++
{
“qid”: 0,
“success”: 1
}
–
It prints the same output if I press the limit switch for all inputs. Does this listen to all gpio pins? I don’t think I fully understand, what it is supposed to do, shouldn’t this print specific information per GPIO pin?
There is a new firmware based on the latest development for the WEMOS pinout .Can you check waht {“task”: “/state_get”} and the digital_in gives?
Thanks!
Flash it via youseetoo.github.io => WEMOS … Thanks
Thanks for making these changes so fast!
But this is now the output after reflashing:
{“task”: “/state_get”}
++{“error”:“Serial input is null”}–
{“task”:“/digitalin_get”}
++{“error”:“Serial input is null”}–
What’s happening if you hit the button?
I think I have to change the " and not copy them from the forum. Otherwise it keeps giving me the serial input is null code.
{“task”: “/state_get”}
++
{“state”:{“identifier_name”:“UC2_Feather”,“identifier_id”:“V2.0”,“identifier_date”:“Mar 3 202514:01:21”,“identifier_author”:“BD”,“IDENTIFIER_NAME”:“uc2-esp”,“configIsSet”:0,“pindef”:“UC2_WEMOS”,“I2C_SLAVE”:0},“qid”:0}
–
For the other command it gives me:
{“task”:“/digitalin_get”}
Guru Meditation Error: Core 1 panic’ed (LoadProhibited). Exception was unhandled.
Core 1 register dump:
PC : 0x400d4659 PS : 0x00060930 A0 : 0x800d26f8 A1 : 0x3ffd4970
A2 : 0x3ffb7ec0 A3 : 0x3f403054 A4 : 0x3f4043b5 A5 : 0x0000ff00
A6 : 0x3ffd2a10 A7 : 0x40404040 A8 : 0x800d4659 A9 : 0x3ffd4950
A10 : 0x00000000 A11 : 0x3f4043b5 A12 : 0x00060620 A13 : 0x3ff96355
A14 : 0x3ffb7ec0 A15 : 0x00000000 SAR : 0x0000001a EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000014 LBEG : 0x400012c5 LEND : 0x400012d5 LCOUNT : 0xfffffff0
…
But I don’t see a difference between button presses (considering that it requests something from a memory location that is not there, it would be weird if it could find something?)
Can you try this?
{"task": "/digitalin_get", "digitalinid":1}
Tested for id 1 to 8, and for X-, X+ etc, but all the same output value of 0:
++
{“digitalin”:{“digitalinid”:1,“digitalinval”:0}}
–
Edit: I tested with a UC2 (I think V2) board, and homing works there, same setup. So I can switch to one of these boards if needed.
The pinconfig is the following:
#pragma once
#include "Arduino.h"
#include "PinConfigDefault.h"
struct UC2_WEMOS : PinConfig // also used for cellSTORM wellplateformat
{
/*#define MOTOR_CONTROLLER
#define BLUETOOTH
#define PSXCONTROLLER
#define WIFI
#define LED_CONTROLLER
#define HOME_MOTOR
#define LASER_CONTROLLER*/
const char *pindefName = "UC2_WEMOS";
// ESP32-WEMOS D1 R32
int8_t MOTOR_A_DIR = GPIO_NUM_23; // Bridge from Endstop Z to Motor A (GPIO_NUM_23)
int8_t MOTOR_X_DIR = GPIO_NUM_16;
int8_t MOTOR_Y_DIR = GPIO_NUM_27;
int8_t MOTOR_Z_DIR = GPIO_NUM_14;
int8_t MOTOR_A_STEP = GPIO_NUM_5; // Bridge from Endstop Y to Motor A (GPIO_NUM_5)
int8_t MOTOR_X_STEP = GPIO_NUM_26;
int8_t MOTOR_Y_STEP = GPIO_NUM_25;
int8_t MOTOR_Z_STEP = GPIO_NUM_17;
int8_t MOTOR_ENABLE = GPIO_NUM_12;
bool MOTOR_ENABLE_INVERTED = true;
int8_t LASER_1 = GPIO_NUM_18; // WEMOS_D1_R32_SPINDLE_ENABLE_PIN
int8_t LASER_2 = GPIO_NUM_19; // WEMOS_D1_R32_SPINDLEPWMPIN
int8_t LASER_3 = GPIO_NUM_13; // WEMOS_D1_R32_X_LIMIT_PIN
int8_t LED_PIN = GPIO_NUM_4;
int8_t LED_COUNT = 64;
const char *PSX_MAC = "1a:2b:3c:01:01:03";
int8_t PSX_CONTROLLER_TYPE = 2;
int8_t JOYSTICK_SPEED_MULTIPLIER = 5;
int8_t JOYSTICK_SPEED_MULTIPLIER_Z = 3;
const char *mSSID = "Blynk";
const char *mPWD = "12345678";
bool mAP = false;
};
const UC2_WEMOS pinConfig;
so that means its actually not activated 
I’ll do that now
can you confirm it’s
// Additional Digital Input Pins
int8_t DIGITAL_IN_1 = -1; // Disabled
int8_t DIGITAL_IN_2 = GPIO_NUM_36; // VP on ESP32
int8_t DIGITAL_IN_3 = GPIO_NUM_39; // VN on ESP32
on the ESP32 Wemos D1? You can trace the contacts with a multimeter I suppose
LimX is on GPIO_NUM_13
LimY is on GPIO_NUM_5
LimZ is on GPIO_NUM_23
gpio_36 is analog and connected on the shield to scl and 39 to sda. Or do I not understand the question?
Yes now I understand VP is 36 and VN is 39 on the chip.
Ah, true. Thanks! I’ll bake this in and rebuild now. Give it 10 minutes and you can reflash
Many thanks for the help, appreciated!