Can't compile for Corexy

[marshr32]

I've managed to get most of the way through the build but it stops at the end saying c:\esp\esp-idf\esp32\build/../main/grbl/grbllib.c:220: undefined reference to `corexy_init'

I've got no idea how to fix this....... help!

[terjeio]

Add grbl/corexy.c to this file list in CMakeLists.txt.

[marshr32]

Thanks terjeio, I'll give that a go. Should it be in that list by default?

While we're talking about that same list, I had an issue with it asking for networking/strutils.c when I didn't have any networking options turned ON. Had to download the network plugin and add that file even though I'm not gonna use it.

I followed the git instructions but it didn't pull this plugin.

The only things I have ON are "Compile for ESPDUINO-32 Wemos D1 R32" and "Safety door enable", so is needing the network plugin to compile normal?

[terjeio]

Should it be in that list by default?

Yes it should, I'll add it in the next commit.

I followed the git instructions but it didn't pull this plugin.

It should pull the networking plugin so something must have failed on your side.

[marshr32]

Thanks for the help terjeio. No doubt I did something wrong with the git pull as I'm completely new to this.

So I added grbl/corexy.c after grbl/ioports.c per your first reply and got the message below.

As it says to include I added it into corexy.c at the start:

include

include "grbl.h"

This got me down to just

I tried initializing b_steps on it's own on a new line in corexy.c, but got the same message. Now I'm stuck again.

I'm using ESP-IDF 4.4.1 if that makes any difference? through powershell.

[marshr32]

Just to make sure I'm not doing this the hard way for no reason...... Can I use Arduino IDE for this? As per https://github.com/grblHAL/core/wiki/Compiling-GrblHAL

I did try and there is no example folder, Am I missing something?

[terjeio]

Change this line to

target_compile_options("${COMPONENT_LIB}" PRIVATE -Wimplicit-fallthrough=1 -Wno-missing-field-initializers -Wno-maybe-uninitialized)

Can I use Arduino IDE for this?

No, not without changes.

[marshr32]

It now appears to compile OK and flash OK using the command given:

But when I try run IOsender with it connected (even after unplugging to reset):

I tried the IDF monitor to see what response I'd get, dunno if it's any help for you?

[terjeio]

It seems you have enabled backlash compensation which is not compatible with corexy. There should be a compiler error for that - as backlash compensation may be hard to add for corexy?

[marshr32]

I do have backlash comp enabled, in fact that was the whole reason for doing this upgrade from my Arduino...... Bummer! I'll try again with it turned off just to see if I can at least get it working.

Do you know why backlash comp isn't compatible with corexy? My "programming skills" won't let me read the code to find out exactly how it's applied to a normal machine but I believe the principle is "if an axis reverses then add the BC distance before the next Gcode move". Could this be modified for a corexy setup to say "calculate if the next move will cause a MOTOR to reverse, if so add the BC distance to that motor's move"?

[marshr32]

BTW if this is not the best place to discuss the backlash comp, then feel free to redirect me to somewhere better suited. I couldn't find any grblHAL forums etc.

[terjeio]

Do you know why backlash comp isn't compatible with corexy?

After taking a look at the code again I guess so. Currently the kinematics transform is done after backlash handling - it has to be done before. So code changes are required.

[marshr32]

Thinking about this still..... Grbl knows when the motors have to change direction as it has to set the DIR output, could the backlash comp be incorporated with that? Every time the DIR pin changes state, add the compensation.

[terjeio]

Every time the DIR pin changes state, add the compensation.

This is how it is done - and the compensation has to pass through the planner to be handled correctly (acceleration, distance to step conversion ...).

[marshr32]

Interesting, wouldn't the kinematic transform have to be done before you'd know when the DIR pin would be high or low? Therefore backlash comp should be just as compatible with corexy as any other kinematics?

[terjeio]

Please report back if backlash compensation works with the lates commit.

[marshr32]

Cool, I'll let you know. It'll probably be a while till I get to work on it though.

[marshr32]

Hi Terje, I tried again yesterday with the latest commit, and it pulled all the submodules this time.

However even though it appeared to build and flash correctly, IOsender still won't connect. I get the same error as above.

Any idea what could be wrong?

Have attached a snippet from the end of the build and flash process, dunno if that's helpful or not. ESP32 build.txt .

[terjeio]

My bad - I have just uploaded another fix. Sorry for that.

[marshr32]

Hi Terje, no apologies needed!

