README: Fix some minor things

This commit is contained in:
fruchti 2020-01-06 23:13:13 +01:00
parent 003833d788
commit 6f156d37be

View file

@ -6,7 +6,7 @@ It is based on [this](http://www.instructables.com/id/Modification-of-the-Lexmar
## Project status and performance ## Project status and performance
The printer behaves reasonably predictable and the way it should. The results are quite good: A minimal trace width of 5mil and a minimal clearance of 10mil are no big deal. The printer behaves reasonably predictable and the way it should. The results are quite good: A minimal trace width of 5mil and a minimal clearance of 10mil are no big deal.
![MCU Board](https://raw.githubusercontent.com/fruchti/haxmark/master/samples/001.jpg) ![MCU Board](https://raw.githubusercontent.com/fruchti/haxmark/master/samples/001.jpg)
@ -14,7 +14,7 @@ The printer behaves reasonably predictable and the way it should. The results ar
### Some notes before you modify your printer ### Some notes before you modify your printer
I strongly recommend that you test your printer in an unmodified state with exactly the driver and printer settings you intend to use it with to print on PCBs. I found out the hard way that the behavior and the timing differ from driver to driver. It is definitely a good idea to make a dump of the interesting signals (operator panel line, manual paper feed sensor, paper in sensor, exit sensor) with a logic analyzer to get the exact timing of your printing setup so you can adjust the timing settings in the MCU board's source code. I included a dump made with logic_sniffer and my settings. I use the printer with linux and [this](http://www.openprinting.org/printer/Lexmark/Lexmark-E360d) PPD file with 1200dpi native resolution. I have not used it with Windows, so if you plan to do that, better check the printer's behavior in detail before making any modification. I strongly recommend that you test your printer in an unmodified state with exactly the driver and printer settings you intend to use it with to print on PCBs. I found out the hard way that the behaviour and the timing differ from driver to driver. It is definitely a good idea to make a dump of the interesting signals (operator panel line, manual paper feed sensor, paper in sensor, exit sensor) with a logic analyser to get the exact timing of your printing setup so you can adjust the timing settings in the MCU board's source code. I included a dump made with logic_sniffer and my settings. I use the printer with linux and [this](http://www.openprinting.org/printer/Lexmark/Lexmark-E360d) PPD file with 1200dpi native resolution. I have not used it with Windows, so if you plan to do that, better check the printer's behaviour in detail before making any modification.
### Differences to the E260d ### Differences to the E260d
@ -25,13 +25,13 @@ The main hardware difference between E260d and E360d is the use of a different o
### Hardware modification ### Hardware modification
The hardware modifications are mainly the same as in [the original instructable](http://www.instructables.com/id/Modification-of-the-Lexmark-E260-for-Direct-Laser--1). But, because the motor directly pulls in the carrier, an additional clutch is needed to keep the rollers stopped unless the carrier actually should move. The printer provides a solenoid, which is able to block the rollers, on its left side. Cut the low-side cable at the printer's controller board and connect it to the new MCU board. Leave the other end connected to 24V. The MCU board also needs a connection to a hall sensor of the motor in order to be able to check if it is running. I tapped the lowest pin on J17, but any of the three sensor lines should work. Just be sure that you do not connect the MCU to one of the motor windings (the three wires with the ferrite bead over them), as they are driven with 24V. The hardware modifications are mainly the same as in [the original instructable](http://www.instructables.com/id/Modification-of-the-Lexmark-E260-for-Direct-Laser--1). But, because the motor directly pulls in the carrier, an additional clutch is needed to keep the rollers stopped unless the carrier actually should move. The printer provides a solenoid, which is able to block the rollers, on its left side. Cut the low-side cable at the printer's controller board and connect it to the new MCU board. Leave the other end connected to 24V. The MCU board also needs a connection to a hall sensor of the motor in order to be able to check if it is running. I tapped the lowest pin on J17, but any of the three sensor lines should work. Just be sure that you do not connect the MCU to one of the motor windings (the three wires with the ferrite bead over them), as they are driven with 24V.
I made some additional modifications: I made some additional modifications:
- I use a 18cm wide and 30cm long carrier. The 60cm long carrier proved to be way to long for me. - I use a 18cm wide and 30cm long carrier. The 60cm long carrier proved to be way to long for me.
- I swapped the forked light barrier "new paper in sensor" for a reflective sensor (SFH900-2). This way I can use a piece of tape on the carriers bottom instead of a hole. If you use the original approach, you have to invert the signal in the AVR's source code. - I swapped the forked light barrier "new paper in sensor" for a reflective sensor (SFH900-2). This way I can use a piece of tape on the carriers bottom instead of a hole. If you use the original approach, you have to invert the signal in the AVR's source code.
- My carrier has two markings for the reflective light sensor. The new first marking triggers the sensor when the carrier is pulled in just slightly. The MCU board uses this to feed the carrier into the printer into the exact same starting position every time. Especially for double-sided PCBs this is useful as it provides better alignment. The markings on my carrier are now 113mm and 181mm from the top with the reflective light sensor being 100mm in front of the first axle. - My carrier has two markings for the reflective light sensor. The new first marking triggers the sensor when the carrier is pulled in just slightly. The MCU board uses this to feed the carrier into the printer into the exact same starting position every time. Especially for double-sided PCBs this is useful as it provides better alignment. The markings on my carrier are now 113mm and 181mm from the top with the reflective light sensor being 100mm in front of the first axle.
### New MCU board ### New MCU board
@ -45,5 +45,5 @@ The printing process is straightforward:
2. Wait until the printer's motor stops running 2. Wait until the printer's motor stops running
3. Put the carrier with the bare PCB on it in 3. Put the carrier with the bare PCB on it in
4. Press the tick button on the printer and watch it print 4. Press the tick button on the printer and watch it print
5. Treat the PCB in acetone vapor (as described in the original instructable) and etch 5. Treat the PCB in acetone vapour (as described in the original instructable) and etch