Hallo Leute!
Habe ein LTP1245
Thermodruckermodul(http://www.seiko-instruments.de/files/ltp1245.pdf)
von Seiko bestellt und würde gerne ihn mit dem PC ansteuern.
Die Funktionsweise des Druckers ist mir noch nicht bekannt. Habe aber
bereits den Produzenten kontaktiert - hoffentlich sendet er mir eine
bald eine Dokumentation zu...
Obwohl ich bis jetzt nur erfahrungen mit R232 gesammelt habe, würde ich
gerne die usb-schnittstelle des PC zum ansteuern verwenden...
Da ich nur ungern das schöne Flexiprint-Kabel zerrupfen würde, frage ich
mich ob es ne passende buchse zum anlöten/stecken auf Lochrasterplatinen
gibt?
Aber dann stellt sich schon das nächste Problem: Ich brauche eine
Ansteuerungslogik. Es sind ca. 29 Pins zum ansteuern, brauche ich also
einen Microcontroller?
Wie würdet ihr an die sache rangehen?
Bastlergrüße eNoVa
eNoVa schrieb:> Wie würdet ihr an die sache rangehen?
1. Doku lesen und verstehen.
2. Einen Platine mit passendem Steckverbinder, µC, Schieberegistern um
die Anzahl der Ausgänge von eben diesem zu vergrößern und
RS232-USB-Wandler zusammenlöten.
3. Programm für µC schreiben.
4. Programm für PC (virtueller ComPort) schreiben.
5. sich freuen.
Ich hab mal so ein ähnliches Modul mit einem Atmega32U4 angesteuert.
Grundsätzliche Frage was willst du damit machen? Wenn du über eine
Virtuelle Serielle Schnitstelle die Daten in einem eigenen Format
schicken willst, geht dass noch. Wenn du das als Windows Drucker nutzen
willst: Vergiss es!
Ich hab mal zwei Datenblätter von ähnlichen Druckern angehängt, damit du
dir einen groben Überblick darüber machen kannst, wie man den ansteuern
muss.
Verwirrter Anfänger schrieb:> Wenn du über eine> Virtuelle Serielle Schnitstelle die Daten in einem eigenen Format> schicken willst, geht dass noch.
Davon gehe ich oben aus. Pollin hat auch ab und an mal solche Module im
Sortiment.
Verwirrter Anfänger schrieb:> Grundsätzliche Frage was willst du damit machen? Wenn du über eine> Virtuelle Serielle Schnitstelle die Daten in einem eigenen Format> schicken willst, geht dass noch. Wenn du das als Windows Drucker nutzen> willst: Vergiss es!
Ich habe meinem Druckerchen so viel HP PCL beigebracht, dass ein
Tektronix TDS-220 einen Screendump auf ihm machen konnte. Das Oszi habe
ich auf HP Thinkjet eingestellt, und damit passte die Auflösung.
Das wäre auch für den OP eine geeignete Strategie. Als Vorbild taugen
z.B. die Star/Epson Bondrucker, die per ESC/POS angesteuert werden.
fchk
Danke für die schnellen Antworten.
Verwirrter Anfänger schrieb:> Grundsätzliche Frage was willst du damit machen?
Die Idee ist ihn in ein PC-Kassensystem als Kassenbondrucker zu nutzen.
Da die Software selbstgeschrieben ist, bin ich ziemlich flexibel im
Datenformat. Da das system unter linux läuft ist Windows irrelevant.
Die Systeme besitzen lediglich USB...
Verwirrter Anfänger schrieb:> Ich hab mal so ein ähnliches Modul mit einem Atmega32U4 angesteuert.
Klingt nach nen guten Tip! Unter der vielfallt der µC tue ich mich bei
der sehr schwer, denn gearbeitet habe ich überwiegend mit nem 8051.
troll schrieb:> 2. Einen Platine mit passendem Steckverbinder, µC, Schieberegistern um> die Anzahl der Ausgänge von eben diesem zu vergrößern und> RS232-USB-Wandler zusammenlöten.> 3. Programm für µC schreiben.
Könnte man nicht ohne µC arbeiten indem man zb. nur ein Schieberegister
füllt und bei änderung ihn leert und neu befüllt( oder "double
buffered"- zwei register stets tauschen)?
Die PC-Software müsste dan dies alles regeln...
Bastlergruß eNoVa
>Könnte man nicht ohne µC arbeiten indem man zb. nur ein Schieberegister>füllt und bei änderung ihn leert und neu befüllt
Wenn du es schaffst ein Schieberegister über USB ohne uC
anzusteuern dann bist du reif für den Nobelpreis.
Ansonsten denke ich das du eine Flachpfeife bist.
Das was du dir da ausgesucht hast ist ein Druckkopf
ohne Ansteuerelektronik. Viel Spass damit.
Am besten gleich in die Mülltonne werfen.
eNoVa schrieb:> Könnte man nicht ohne µC arbeiten indem man zb. nur ein Schieberegister> füllt und bei änderung ihn leert und neu befüllt( oder "double> buffered"- zwei register stets tauschen)?> Die PC-Software müsste dan dies alles regeln...
Naja. Es mag so funktionieren (kenne die Ansteuerung dieser Drucker
nicht), allerdings dürfte es ein Krampf sein das Schieberegister an den
USB-Port zu bekommen (eventuell FTDI mit GPIO?). Ich würde nen AVR und
einen RS232-USB-Wandler nehmen, dann reduziert sich das Problem auf ein
paar triviale Sachen die man miteinander verhäkelt.
holger schrieb:> Ansonsten denke ich das du eine Flachpfeife bist.
Sowas ist in keinster Weise produktiv, also halt gefälligst die Schnute!
Der TO hat vernünftig gefragt also bekommt er auch vernünftige
Antworten.
>> Ansonsten denke ich das du eine Flachpfeife bist.>Sowas ist in keinster Weise produktiv, also halt gefälligst die Schnute!
Wieso? Der Typ kann nichts. Warum darf man ihm das nicht sagen?
>Der TO hat vernünftig gefragt also bekommt er auch vernünftige>Antworten.
Mal ihm einen Schaltplan mit der entsprechenden Leistungselektronik.
Sonst kackt der doch gleich wieder hier rein.
>Ich würde nen AVR
Ohne uC war die Frage. Selbst mit ist der doch komplett überfordert.
eNoVa schrieb:> Könnte man nicht ohne µC arbeiten indem man zb. nur ein Schieberegister> füllt und bei änderung ihn leert und neu befüllt( oder "double> buffered"- zwei register stets tauschen)?
Nein. Da gibts ein enges Timing, das einzuhalten ist. Schaltest Du z.B.
die Heizspannung zu kurz ein, bekommst Du weiße Schrift auf weißem
Grund. Heizt Du zu viel, tötest Du den Druckkopf. Ein PC ist kein
Echtzeitsystem. Schon gar nicht über USB.
Der Hersteller bietet nicht ohne Grund für Leute wie Dich ein
Interface-Board an, das eine parallele Schnittstelle bereitstellt. Nimm
das, dann kannst Du ein normales USB-Parallelport-Druckerinterface
verwenden, und alles wird gut.
fchk
@holger ( ja ganze 25 zeilen widme ich dir ;-)
holger schrieb:>> Ansonsten denke ich das du eine Flachpfeife bist
Was andere über mich denken interessiert mich herzlich wenig.
>Wenn du es schaffst ein Schieberegister über USB ohne uC>anzusteuern dann bist du reif für den Nobelpreis.>Ohne uC war die Frage. Selbst mit ist der doch komplett überfordert.
hmm, lese ich hier interesse an dem Thema herraus?
>Am besten gleich in die Mülltonne werfen.>Bei den Kenntnissen die du hast: Vergessen.
Aber im grossen und ganzen lese ich eine zimlich agressive,
lernfeindliche und materialfeindliche einstellung heraus. Bist du mit
dir unzufrieden,cip. ?
> Wieso? Der Typ kann nichts. Warum darf man ihm das nicht sagen?
Darfst du, jeder wird aus diesem Thread, das herausziehen was er als
nützlich erachtet; es ist nur schade dass alle Mitleser wegen dir ihr
Scrollrad zusätzlich strapazieren müssen.
holger schrieb:> Mal ihm einen Schaltplan mit der entsprechenden Leistungselektronik.> Sonst kackt der doch gleich wieder hier rein.
Wenn du meine Posts als Geistigen-Durchfall empfindest und ein
Schaltplan als anti-diarrhoea ansiehst, wieso forderst du andere auf,
dein leiden zu beenden, wenn du es selbst könntest(das ist aber von mir
keine aufforderung, hier irgentetwas konstruktives beizutragen).
Naja wie auch immer, am ende werd ich dir danken, wie sonst auch allen
mein Zweiflern, den die gaben mir immer ne schmackhafte Portion
Motivation.
ok, dass war genug geistiger Durchfall, nun zum Thema :
========================================================================
==
Sehe ich das richtig, in anbetracht der ca. 29 Pins des Druckers
lediglich, an die I/O Pins eines µC, welcher einen TX und RX Pin für den
seriellen empfangen und senden aufweist,zu verdraten( modulo evtl.
wiederstände etc.) ?
Gibt es noch etwas was ich bei der wahl des µC beachten sollte?
Wie sieht es mit dem Speicher aus?
Wegen der 8dots/mm => 384dots/line bräuchte ich ja für 10cm Papier,
384000bits => 48kb Speicher.
Ein empfangen der Rohdaten, sichern dieser und anschliesendes ausführen
des Druckjobs, scheint nicht allzu praktikabel zu sein.
Ein gleichzeitiges empfangen und drucken scheint freundlicher zu sein.
Ein kleines Protokoll mit der möglichkeit daten direkt in ASCII zu
senden scheint mir überaus sinnvoll zu sein.
Ist eine Zeile gedrukt könnte man durch TX dann auch gleich die nächste
Zeile anfordern und den Papierstatus gleich mitsenden.
Da ist, glaube ich, HP PCL sich anzuschauen ein guter Tip von Frank K.
Bin schon gespannt, ist HP PCL nur ein unidirektionales Protokoll? -
Oder beschreibt es auch Drucker-Antworten?
Werde mich morgen abend mehr mit der Materie auseinandersetzen.
Gute Nacht
eNoVa schrieb:> Sehe ich das richtig, in anbetracht der ca. 29 Pins des Druckers> lediglich, an die I/O Pins eines µC, welcher einen TX und RX Pin für den> seriellen empfangen und senden aufweist,zu verdraten( modulo evtl.> wiederstände etc.) ?>
Du wirst noch einen Schrittmotortreiber für den Papierlauf brauchen und
solltest nach Möglichkeit die Auslesung der Temperatur un des
Papierstatus einbauen, dafür brauchst du evtl. einen Spannungsteiler.
Bei der Spannungsversorgung ist darauf zu achten, dass der Kopf beim
Drucken bis zu 2A ziehen kann, also ordentlich buffern und nicht per USB
betreiben.
> Gibt es noch etwas was ich bei der wahl des µC beachten sollte?> Wie sieht es mit dem Speicher aus?> Wegen der 8dots/mm => 384dots/line bräuchte ich ja für 10cm Papier,> 384000bits => 48kb Speicher.> Ein empfangen der Rohdaten, sichern dieser und anschliesendes ausführen> des Druckjobs, scheint nicht allzu praktikabel zu sein.> Ein gleichzeitiges empfangen und drucken scheint freundlicher zu sein.> Ein kleines Protokoll mit der möglichkeit daten direkt in ASCII zu> senden scheint mir überaus sinnvoll zu sein.> Ist eine Zeile gedrukt könnte man durch TX dann auch gleich die nächste> Zeile anfordern und den Papierstatus gleich mitsenden.> Da ist, glaube ich, HP PCL sich anzuschauen ein guter Tip von Frank K.> Bin schon gespannt, ist HP PCL nur ein unidirektionales Protokoll? -> Oder beschreibt es auch Drucker-Antworten?
Du könntest nen externen Speicher dranhängen, aber ich würd zeilenweise
drucken, dann bist du bei der Länge des Abschnitts nicht eingeschränkt,
und 48 Byte sollte in den meisten µC noch frei sein.
Du könntest natürlich auch einen Textmodus einbauen, damit lässt sich
locker eine 1:10 Komprimierung erreichen.
So habe ich das gemacht. Achtung - ich verwende ein anderes Druckwerk,
bei Dir kann das ganz anders gelöst sein. Mein Druckwerk möchte die
Pixeldaten seriell haben, und über die sechs STROBE Signale werden die
Heizelemente im Druckwerk aktiviert, segmentweise, um den Stromverbrauch
zu begrenzen. Ein Schrittmotortreiber macht den Vorschub, und über ein
paar Sensoren können Temperatur, Papier und Kopf hoch(Papier
einfädeln)/runter(drucken) abgefragt werden.
Normalerweise macht das Teilchen nur Textmodus, d.h. Textzeile
empfangen, Zeichen im Pixel übersetzen und ausgeben. Den PCL-Grafikmodus
für mein TDS220 hab ich später eingebaut. Das sind nur ein paar Befehle,
genau die, die das Oszi benutzt. Eine vollständige PCL-Unterstützung ist
zu aufwändig und würde bei so einem Teil keinen Sinn machen. Den
PCL-Standard gibts bei HP, das sind insgesamt so >>1000 Seiten.
Du solltest erst einmal gar nichts machen, so lange bis Du die komplette
Schnittstellenspezifikation Deines Druckwerks hast. Vorher bist Du nicht
in der Lage, sinnvolle Designentscheidungen zu treffen. In der
Spezifikation steht dann auch drin, welcher Stecker für Dein FPC passt.
fchk
Verwirrter Anfänger schrieb:> Ich hab mal so ein ähnliches Modul mit einem Atmega32U4 angesteuert.
Du hast in dem Beitrag (s.o.) das Datenblatt u.a. vom MP205 hochgeladen.
Hast Du genau das Druckwerk angesteuert? Wenn ja, kannst Du mir bitte
mal mit einem kleinen Rat zur Seite stehen? Ich will das MP205 auch mit
einem ATMEGA ansteuern. Ich weiss nicht, was ich falsch mache, aber es
druckt bei mir immer nur die erste Zeile, die ich zum Drucker sende.
Alle Daten, die ich danach zum Drucker sende, werden ignoriert und
weiterhin nur die erste Zeile gedruckt.
Was mache ich:
1. Ich schicke 384 Bits zum Drucker (also 384 x Clock L/H/L schalten,
nebenbei auch das Datenbit entsprechend setzen). Jeder Zustand ist 10µs
lang. Da im Datenblatt nur die minimalen Zeiten im ns-Bereich angegeben
sind, sollte ich mit meinen 10µs definitiv nicht zu schnell sein.
2. Ich warte, nachdem ich die Daten gesendet habe, 10µs. Dann schalte
ich /LAT von H nach L und nach 10µs wieder zurück nach H
4. Ich warte 10µs, bevor ich die Spannung für die "Heizung" einschalte
3. Ich warte 1ms, dann schalte ich Strobe (alle Leitungen gleichzeitig)
nach H (ca. 2ms, je nach Spannung), danach wieder auf L
3. Ich warte 1ms, dann schalte ich die Spannung für die "Heizung" aus
Nach 10ms kommt die nächste Zeile.
Egal, was ich dann sende, es kommt nur der Ausdruck der Daten der zuerst
gesendeten Zeile. Es ist. als ob die Daten der folgenden Zeilen gar
nicht angenommen werden.
Ich weiss, die Zeiten sind viel zu lang und damit wird der ganze
Ausdruck sehr langsam, aber das ist mir erstmal egal. Ich will, dass das
Ding druckt, optimieren kann ich später immer noch.
Wäre schön, wenn jemand einen Tipp für mich hat, was ich falsch mache.
Gruß, Helge
Meine Frage hat sich erledigt, ich hatte beim ersten Mal die
Latch-Leitung nicht richtig initialisiert, die war beim Start immer L
und erst nach dem Druck der ersten Zeile stimmte der Pegel (inaktiv H).
Gruß, Helge
