Quantcast
Channel: KwartzLab Makerspace » Kwartzlab Radio
Viewing all articles
Browse latest Browse all 28

LPKF Board Mill, Part 3

$
0
0

We seem to have run into a wall again with the board mill.
Just before last week’s TON I had a bit of an epiphany which cleared up a little mystery but we are otherwise at a standstill again.

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.


Viewing all articles
Browse latest Browse all 28

Trending Articles