Hallo Profis, ich hab da ein kleines Problem. Ich plane zur Zeit ein Projekt eines automatisierten Ladegerät für eine große Anzahl an NiMH-Akkus ( > 50). Diese sollen mit einer SN/ID versehen werden, und dann auf einer SD-Karte beim Laden geloggt werden. Um die SN/ID einzulesen dachte ich mir, ist es einfach einen Barcode auf die Akkus zu drucken und mit einem Scanner einzulesen. Dazu habe ich mir in der E-Bucht günstig einen Barcode-Reader in Stiftform besorgt: Intermec 1281A02 Leider hat sich nach ein wenig Herumprobieren und Logikanalyzer quälen heraus gestellt, das der überhaupt keinen Seriellen Ausgang hat, sondern mit einem Pullup gegen 5V an der OUTPUT-Leitung die Barcode-"Daten" im Rohformat rausgibt (wie eine Lichtschranke) schwarz -> LOW weiss -> HIGH Das ist natürlich Mist, aber bevor ich mich jetzt nach einem anderen Scanner mit RS232, PS2 oder ähnlichem umsehe, dachte ich, ich probier es mal das Ding trotzdem irgendwie an einen AVR zu bekommen. Habt ihr hierfür vielleicht einen Tipp, oder ist die Auswertung von Barcodes im AVR in C viel zu komplex ? Ich wollte halt einen schlanken Bracode-Reader in Stiftform oder etwas vergleichbar kleines und einfaches. Oder habt ihr ganz andere Vorschläge wie ich die Akkus erfassen kann, ohne die SN/ID händisch einzutippen ? RFID dachte ich wäre auch eine Lösung, aber die TAG's sind nicht gerade günstig und dicker als ein Barcode. Und bei AA-Akkus wird es da schon eng mit dem Platz. Grüße, Marcel
Ich habe auch schon mal mit dem Gedanken gespielt, so etwas zu bauen. Meine Idee war, in den Akku-Halterungen selbst die Akkus zu identifizieren. Dazu hätte ich mehrere grobe Ansätze. Kriterien sind: 1. Markierung soll "einfach" d.h. mit Bastler-Haushaltsüblichen Mittel erstellbar sein. Also etwa Drucker bzw. Labeldrucker (Brother Ptouch kann Barcodes als auch Symbole). 2. Markierung soll "haltbar" sein. D.h. das Merkmal muss auch langfristiges Hantieren überstehen. Gerade bei Papierlabels sehe ich die Gefahr, dass durch häufiges Berühren die Erkennbarkeit leidet. Als Alternative habe ich z.B. so etwas wie hier: http://www.pearl.de/a-PE8352-2010.shtml;jsessionid=oaaUI0D5ho9_t9nSj_Y7u ins Auge gefasst. (Nur gerade der erste sinnvolle Treffer bei Suche nach: "laserdrucker kunststoff klebefolie undurchsichtig". 3. Code soll Redundanz bzw. Prüf- oder sogar Korrekturinformationen enthalten. Mit einigen Einschränkungen schienen mir 2 gleichartige Lösungen sinnvoll: a) Eine Reihe von LEDs und Fotodioden oder Transistoren. b) Eine kleine CCD-Zeile. Beide Lösungen haben den Nachteil, dass man entweder eine handelsübliche Akku-Aufnahme "modden" muss oder sich eine anfertigen lassen muss. Was früher nicht ging, aber heutzutage mit 3D-Druck einfach und recht günstig geht. Was hälst Du davon?
Die Idee das ganze in jede Ladeschale einzeln zu bauen hatte ich auch schon, daher zuerst die Idee mit RFID. Leider tragen diese zu dick auf. Im Ladegerät ist das kein Problem, aber in einer Maglite-AA oder ähnlichem könnte der etwas dickere Tag schon zum verhaken führen. LED's & Photozellen schaffen wohl keine ausreichende Auflösung. Aber das mit der CCD-Zeile hört sich interessant an. Man könnte aber auch eine einzelne "Dummy-Ladeschale" machen, wo der Akku eingelegt und erfasst wird, und dann mit einer LED oder so eine freie Ladeschale angezeigt wird, wo der Akku zum laden rein kommen soll. Die selbe Idee hatte ich schon mit einem Laser-Barcodescanner, aber da scheint der Laser dann ja aus dem Gerät raus, und man könnte eventuell reingucken -> nicht schön. Schön wäre es trotzdem, den Barcode-Pen irgendwie zum laufen zu bekommen ;-) Joe F. schrieb: > Nummer von 1 bis 50 mit Edding draufschreiben. das ist keine Option, da in der ID diverse Sachen wie Typ, Hersteller und so Sachen eingebaut werden sollen um auch neue Akkus automatisch als Datenbankeintrag auf der SD-Karte anzulegen. Das Ladegerät soll nämlich auch von absoluten Vollpfosten bedienbar sein. Akku scannen -> eventuell Reinlegen wo es leuchtet -> macht alleine
:
Bearbeitet durch User
Marcel P. schrieb: > ... > LED's & Photozellen schaffen wohl keine ausreichende Auflösung. Ich denke das könnte schon reichen. Eine AAA-Zelle ist ca. 43mm hoch (Wikipedia), Das wären bei einem 8-Bit-Code 5mm pro Zeichen. Es gibt ja 3mm LEDs oder SMD. (Natürlich existiert damit dennoch eine Untergrenze für die Grösse). > Schön wäre es trotzdem, den Barcode-Pen irgendwie zum laufen zu bekommen > ;-) Verstehe. Ob ein AVR das packt, weiss ich nicht definitiv, aber ich denke der sollte das können. Schon mal nach fertigem Code gesucht?
Marcel P. schrieb: > ... da in der ID diverse Sachen wie Typ, Hersteller > und so Sachen eingebaut werden sollen um auch neue Akkus automatisch als > Datenbankeintrag auf der SD-Karte anzulegen. > Das Ladegerät soll nämlich auch von absoluten Vollpfosten bedienbar > sein. Akku scannen -> eventuell Reinlegen wo es leuchtet -> macht > alleine Ach so! Dann klappt meine 8-Bit-Lösung natürlich so nicht. Wieviel Bits willst Du denn ablegen? Was für einen Code willst Du verwenden?
Klaus schrieb: > Verstehe. Ob ein AVR das packt, weiss ich nicht definitiv, aber ich > denke der sollte das können. Schon mal nach fertigem Code gesucht? Halbherzig ja. Ich dachte daran EAN-Code zu verwenden, leider habe ich dazu wenig bis gar nichts gefunden, was sich mit einem 8-biter beschäftigt. Meist geht es in Richtung PS2-Auswertung oder eben Auswertung mit CCD-Zellen.
Schau mal hier rein: http://zbar.sourceforge.net/ https://github.com/zxing/zxing Ansonsten mal suchen nach: Symbology Decoding Algorithm
Marcel P. schrieb: > Das Ladegerät soll nämlich auch von absoluten Vollpfosten bedienbar > sein. Egal was du tust, der Vollpfosten wird immer einen Weg finden wie er dein hübsch ausgedachtes Konzept aushebeln kann. Je 'technisch komplexer' du das machst, desto mehr Wege wird er finden. 999 Akkus hab ich mein ganzes Leben lang ganz sicher noch nicht besessen (noch nicht einmal annähernd). Und ich mach jetzt seit >35 Jahren Modellbau.
:
Bearbeitet durch User
Karl H. schrieb: > Marcel P. schrieb: > >> Das Ladegerät soll nämlich auch von absoluten Vollpfosten bedienbar >> sein. > > Egal was du tust, der Vollpfosten wird immer einen Weg finden wie er > dein hübsch ausgedachtes Konzept aushebeln kann. Je 'technisch > komplexer' du das machst, desto mehr Wege wird er finden. Es ist ohnehin zu vermuten, dass das Konzept eines "DAU-sicheren" Gerätes von einem DAU stammt. :-) Aber mal im Ernst: @ Marcel Einerseits schreibst Du das im Code die Informationen über Kapazität, Hersteller etc. vorhanden sein sollen, dann aber schreibst Du von "EAN" (GTIN). Es ist aber schon klar, dass Du bei Verwendung der GTIN eine externe Datenbank benötigst um Kapazität etc. aus der GTIN erst zu ermitteln, oder? Oder die Datenbank ist (zumindest die Public Domain DBs) potentiell unvollständig oder falsch und daher nicht DAU-sicher. Ist das soweit akzeptabel für Dich?
Zxing ist wohl eher ungeeignet für einen 8-biter... @kbuchegg Das ist klar das es immer einen noch größeren DAU gibt. Aber dafür gibt es dann auch den 1200mm-Holz-Patch ! Die Zielgruppe, welche ich da im Kopf habe, sind froh um jedes Knöpflein das sie weniger drücken müssen. Ich werde wohl für das Ladegerät-Projekt auf einen anderen Barcode-Reader mit PS2 oder Seriellem Output gehen müssen, denn ich möchte nicht allzuviel Zeit in den Eingabeteil investieren. Die Lade-Funktionen werden genug Zeit fressen. Aber ich will den Pen trotzdem irgendwie zum laufen bekommen, auch unabhängig von dem Ladeprojekt.
Marcel P. schrieb: > Die Zielgruppe, welche ich da im Kopf habe, sind froh um jedes Knöpflein > das sie weniger drücken müssen. :-) Ehe ich da jetzt bei einem neuen Akku kompliziert mir erst mal den Drucker mit dem Ladegerät verbinden muss (oder den PC hochfahren), ein Barcode Etikett ausdrucke, das ich dann mit Tesa auf den Akku kleben muss .... da pfeif ich drauf. Dem gegenüber ist es eine WOhltat, wenn ich am Ledgerät den Punkt 'neuer Akku' auswähle, das Ladegerät gibt mir eine Zahl (zwischen 001 und 999) und die schreib ich mit Edding auf den Akku. Beim Einlegen eines Akkus eine Taste beim Schacht drücken und dann auf der Hauptkonsole eine 3 stellige Zahl eingeben, erscheint mir schon fast als Wohltat wenn ich bedenke wie oft so ein Barcode Einlesevorgang wiederholt werden muss, weil mal wieder irgendwo Schmutz drauf ist, zu schnell bzw. zu langsam gescannt wurde, ungleichmässig gescannt wurde bzw. der verdamm.... Barcode Leser wieder mal irgendwo verschwunden ist :-) Es hat schon seinen Grund, warum manuelle Barcode Leser wieder mehr oder weniger ausgestorben sind. Aber ich will dich nicht aufhalten. (Es gab auch mal eine Zeit in der man dachte ein Lightpen wäre super duper. Bis den ersten Benutzern nach 2 Stunden 'Arbeit' der Arm abgefallen ist)
:
Bearbeitet durch User
Hm. Ich hielt es für eher unwahrscheinlich aber mit "barcode pen mikrocontroller decoder" fand ich folgenden Eintrag: https://courses.cit.cornell.edu/ee476/FinalProjects/s2004/mtf23/BarcodeScanner/index.htm Ist das was für Dich?
@Marcel Du hattest den Beitrag schon gelesen und auch verinnerlicht? Klaus schrieb: > Einerseits schreibst Du das im Code die Informationen über Kapazität, > Hersteller etc. vorhanden sein sollen, dann aber schreibst Du von "EAN" > (GTIN). > Es ist aber schon klar, dass Du bei Verwendung der GTIN eine externe > Datenbank benötigst um Kapazität etc. aus der GTIN erst zu ermitteln, > oder? Oder die Datenbank ist (zumindest die Public Domain DBs) > potentiell unvollständig oder falsch und daher nicht DAU-sicher. Ist das > soweit akzeptabel für Dich?
Mit dem eintippen kann es aber auch wieder zu Bedienfehlern kommen (falscher Akku zugeordnet). Hintergrund der ganzen Aktion: Die Nummern-Zuweisung der Akkus gibt es schon und funktioniert aktuell so, das wenn die Akkus gekauft werden (was über eine zentrale Stelle geschieht) denen eine eindeutige ID gegeben wird. Protokolliert wird das alles momentan händisch mit Stift & Papier. Und da geschieht genug murks... Wir haben Akkus die Hochstrom-geeignet sind, und andere die Langzeit-geeignet sind. Daher dürfen manche auch mit 2C geladen werden andere nur mit 0,2 C Die Akkus werden in diversen Messgeräten, Datenloggern und Steuerungen als Puffer eingesetzt, welche wiederum im Versuchsbetrieb genutzt werden. Das die ganze Akku-Geschichte protokolliert werden muss ist nicht meine Entscheidung, aber das ganze Loggen soll nun mit dem Laden kombiniert und dadurch vereinfacht werden, daher ID-Barcode und Scanner in irgend einer Form und RFID-Tags sind schlicht zu teuer pro Akku. wenn irgend eine andere Möglichkeit der eindeutigen Erkennung/Markierung günstig zu machen ist, dann bin ich dafür auch offen. @Klaus - Der Link ist einfach genial ! Vielen Dank @Bestromer mit EAN meinte ich nur die Codierung EAN-13 die Nummer auf dem Akku sollte folgendermaßen aufgebaut werden: Zahl 1 bis 6 -> ID 7,8 -> Ladestrom in 100 mA 9-12 Optionscodes Das hier eine DB in irgend einer Form vorliegen muss, die mit die Nummern entsprechenden Daten zuordnet ist klar.
:
Bearbeitet durch User
Marcel P. schrieb: > @Klaus - Der Link ist einfach genial ! Vielen Dank Bitteschön. > @Bestromer > mit EAN meinte ich nur die Codierung EAN-13 > > die Nummer auf dem Akku sollte folgendermaßen aufgebaut werden: > > Zahl 1 bis 6 -> ID > 7,8 -> Ladestrom in 100 mA > 9-12 Optionscodes > > Das hier eine DB in irgend einer Form vorliegen muss, die mit die > Nummern entsprechenden Daten zuordnet ist klar. Ich feiere jetzt mal wieder meinem inneren Erbsenzähler. :-) [Erbsenzählermodus] Du meinst nicht EAN (die heisst inzwischen "GTIN") insofern als diese Bezeichnung auch den Dateninhalt benennt. Vielmehr meinst Du ISO/IEC 15420, die sich auf die physischen Merkmale beschränkt. [/Erbsenzählermodus] Den Unterschied zu kennen könnte zumindest im Gespräch mit Einkaufsleitern/Vorgesetzten etc. ein wenig Eindruck machen. :-) Wenn Du dem Code eine eigene Bedeutung hinterlegst die unter anderem den Ladestrom enthält, dann benötigst Du auch keine Datenbank. Oder verstehe ich da was falsch?
Klaus schrieb: > Ich feiere jetzt mal wieder meinem inneren Erbsenzähler. :-) > > [Erbsenzählermodus] > > Du meinst nicht EAN (die heisst inzwischen "GTIN") insofern als diese > Bezeichnung auch den Dateninhalt benennt. Vielmehr meinst Du ISO/IEC > 15420, die sich auf die physischen Merkmale beschränkt. > > [/Erbsenzählermodus] genau die meine ich... > Den Unterschied zu kennen könnte zumindest im Gespräch mit > Einkaufsleitern/Vorgesetzten etc. ein wenig Eindruck machen. :-) Bei meinem Vorgesetzten hört es beim Ohmschen Gesetzt schon auf... > > Wenn Du dem Code eine eigene Bedeutung hinterlegst die unter anderem den > Ladestrom enthält, dann benötigst Du auch keine Datenbank. Oder verstehe > ich da was falsch? Da ist richtig.. Dann ist mein Quellcode eben die "Datenbank" ;-)
Auf der Basis seiner patentierten Flat Inlay Technologie fertigt SES RFID Solutions robuste und flexible Tags und Karten, die bis zu zu 0,3 Millimeter dünn sein können. Da gehts allerdings um NFC.. hab auch schon so einen flachen gesehen.
Für die Thermo-Labeldrucker gibt es auch Spezialetiketten die abrieb- und wasserfest sind und noch dazu selbst wenn man will fast nciht wieder runter zu bekommen sind. Zum Beispiel zum beschriften von Chemikalien... Bleiben noch schlecht lesende Pens oder Dreck zu lösen!
Die Idee mit dem automatischen Akku-Ladegerät gefällt mir sehr gut! Für Programmierer, die ein paar Bitmuster der Länge 95 Bits und Codes testen wollen, siehe Anhang. Zum oben genannten EAN13-Software-Decoder: https://courses.cit.cornell.edu/ee476/FinalProject... Naja, ob der Softwerker Wyatt Schweizer immer wusste, was er tut? Mit einem 16MHz-Atmega32 schafft er keine zuverlässigen Scans und auch nur UPC-A, bei EAN13 gibt es Probleme. Da gibt es Verbesserungspotential: Ich würde PIN-Change-Interrupt verwenden und die Timer-Ticks messen oder Capture-Mode. Bei seiner Lösung läuft der Timer viel zu langsam. Er schafft nur 2-4 Samples pro EAN-Bit. Because so few samples are taken, there is an interesting problem created by integer math; often the numbers will not work out perfectly and adjustments will need to be made. ... NOTE: Due to error correction considerations, our barcode scanner will only read UPC-A Barcodes, which are a subset of EAN-13 Barcodes. This simplifies one dimension of the encoding allowing for more accurate error correction. ... This immediately suggested the necessity of a state machine driven by a compare match interrupt on Timer1 running as fast as possible, effectively running as software polling. To get optimal performance, we deactivated the register save on both the ISR and the state machine update and designed them such that they used only global variables. Therefore we needed only to save and restore the status register on each call, saving approximately 60 cycles per call. ... Results vs. Expectations: Our results met our expectations reasonably well. We maybe expected a little more consistency with our accuracy, but we did not foresee the limitation on our ability to sample quickly over such small physical features while moving the wand at a steady but quick pace. After realizing we would need to switch to the wand-based scanner, our expectations were lowered. We rebounded well with our error correction schemes and were able to easily meet our adjusted expectations from that point. If we were to approach this problem again we may consider writing in assembly all of the code must be executed on each read. We might first analyze the situation again to be certain that code speed is indeed the problem, considering that there is not too much code that executes on each interrupt. Conformity to standards: We had no difficulty in conforming to the RS232 standard, as it is very straightforward. We were also able to successfully implement our UPC-A standard barcode scanner. Our efforts to internationalize the design for the EAN-13 standard, a superset of UPC-A greatly hindered our accuracy. EAN-13 does not guarantee uniform parity of the left-hand digits, which greatly tied the hands of our error correction algorithm by doubling the set of valid bit strings. Dieser Ansatz gefällt mir ganz gut: Beitrag "Re: Kugelschreiber mit Barcodescanner bei Pollin"
EAN-13 ist (ohne leading- und trailing-zone) immer 95 bit breit: Im Anhang die Beispiele, bei denen man genau sieht, wie decodiert wird. Was mir zum beschriebenen Projekt noch eingefallen ist: Barcode sollte auch von hinten scanbar sein.
Zurück zum eigentlichen Problem: Wenn auch das decodieren eines einfachen Barcodes (z.B. "Code 39") unter optimalen Bedingungen algorithmisch recht einfach ist und sicher auch auf einem Mikrocontroller selber umsetzbar - in der täglichen Praxis gehört etwas mehr dazu und da wirds richtig kompliziert. Dazu zählen z.B. der Ausgleich von Helligkeitsunterschieden (alleine schon durch das Halten), Ausgleich geometrischer Verzerrungen, ungleichmäßig schnelles Bewegen des Stiftes ... da stecken zig Mannjahre drin. Eine mögliche Lösung: Die Helligkeitssignale per MC zum PC leiten, daraus eine Grafik erzeugen und die einer Libary zum decodieren von Barcodes "Zum Fraße vorwerfen" - den Stift quasi nur als 1-Punkt-Kamera benutzen, die durch die Bewegung zur Zeilenkamera wird ... Und um auf die Postings hier davor mal einzugehen, die schon gleich den Aufbau div. Barcodes beschreiben: DAS ist so ziemlich das letzte Problem, was du hast. Erstmal brauchst du einen "sauberen" und verlässlichen Datenstrom bzw. Grafik, so dass mind. 90% aller Scans gleich beim ersten mal decodiert werden können. Wenn du das nicht als Lern- und Bastelprojekt durchziehen willst, sondern das Erzielen eines Ergebnisses wichtig ist, solltest du den Stift unter Lehrgeld verbuchen und dir einen "richtigen" Barcodereader mit USB- oder MC-freundlichem PS/2-Anschluss kaufen, gibts ab 20...30 Euro. Beispiel für 15 Euro: http://www.ebay.de/itm/Manhattan-Barcode-Scanner-CCD-LONGR-PS-2-SG300-/301702170694?hash=item463ed9c846 Und wenn du ca. 40 Euro in de Hand nimmst, bekommst du sogar einen Scanner, der QR-Codes lesen kann. Dann hast du auch bei kleinen Akkus kein Platzproblem (wegen der wesentlich höheren Datendichte). http://www.ebay.de/itm/Honeywell-DataMatrix-4410-LR-2D-QR-Code-und-Barcode-Scanner-COM-USB-Rechnung-/262004172235?hash=item3d00aa65cb
:
Bearbeitet durch User
EAN-Spezialist schrieb: > Barcode sollte auch von hinten scanbar sein. Ich frage mich sowieso ob der Aufwand lohnt. Wahrscheinlich sind 50% der Rundzellen mit dem Etikett nach hinten eingelegt und damit unlesbar. Weiterhin sollte man wissen, daß z.B. manche AA Varta-Akkus nur 1/10 mm dicker sind und schon OHNE Dein zusätzliches Etikett nicht in alle Geräte passen. Wenn Du schon per ttf den Barcode aufdruckst, sollte darunter als Ergänzung in kleiner Schrift eine lesbare Übersetzung dazu stehen. Sonst kann kein Dau das später lesen. Wenn Du es wirklich realisieren möchtest, dann drucke Dir mit dem Laserdrucker über Word einige A4-Blätter mit gewünschten Etiketten in passender Größe aus (Every Nr ..., Zweckform usw.) z.B. https://www.etikettenversand.de/
oszi40 schrieb: > Wenn Du es wirklich realisieren möchtest, dann drucke Dir mit dem > Laserdrucker über Word einige A4-Blätter mit gewünschten Etiketten in > passender Größe aus (Every Nr ..., Zweckform usw.) z.B. > https://www.etikettenversand.de/ Sorry, aber das ist ziemlicher "Büro-Hengste-Pfusch", kommt gleich nach dem handbeschrifteten Heftpflaster. Wenn die Barcodes oder QR-Codes eine Weile lesbar sein sollen (also professionell), so druckt man die auf Vorrat bei einem Dienstleister auf lösungsmittel- und wasserfeste selbstklebende Vinylfolie ... ist auch dünn genug.
:
Bearbeitet durch User
Frank E. schrieb: > Wenn die Barcodes oder QR-Codes eine Weile lesbar sein sollen (also > professionell), so druckt man die auf Vorrat bei einem Dienstleister auf > lösungsmittel- und wasserfeste selbstklebende Vinylfolie ... ist auch > dünn genug. So was Aehnliches hatt ich auch mal getestet. Allerdings werdenAkkus beim Laden auch warm, manchmal auch sehr warm. Da waren dann die Aufkleber sehr schnell wieder ab und ich habe das Ganze aufgegeben. wendelsberg
Frank E. schrieb: > ziemlicher "Büro-Hengste-Pfusch" > lesbar sein sollen (also professionell), Mein Profi >1000€ Etikettendrucker (Thermotransferverfahren) hat wunderschöne silberne Etiketten erzeugt. Leider haben auch diese nicht den Abrieb widerstanden. Daher Aufwand und Nutzen abwägen und mit Laseretiketten erst mal anfangen. Im einfachten Fall: Kopierpapier und Tesafolie drüber. Steigern könnt Ihr Euch immer. Es gibt A4- Papier-, Plaste-, Metall-Etiketten. Zur Übung reicht Papier+Tesa!
Frank E. schrieb: > dir einen "richtigen" Barcodereader > mit USB- oder MC-freundlichem PS/2-Anschluss kaufen, gibts ab 20...30 > Euro. Schliesse mich an, bei den Dingern brauchst du nicht mal Software: die geben den Text des Barcodes ein, als ob er auf der Tastatur getippt worden wäre, auf Wunsch plus CR. Z.B. in ein Windows-Eingabefeld klicken und auf den Knopf der Pistole drücken, da steht der Code. Hat sich bei uns im Firmeneinsatz bewährt (Auftragszettel einlesen). Die Stifte sind eigenlich längst ausgestorben, selbst mit Auswerteelektronik. Da hast du jemandem eine grosse Freude gemacht, dass er sein altes Zeug noch losgeworden ist. Georg
Die STifte sind old-school (hatten wir schon vor 30 Jahren in der Hand). Die Decodierung per Software war schon damals eine Aufgabe für das Semester, ist nicht so schwer. Timer laufen lassen und die Zeiten hell und dunkel speichern. Dann die Anfangs-Balken auswerten und die Timergrenzen setzen und nach jedem erkannten Balken (dünn, dick) wieder neu justieren... Die Scanner mit PS/2-Anschluß konnten wir nicht nackt an einen PC anschließen, die brauchen auch eine angeschlossene Tastatur als Taktquelle. Die COM-Dinger sind OK, wundert mich, daß es die so billig gibt. Als Etiketten sieh dir unbedingt die P-Touch-Systeme von Brother an. Hab mir gerade für ca. 50€ einen PT-2100 geholt, der druckt auch Barcode und die dünnen aber laminierten Etiketten kleben wie "Scheiße am Handtuch".
Bernd R. schrieb: > Als Etiketten sieh dir unbedingt die P-Touch-Systeme von Brother an. Hab > mir gerade für ca. 50€ einen PT-2100 geholt, der druckt auch Barcode und > die dünnen aber laminierten Etiketten kleben wie "Scheiße am Handtuch". Genau das hatten meine nicht gemacht. Kalt schon, aber bei ca. 60-80° nicht mehr. wendelsberg
>> kleben wie "Scheiße am Handtuch" WO? Auch auf kleinen Radien wie bei AAA? > Genau das hatten meine nicht gemacht. > Kalt schon, aber bei ca. 60-80° nicht mehr. Alte Boeder-Papieretiketten kebten auch ewig. Kleben garantiert leider noch nicht, daß sie ewig LESBAR sind. Was nützt uns ein Etikett ohne Schrift? Wahrscheinlich ist die ganze Mühe für die Katz.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.