Stap 7: Vervoerder Feed besluiten en theorie
Deze stap beschrijft een aantal van mijn gedachten bij de beslissing hoe te voeden de vervoerder en de gemonteerde PCB via de printer te bereiken van de maximale nauwkeurigheid. U kunt het overslaan als je niet geinteresseerd bent.
De vorige twee iteraties van dit project gebruikt de Manual papier Feed mechanisme om te rijden de vervoerder naar voren in de printer. Dit werkte (meestal) want ik mag de drager om verder te gaan met minimale wrijving of beperking, met de voorkant van de vervoerder ver van de Drum/Transfer Roller Interface (DTRI).
In deze versies sloeg het gat in de vervoerder de vzw's goed voordat de voorkant van de vervoerder de DTRI ingevoerd. Terwijl dit goed voor één dubbelzijdige PCB's werkt, de variatie in snelheid als de DTRI wordt geraakt zorgt ervoor dat een kleine, maar merkbare, variatie in de timing van de afdruk, wat leidt tot verkeerde registratie in de Y-as. De X-as had zijn eigen problemen te wijten aan de korte "timing venster" toegestane in de firmware van de printer E260. Om het even wat die belemmerd motie (zoals wrijving) van de vervoerder veroorzaakt een fout.
Voor maximale boven naar onder registratie nauwkeurigheid is het noodzakelijk dat de vervoerder zich beweegt op zijn stabiel, definitieve tarief wanneer de vzw's wordt geactiveerd. Om dit te bereiken, willen we de vervoerder al in de trommel/Transfer Roller Interface (DTRI) worden geplaatst wanneer het papier In Sensor (PIS) laag gaat.
Hiervoor echter vereist dat het beginpunt van de voorrand van de drager slechts vooruit van de DTRI, en dat de PIS trigger punt worden gevestigd ten minste twee duim en bij voorkeur een beetje meer van de startlocatie van de vervoerder.
Helaas, de eisen van de interne timing van de E260 maakt dit moeilijk te bereiken, met name met behulp van de inconsistente handleiding Feed koppeling solenoïde ingebouwd in de printer. Deze spoel heeft de neiging om te "plakken", zowel als het opent en sluit, vernauwing van de timing "window" van de vergadering van de koppeling. Dus, terwijl er nauwelijks kunt u gebruik maken van de handleiding Feed mechanisme om te rijden de vervoerder in de DTRI, de koppeling solenoïde moet zorgvuldig worden aangepast zodat het zo snel mogelijk de koppeling vrij.
Het andere probleem met dit smalle timing-venster is dat wrijving, met inbegrip van dat inherent houden de vervoerder perfect uitgelijnd side-to-side, de vervoerder vertraagt, soms waardoor het "late" bij het bereiken van de PIS, waardoor de printer fout uit.
Na een heleboel gedachte en experimenten besloten heb ik dat eenvoudigste is het beste. In plaats van het mechanisme van de printer om te duwen van de vervoerder in de Interface, ik verwijderde de hele koppeling en solenoïde vergadering en ik laat de gebruiker gewoon handmatig "schuif" de vervoerder in de Interface met de hand. De MCU controleert de timing door het detecteren van de juiste tijd om de vervoerder vooraf en ontvangt de gebruiker een bericht wanneer "push" via een piëzo "beeper".
