Try this binary. A and Z limit switches has to be connected in series or parallell depending on the type (NC or NO).
I connected the A and Z limit switches in parallel and hooked them in the Z-limit port in the X32 controller. Flash the firmware with the new binary, re-configure grblhal for my machine and... it worked! Thanks you so much @Peter Van Der Walt and @terjeio!
Next step is to try to run some gcode and see how it behaves (just dry runs for now). I'm planning to use Profili Pro 2 to generate the gcode to cut wing cores. I know it's been discontinued for a while now, and replaced by devFoam2, but that's what I have. I might consider upgrading if I can't get it to work properly. Stay tuned!
@terjeio, will this change (hack) to the source code be merged permanently to grblhal? @Peter Van Der Walt, will this new binary be available (embeded) in OpenBuilds Control and available (as an option) to flash the firmware?
Yes it will get merged (see auto Square issue · Issue #64 · grblHAL/ESP32) and you are helping with the testing before it does At this time we advise people to use Web Builder for latest-latest firmware. Builds in CONTROL are older. On a different project at the moment but when we get allocated time to work on CONTROL again, there is plans to integrate Web Builder directly so users can customize at will and have the latest code too. Same as using Web Builder in essence, just in the wizard. Two extra clicks gets you that already
Great plans! Can't wait. Looks like there's a lot work ahead. I noticed that the wifi portion was left off in the new experimental firmware. I'm OK with this for now, but I like the idea of ditching the hard connection with the computer (although I'm sure some people think this is a no-no).
I generated a gcode file and did a dry run and it all went good! I have one more question. What do I need to add to the gcode header to perform the homing routine and set that as zero?
I looked it up a bit and my understanding is that you cannot add auto homing into the gcode header with grbl. I thought you could do as you do with a 3D printer running Marlin, where you send an auto home code (G28). I guess the equivalent with grbl is to run manually $H, then G28.1 and then run your gcode file.
When you home, you are setting the zero point in the Machine Coordinate System. The thing about a 3D printer is that the tool head never changes so the Z zero in the Work Coordinates System never changes. If you just ran a homing sequence and started cutting, the machine would not know how long your end mill was, how thick your material is, how it is clamped/fastened down, or where your work stock is located on the machines work surface. Therefore there are two coordinate systems in play. You home the machine after turning it on so it can find the Machine Coordinate System XYZ zero point. From there it knows the boundary of our machine if you have soft limits active. You then have to set your Work Coordinate System XYZ Zero manually once you figure out where you plan to do the cutting on your piece.
Thanks for the detailed explanation @Giarc ! My foam cutter has a fixed toolhead and the piece of foam I’m cutting will always be located at the same location (it’s bottom left corner). Thickness may vary, but all those parameters are set in the gcode generating software. I guess it’s another type of specialized CNC machine like a 3D-printer. That why I thought I could just add both MCS and WCS in the header of my gcode (because they’ll always be the same). But now I realize that this is not how grbl was designed and you explained to me very well why that is. It’s for flexibility (and safety) purposes. I’m glad I’m (slowly) learning all that stuff. Having to build a custom machine forced me to dive in into all the settings. And the support I’m getting from the OpenBuilds team is amazing!