So the upload works this time but there are still errors when trying to communicate . I also tried comms over the arduino serial monitor. $ gets me this: <Alarm:11|MPos:0.000,0.000,0.000|Bf:35,1000|FS:0,0|Pn:XYZRH|WCO:0.000,0.000,0.000|WCS:G54|A:|Sc:|H:0|T:0|TLR:0|FW:grblHAL> [GC:G0 G54 G17 G21 G90 G94 G49 G98 G50 M5 M9 T0 F0 S0.] error:9 error:52 [HLP:$$ $# $G $I $N $x=val $Nx=line $J=line $SLP $C $X $H $B ~ ! ? ctrl-x] ok

$$ will list the parameters but I can't change anything, $14=78 just gets me error:52 again.

What am I doing wrong? Thanks, Mike.

[marshr32]

Playing some more in Arduino serial monitor, I can set $14= anything up to 7, but not 8 or higher (error:52)

$I gives [VER:1.1f.20220710:] [OPT:VNCPZTSR,35,1024,3,0] [NEWOPT:ENUMS,RT+,HOME,TC,SED] [FIRMWARE:grblHAL] [NVS STORAGE:*FLASH] [DRIVER:ESP32] [DRIVER VERSION:220710] [DRIVER OPTIONS:v4.4.1] [BOARD:ESPDUINO-32 Wemos D1 R32] [KINEMATICS:CoreXY v2.00] ok

[marshr32]

Just noticed this in the Additional settings wiki: Bits 4 - 7 cannot be set with $14 when COMPATIBILITY_LEVEL > 1 or the driver does not support the input.

This would match with only being able to set up to $14=7, but my compatibility is still set at 0, and I've no idea if the driver supports it or not.

[marshr32]

OK I'm getting somewhere, but there is some weird stuff is going on here. With Feed Hold and Reset (E Stop) pins grounded, and cycle start open, if I set $14=4 to invert the cycle start pin to expect an NO connection I get an error for cycle start (using UGS as IOsender won't connect). If I put $14=0 and still have the pin open then it's fine. Shouldn't this be equivalent to holding the start button continuously?

UGS is still throwing a heap of errors about the response from the controller, but it doesn't shut down because of it.

[terjeio]

if I set $14=4 to invert the cycle start pin to expect an NO connection I get an error for cycle start

An error generated by UGS?

using UGS as IOsender won't connect

ioSender connects but fails due to wrong response from the controller. Try connecting with Toggle RTS selected as this shoud reset the ESP32. You may also try the latest edge version of ioSender.

If I put $14=0 and still have the pin open then it's fine. Shouldn't this be equivalent to holding the start button continuously?

Yes. But it does not matter since the start button only generates start events on a pin state change.

UGS is still throwing a heap of errors about the response from the controller, but it doesn't shut down because of it.

It does not for me - could it be due to you having enabled additional elements in the real-time report with $10?

[marshr32]

An error generated by UGS?

When I said error, I should have put alarm. But this alarm is constant, not like it's only looking at a state change.

ioSender connects but fails due to wrong response from the controller. Try connecting with Toggle RTS selected as this shoud reset the ESP32. You may also try the latest edge version of ioSender.

I tried the edge version with Toggle RTS and it seemed to connect with no errors. So I closed it and tried my older version, which also now worked. Then I tried to go back to edge version and now I'm getting these weird errors from both versions, and deleting the config file to start again doesn't seem to help.

UGS is still throwing a heap of errors about the response from the controller, but it doesn't shut down because of it.

It does not for me - could it be due to you having enabled additional elements in the real-time report with $10?

These are the errors in UGS, the number climbs and drops for a while then goes to 0, then I can do something. $10=511 I don't know why as I've not changed anything there.

[marshr32]

This is in /grbl/config.h as cloned

// After homing, Grbl will set by default the entire machine space into negative space, as is typical // for professional CNC machines, regardless of where the limit switches are located. Set this // define to 1 to force Grbl to always set the machine origin at the homed location despite switch orientation. //#define HOMING_FORCE_SET_ORIGIN // Default disabled. Uncomment to enable.

define HOMING_FORCE_SET_ORIGIN 1

Is this enabled or disabled when set like this? it kinda seems like both?

[terjeio]

When I said error, I should have put alarm. But this alarm is constant, not like it's only looking at a state change.

It looks like that the red alarm box is same as the Signals box in ioSender. Perhaps UGS should have used Alert as the label instead of Alarm to avoid ambiguity with real grbl alarms.

These are the errors in UGS, the number climbs and drops for a while then goes to 0, then I can do something.

I do not get the 52 errors when connecting. If $22 is et to enable Homing on startup required I get 3 errors, none when disabled (UGS 2.0.11).

I have to check what the ESP32 is outputting to make ioSender crash - the meditating guru present in this chip can drive one crazy with all its antics...

[terjeio]

I have changed the latest ioSender edge version a bit, this performs a number of retries on startup if unexpected responses are encountered.

What is a bit odd is that startup failed after a previous connection with UGS, perhaps due to UGS leaving the serial interface in a state where characters are left in an ouput buffer?

[marshr32]

I have to check what the ESP32 is outputting to make ioSender crash - the meditating guru present in this chip can drive one crazy with all its antics...

Haha are they that bad? I'm beginning to think that I should have just gone with a teensy, but the espduino is a plug in fit to my router.

[marshr32]

