Kwartzlab Radio Episode 6

Enjoy!

Kwartzlab Radio Episode 5

Dev House Google Group

Kwartzlab Radio Episode 4

Enjoy!

Enjoy!

Kwartzlab Radio Episode 3

Kwartzlab Radio Episode 2

In the first episode Darcy Casselman and I talk about the formation, culture and history behind kwartzlab.

Kwartzlab Radio Episode 1

The epiphany relates to the relationship between the various microswitches (sensing open covers, tool crib position, and presence of an adequate supply of compressed air) and the value read from “register 6″ on the HF board. When I had been manually sending read commands for this register while actuating the various switches, I at first started jotting down numbers like 0226C, which seemed to map the switches combinatorially, as if the register was returning some interpreted status rather than just 5 bits for 5 switches. Eventually I realized that the ‘C’ was just the command-completion letter, returned by the mill after completion of each command, but values like 0x236 still made no sense. The epiphany was to realize that the ‘C’ had got me thinking the number was hexadecimal, and that mindset remained even after realizing the ‘C’ was not part of the number.
Interpreting the results of the read-register operation as decimal values makes much more sense: the 5 lower bits map to the 5 switches, while the upper three bits are always on (as their inputs are unconnected other than a pullup resistor). So a value like 226 (0xE2) shows the three stuck bits and one microswitch open.

Other that that, not much has been determined. Tonight we looked into whether there was some other switch or interlock that was missing; this might explain the error message that we “had attempted to stop” the tool change. We traced the wiring from the header on the HF board to the known switches and solenoids, but found no place where some other switch might have been connected.

Maybe next week we will try just grounding the other three input lines to see if this makes any difference.

I still find it suspicious that the last command issued before the error message is a read of register 5 (not 6), which returns a zero value. Register 5 at the CPU level is the output bank used to drive the tool crib solenoids. The external wiring of these CPU pins does not provide for any input, so the value read would be whatever the CPU wrote to the solenoids. That just seems to be a strange thing to do… Perhaps some of the bits in this register have been programmed for their special purpose rather than GPIO. I will have to look at the processor documentation to see what special purposes these bits can have.

We haven’t really got the mill any closer to working but we have more specific symptoms. One is that, when we ask BoardMaster to change tools, we get the error:

You have attempted to stop the tool exchange procedure. Task is aborted!

I have not been able to get any information online concerning this message, but the serial trace reveals that the last command sent to the mill was !RD5 for the HF board (which means Read Port 5), and the response was zero. If we want to determine what else might be expected, we would have to trace the circuit on the HF board and make some assumptions about how “port 5″ maps to CPU pins.

A straightforward interpretation would be that these port numbers refer directly to the CPU’s GPIO port banks, and an examination of the results of !RD6 while we operate various microswitches tends to support this view.

The other anomaly is that, once we convince BoardMaster that there is a bit loaded in the spindle chuck, telling it to spin it up seems to send the appropriate commands but does nothing (i.e. the motor does not spin).

So next week I guess we will be tracing what all the GPIO ports connect to, so we can try to guess what is in port 5 that the software might be expecting.

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.