After my last session working on this mill, we concluded that the processor on the “HF board” (which controls the spindle) was dead. I ordered a new-old-stock one from Hong Kong and it arrived this week.
Once I installed it things seemed to be responding better, so I powered down again, re-installed the heatsinks on the spindle motor driver MOSFETs and put the mill back together again. It was unresponsive again, but it turned out I had missed re-installing one internal cable during assembly. With that cable plugged in, I was able to get responses from the HF board when using a terminal program to send commands down the serial line. Furthermore, the BoardMaster program would start up properly. It even complained about the cover being open (I did not have the safety interlock switches plugged in).
But I was still unable to get it to spin up the motor or operate the tool crib. The former was likely because it did not know what tool was loaded, but the latter seemed to be getting some unexpected status back from the mill.
The BoardMaster program has an option to trace its serial line to a log file, but I am now quite suspicious of this file’s contents. For one thing, it does not include response data returning from the mill, making it less than ideal for diagnosing problems. Furthermore, at least half the commands I see being sent in the log file are rejected as erroneous if I try typing them directly via a terminal program. They are also not listed in the (albeit limited) documentation for the command set, and one of them does not even follow the overall format for their commands.
I have a strong suspicion that the program has another layer which translates these commands I am seeing in the log file into other commands. Next time I will try using a serial port sniffer program to find out what is really being sent and received on the line.