I have my 12-point Binny Old Style diecase set up, so last Saturday, I tried my first run with my laptop controlling my Monotype Composition Caster.
The text is a little note to include when I ship type across the border, attempting to discourage customs inspectors from unwrapping and pi-ing the type. Up until now this has been an MS Word document, from which I copied and pasted the main text into a new document to feed to Bill Welliver’s CompCAT software. So, no typos.
The casting job seemed to run well, although some of the type has burrs or fins on the body. The low em-quads have a fin up from the trailing edge, indicating the the upper mould blade is not staying closed tight against the mould crossblock. I guess it is time to take the mould apart and clean it.
I used some carbon paper to take a proof without having to wash ink off the type:
Although the input file had no typos, the words “clear” and “neatly” cast as “llear” and “eeatly” respectively. So letters that should have cast from positions J4 and K8 cast from J1 and K4 instead, both being the exact positions of the previously-cast letters.
One possibility is that some of the front airpins are slow to drop, so the 1 and 4 pins stayed up for an extra casting cycle. This would be more plausible if it were the same pin in both cases, but it seems very unlikely that there should be two sticky pins and that they both happened to stick when the next letter to cast was in the same column (J or K), and nowhere else in the job. Note that in each case the desired pin is a higher number than the (sticky) one. This would not be a valid explanation if the caster had cast “cc” instead of “lc” (J4 then J1 in the reversed casting order) because the 4 pin sticking up would have been overridden by the smaller-numbered 1 pin.
Another possibility is that the computer is occasionally failing to send a new selection code to the interface, so the same letter is cast twice in a row. The fact that the correct and cast letters happen to be in the same column would then be just coincidence. Given that the diecase layout is designed to keep the common letters close together, that is not a particularly unlikely coincidence. I’ve also noticed hints of communication problems when the air compressor starts up, and those two errors are roughly one compressor cycle apart.
I’m feeling that my measurement of plausibility here may be a bit skewed: On the one hand I appear to be finding it implausible that the two errors should happen to occur when the two letters involved happen to be in the same column, yet on the other hand I’m happy to treat that as just a coincidence. I should probably just cast the job a few more times to better qualify when the errors occur.
The USB protocol for writing to the device does not include any sort of verification: The host computer just sends the data and the device is expected to listen for it. It looks like I will have to modify the software to read back the device status to ensure that the written data was received, and if not, to send it again. At first I will make the software signal an error when this happens rather than resending, so I can verify that this is indeed the source of the problem. Fixing intermittent problems is always so much fun…
Leave a Reply