It looks like my espduino is just sending back a heap of rubbish on the comms and overwhelming the sender. I tried to switch to check mode in ugs and it went up over 200 errors! I'm away for a few days now but will try the new edge version when I get back, on a freshly restarted pc before anything else uses the com port.

[marshr32]

Ok, trying this again and still no real luck.

IOsender 2.0.40 will start up with no problems now but it's very finnicky about inputs. Is it possible to make it so that it doesn't automatically exit for random "errors" all the time? I've had this for the below situation, and for a "check door" situation too. Killing the program when I just try to pause isn't great.

IOsender won't bring up the GRBL settings. I have to use UGS to change them, then come back to IOsender to try things.

The ESpduino is also ignoring the reset/abort input (IO2) no matter if its grounded or open. This is the Estop pin, correct?

[marshr32]

Oh, and this is all with $10=25

[terjeio]

Do you have electrical interference triggering the reset input?

The ESpduino is also ignoring the reset/abort input (IO2) no matter if its grounded or open. This is the Estop pin, correct?

No, it is the reset input (the R "LED"). It can be used as estop input by changing code but this driver does not have this option yet. If not reacting to the input then something is amiss... If you have a voltmeter then check the level at the pin on the processor board to see if it changes with switch state.

[marshr32]

It shouldn't be electrical interference, as it's just sitting on my computer desk, but who knows. Being hard wired to GND there shouldn't be any interference possible?

The RST pin in the ESPduino-32 board (not the ESP chip itself) is sitting at about 4V and goes to 0V when I push the reset button on the corner of the board. This RST pin is connected to the EN input on the ESP chip. At the same time IO2 goes from 0.075V to 0V, and there is continuity between IO2 and pin 24 on the ESP32 chip (GPIO2). Should this be sitting at 5V (4V?) when not connected to anything?

Which pin would be used as Estop on this board? Hold (IO4) comes to a controlled stop so is not suitable in this case.

[terjeio]

Being hard wired to GND there shouldn't be any interference possible?

Correct.

The RST pin in the ESPduino-32 board (not the ESP chip itself) is sitting at about 4V and goes to 0V when I push the reset button

This should be 3.3V according to the schematics, is the regulator broken? The ESP32 is a 3.3V chip.

At the same time IO2 goes from 0.075V to 0V, and there is continuity between IO2 and pin 24 on the ESP32 chip (GPIO2). Should this be sitting at 5V (4V?) when not connected to anything?

It should be sitting at 3.3V if $17=0 and the correct map file is used. Use the $pins command to check.

Which pin would be used as Estop on this board?

Pin 2 ("soft" reset). I have not added code (and option) to remap the pin to the internal EStop signal yet as I have done for a few other drivers.

[marshr32]

Ah yeah, it is a 3.3V chip, which makes the 4V reading super weird! 3.3V and 5V rails are reading correctly though, and I've never powered it with anything other than USB.

When I jump IO2 to 3.3V I get the soft reset alarm in the sender and the blue LED on the board. So it seems like the pull up resistor is broken/not correct, or the LED circuit is pulling the pin down to 0.075V but without enough current to light the LED.

Maybe I should remap this input to IO36 or something?

$17=0 and $pins gives the following response over 50 times. [PIN:2,Reset] [PIN:4,Feed hold] [PIN:35,Cycle start] [PIN:39,Probe] [PIN:13,X limit min] [PIN:5,Y limit min] [PIN:23,Z limit min] [PIN:26,X step] [PIN:25,Y step] [PIN:17,Z step] [PIN:12,Steppers enable] [PIN:18,Spindle on] [PIN:32,Flood] [PIN:16,X dir] [PIN:27,Y dir] [PIN:14,Z dir] [PIN:34,RX,Primary UART] [PIN:35,TX,Primary UART] [PIN:19,Spindle PWM] [Error] Error while processing response : An unexpected command was completed by the controller.

It's like everything is just being repeated so many times, when I start it I get so many repetitions of the $$ output (GRBL settings)

Other people have gotten this to work, right? Maybe I've just been supplied a bad ESPduino, I've seen it before with arduinos.

Sorry this has turned into such a mission, and thank you for your help.

[marshr32]

Interestingly, device manager says this board has an FTDI chip not a CH340 like the schematic. I tried updating the FTDI driver, no luck. I even tried to force the CH340 driver on it, but that crashed the PC

[terjeio]

or the LED circuit is pulling the pin down to 0.075V

Try removing R10?

Maybe I should remap this input to IO36 or something?

Be aware that some of the higher numbered GPIOs do not have internal pullups available.

Other people have gotten this to work, right?

It works for me with a "standard" ESP32 board. AFAIKT other users are using this driver as well.

Maybe I've just been supplied a bad ESPduino, I've seen it before with arduinos.

Well, the whole ESP32 ecosystem seems a bit flaky to me - I am no great fan of it.

[terjeio]

Interestingly, device manager says this board has an FTDI chip not a CH340 like the schematic.

A fake/cloned FTDI chip? Contact the supplier of the board to get a working driver?