We now have a three-axis machine: aged but still robust industrial motion control linear drives for our X and Y axis, and a new but not at all robust servo holding a Sharpie marker as our Z-axis. It was enough to let us feed three-axis G-code programs and watch them in action.
We started with short programs that would take less than a minute to run, then gradually increased the complexity and duration of jobs. If we wanted to turn this into a CNC mill, it will need to be reliable and dependable for long jobs. We didn’t have enough experience to have a list of potential points of failure, we just ran ever longer jobs and watched to see what goes wrong. We knew it was going to be a process of finding a problem, fixing it, finding the next thing to fail, fix that too, and repeat.
Our first problem: the G-code sender UGS running on the control console laptop. In the middle of running a job of approximately 15 minutes, UGS would drop serial connection. The machine stops moving and UI shows “OFF-LINE”. This is not just annoying, it is plainly unacceptable in a machine that might be expected to run for hours.
And there’s another possibly related problem with UGS serial communication: it was not able to connect to Grbl ESP32 if the dev board was connected at boot. We could work around this by unplugging the USB cable to ESP32 and reconnect, but this is rather inconvenient.
We could put up with the startup connection issue if that was the only problem, but randomly halting in the middle of a long job is unacceptable. So UGS is out of contention, and we return to the Grbl G-code sender list to find a replacement.
The next candidate: bCNC.