I bought a Tom’s Robotics STM32 based CNC board (F13 – 3 axis) [Note: the jury is still out on this product, as I havn’t gotten it to work and Tom hasn’t responded yet] and finally received the MKS Servo57/42a boards (and a spare) that I blew up. I was eager to bench test it.

I physically built out the new controller in a new case that holds all the electronics for my CNC router: the CNC board and the 5v PWM to 0-10v converter for the External Brushless Spindle Controller.

Connecting to the board via the USB port and firing up my choice of CNC controller (bCNC in Python), first issue was the baud rate. By default the F13 is set to 921600 which is not a choice in bCNC. Luckily, Tom forked a copy of bCNC and updated this list of baud rates, so I was able to quickly edit the code.

Connected!

I was able to get bCNC to connect and did a few moves with it without any stepper/servos hooked up. All was looking good until bCNC stopped reporting any status or responding to commands. I was able to repeat this several times after a reset of the STM32.

I immediately suspected communications issues, but swapping cables to known good ones did not resolve it.

Is the baud rate too high? Probably not, but Tom does offer to reduce it to 115200 at ship time. I decided to reflash the STM32 with the lower baud rate. This took a bit of setup as I had the build environment is the STM32CubeIDE and the STM32 requires an ST-Link programmer/adapter. The structure of the source code of grbl32 from Tom took me a bit to figure out. It needed two symlinks for grbl and stm32 inside the cubeide directory. (I’m on a PC, so I simply moved the directories).

After a few hours, I had built and loaded grbl32 to the STM32 board with a default baud rate of 115200. More testing and…. (sad trombone) same issue.

Finally a clue…I eliminated the CNC software issue by just using trusted terminal program (PuTTY) to reproduce the problem without any other software involved. I was able to lock it up. When rebooting the STM32 via the reset button, the serial buffer output: Error: 7 just after the reboot. This is a standard GRBL error for EEPROM read failed. Reset and restored to default values. and indeed all the settings I had modified in my testing (speeds and acceleration) were reset to the defaults.

I have another STM32 on order to eliminate a bad board as the cause.

Update 01/06/2021: Tom very graciously sent me another F13 board+Black Pill which exhibited the same issue. I spent about 3 days trying everything I could think of including annotating code for better logging and poking around in the STM32 debugger. It looks like a timing issue as grbl gets confused about the queue counting method of buffer control…. it at some predictable point for a given file grbl32 fails to respond to the host with an OK and the CNC sender stops and waits to send more commands. Ultimately I needed the machine back up and running so I returned both units to Tom and he gave me a full refund. It is an awesome concept and I feel given my depth of skills I should have been able to make it work, but the truth is that it didn’t.

I went back to a cheap Sainsmart grbl 1.1f board that I had in my parts bin that is working fine and I’m building up around that. I’ll swap that out soon as it doesn’t include all the I/O needed. My real work life has picked up, so progress has slowed…. more to come.