LAUGHTON ELECTRONICS |
|||
   |
|||
Diablo Daisywheels: a devilish design indeed
|
|||
 The print-wheel (aka "daisy" wheel) 
|
Introduction and General DescriptionDaisy-wheel printers are uniquely suited to certain applications, and a pair of Diablo 1345WP's was the essence of the Wescode typesetter. Analyzing the Diablo's operation is a study in robotic principles. The device features analog and digital sensors and servo loops, A-to-D and D-to-A conversions, stepper motors and solenoids, and real-time multitasking of its embedded computer. During the printing process there are five axes of motion a 1345 has to control, as follows: a pulley driven by a DC servomotor yanks the printer carriage horizontally to the correct spot on the paper. A smaller DC servomotor, traveling on the carriage, spins the print-wheel clockwise or anticlockwise as required to most quickly bring the next required petal into place in front of the hammer. Then a solenoid violently launches the hammer toward the back of the petal, momentarily crashing it against the ribbon and paper and printing that petal's embossed letter or digit on the paper. Somewhat less dramatically, a tiny stepper motor advances the ribbon after each character is printed, and a large stepper motor advances the paper vertically after each row of characters is done. The Rotary Sensors and ServosLightning precision is required for the print-wheel motor, which maniacally chatters between positions 40 or 50 times per second. The print-wheel servo toggles between two different configurations: one mode which is purely analog and another mode that's hybrid. Hybrid mode uses the embedded computer as part of the feedback loop. During seeks to a new petal, hybrid mode tracks angular distance to destination and (digitally) issues velocity commands accordingly. Then when the motor has almost reached the desired position (and zero velocity), the computer switches itself out of the loop. Analog mode is what provides damping as the print-wheel settles to zero velocity, and it keeps the wheel (and the selected petal) on station as the hammer fires. An H-bridge PWM power amplifier is what drives the motor, and feedback comes from a motion sensor mounted on the rear of the print-wheel motor. The motor's rotary motion sensor is a type well suited to a dusty, high vibration environment. It's an air core transformer, and its primary windings (there are two) and its secondary winding are copper traces in the form of radial spokes etched on the insulated surfaces of two flat disks. All the windings have the same pitch, such that 96 turns (96 pairs of spokes) would occupy a complete circle. This pitch is chosen to match the print-wheel, which has 96 petals. The disks are mounted in close proximity; one is mobile (attached to the motor shaft) and the other is stationary. The stationary disk holds both transformer primaries. Each is energized with a carrier signal, a digitally synthesized sine wave at roughly 300 kHz. It's easier to explain if we begin by pretending there's just one primary. The secondary, on the mobile disk, receives the 300 kHz signal by magnetic induction. The zig-zag pattern of the windings is crucial to the scheme: current always follows a radial path, travelling "out" one spoke (away from center) then back "in" the adjacent spoke, then out, then in, and so on. That makes the secondary very sensitive to changes in alignment, relative to the primary. For example: if the primary and secondary start off aligned, then rotating the secondary by half a petal (1/192 of a revolution) will invert the received signal. That is, the received signal will flip from 0 degrees phase angle to 180 degrees, relative to what's being transmitted. Interestingly, if we only move the secondary a quarter petal (1/384 of a revolution) we encounter one of two null points where the 0 degree and 180 degree signals are received equally, and actually cancel. The secondary experiences a loss of signal! Under these conditions (halfway between 0 and 180) it would be darn convenient to have a 90 degree signal appear, and in fact that is what the extra primary is for. The two primaries, both residing on the stationary disk, are mechanically offset a quarter petal (1/384 revolution) relative to one another, and likewise the carrier signals they transmit are electrically 90 degrees apart in phase. This eliminates null points, guaranteeing that as the secondary rotates it will always receive at least one carrier. Very often it gets a blend of both. In fact, the received signal turns out to be continuously variable in phase: it will smoothly shift from 0 through 360 degrees each time the motor revolves from one petal to the next (1/96th of a revolution). One entire revolution causes 96 repetitions of the effect. That is the essense of what makes the rotary motion sensor work. The secondary signal can fairly easily be demodulated and processed to create signals representing the instantaneous angular velocity of the wheel and the instantaneous intra-petal position. By simply counting up and down in response to the petal signals, the embedded computer always knows which direction the wheel is turning and how many petals have gone by. The 1345 carriage motor servo uses the same type of rotary motion sensor. And, in case you're wondering, there are no brushes in the sensors. Instead a conventional coaxial transformer is what relays the signal from the spinning secondary disk. the Diablo proprietary processorThe digital "brain" in control of the 1345 is not a microprocessor but a proprietary 8-bit engine built out 3 PROM's and a few dozen TTL chips. This processor and its remarkable firmware can track and control motion in all four motors (2 servos & 2 steppers) simultaneously — an astonishing feat, given that the processor has no subroutine capability, no interrupt capability, no clock/timer facility, and a program memory containing only 512 instructions! (More on this enigmatic device here.) Cracking the system and customizing the codeGetting into the Diablo computer and hacking the code an enormous challenge, not because of any security measures but simply because the code was somewhat complex and utterly obscure. I felt like an archaeologist who encounters a novel and mysterious variety of hieroglyphics — and my goal was not only to decipher the unknown language but to add some thoughts of my own, pithily expressed in the ancient vernacular! For details of the embedded processor itself, see the link in the paragraph above. The net results are as follows:First of all, I identified the location and purpose of a dozen or so program constants, such as one that determined the amount of time allocated for the print wheel to settle after a seek to a new petal. Control over the settling time was beneficial because Diablo engineers had allowed only a very brief interval for the wheel come to a stop, whereas for my client's needs it made sense to grant more time. Increasing the time allotment had a certain cost in terms of printing speed, but the payoff was an extra margin of tolerance for mechanical and maintenance issues, making it easier to sustain a high standard of print quality. A more significant change I made had to do with the print-wheels. The client used a custom print-wheel featuring a non-standard set of characters. That resulted in a mismatch with the hammer intensity values contained in the Diablo embedded processor's program. (Individual hammer intensities are stored for each petal of the wheel. This accomodates the need to hit a letter "W" fairly hard, for example, and a letter "i" comparatively gently.) The custom print wheel had been laid out in a way that made best use of the intensities for a standard wheel — but this effort was inevitably a compromise, and certain characters were forced to make do with marginally appropriate values. Fortunately, the compromise became unnecessary once I gained access to the embedded processor's program. I then had complete freedom with regard to hammer intensiries, and was able to ensure every petal used a suitable value. The payoff of the improved hammer intensities was better print quality and longer print-wheel life. Finally, the most ambitious change I made had to do with the ribbon-advance system. Originally the ribbon motor would advance the same amount for all characters, that amount being fixed at High or Low by a jumper option. The High option was mandatory for printers used for MICR service in the Wescode; this was because MICR characters are unusually wide. (In fact MICR printers had to use another custom print-wheel, one with half the usual number of petals.) But the large, fixed ribbon advance was wasteful because the MICR wheel also included a lot of narrower, non-MICR characters. I intervened by patching an entirely new routine into the program. It enabled the ribbon motor to mete out ribbon proportionally according to each character, rather than in a fixed increment. Each character got a specific amount, tailored of course to the client's custom print-wheel. This innovation reduced ribbon consumption significantly, resulting in lower Consumables costs and less need for operator intervention. |
||
|
|||
 |
|||
