Ein Wägelchen, das auf einer Edelstahlschiene fährt, soll gelegentlich seine Position über einen Barcode übermittelt bekommen, der von eben dieser Schiene abgelesen werden soll. Der Barcode soll sich im sichtbaren Bereich befinden und per Laser eingebrannt sein. Der Lesekopf sollte möglichst klein sein. Leseabstand ca. 5 mm +3 -2. Der Barcode muss vorwärts wie rückwärts gelesen werden können. Mit der Anfangs- bzw. Endemarkierung soll dann der Positionsimpuls generiert werden. Gibt es da was Fertiges?
Es gibt die üblichen Auto-ID Hersteller die Barcode-Leser als Baugruppen liefern bzw. anpassen oder neu entwickeln: eventuell zu teuer.
Selbermachen auch möglich, ist ja letztlich selbstgebauter Barcode-Lesestift. Es gab ehedem sowohl Reflexsensoren als auch 8051-Controller mit Masken-ROM als Decoder für gängige Barcodes von HP. (
formatting link
der Text ist aber unfertig ) Die Controller waren aber in Einzelstückzahlen bei $40 und die Sensoren ca 100DM: Verbreitung gering. Zudem wurde/wird der Optoelektronik- bereich von HP schrittweise aber vollwirksam abgewickelt. Den Controller kann man offensichtlich selber programmieren. Für den Barcode würde man sich an was gängigem orientieren, z.B. Code 2/5 interleaved. Bezüglich Reflexsensoren: alte Beiträge dazu in dieser newsgroup mit "barcode" googlen, das Thema taucht sporadisch auf.
Gray-Code wäre ja was, um direkt und absolut die Wegstrecke abzumessen. Das wäre im konkreten Fall aber mit Kanonen auf Spatzen geschossen. Die Gleisverlegung würde an den Stößen in einen aberwitzigen Aufwand ausarten. Das sollen aber auch geübte Laien hin kriegen. So ungefähr weiß der Antrieb ja aufgrund seiner Antriebsimpulse wo er sich grade befindet. Weil der Antrieb allerdings Schlupf und diverse Nichtlinearitäten hat und Bögen fährt, braucht er hin und wieder mal einen Meilenstein zur Orientierung. Da sollte ein Barcode eigentlich reichen. Vorteil: Man hat einen riesigen Zahlen- und Zeichenvorrat und kann deshalb jedes Gleisstück schon in der Fabrik individualisieren. Einmal die damit gebaute Strecke abgefahren kann man jedem Gleisstück einen bestimmten Ort zuweisen, von dem aus die Motorsteuerung dann weiterzählen kann.
Aber bei dieser Anwendung würde ich wohl auf die übliche Barcodes verzichten. Denn: Du willst nach der sonstigen Beschreibung deiner Absichten zu urteilen doch keinen einfachen "Positionsimpuls" sondern ein Datagramm mit den gelesenen Positionsdaten, oder? Wenn Datagramm, dann muß es wiederum irgendwas geben, was dieses Datagramm verarbeitet, ist ja logisch.
Dieses ominöse Etwas kann dann aber genausogut gleich die Rohdaten eines eigenen, speziell für den Zweck geschaffenen Codes verarbeiten. Dann reduziert sich der "Lesekopf" nämlich auf eine gängige Reflexlichtschranke. Kleiner und billiger geht kaum.
Natürlich kann so eine Lösung auch die Daten eines üblichen Barcodes verarbeiten. Dann ist halt ein entsprechender Decoder zu schreiben. Was man bei der Hardware spart, steckt man in die Software. Die schreibt man allerdings nur einmal, Hardware hingegen müßte für jedes Exemplar des Wägelchens neu gekauft werden. Die Kostenbilanz wird also nach n Wägelchen zugunsten der Softwarelösung kippen. Bei Wahl eines "günstigen" Codes und einigermaßen brauchbarer Programmiererfahrung dürfte n sicher im einstelligen Bereich liegen.
Logisch, wenn du mit "Datagramm" individualisierte Daten auf den Gleisstücken meinst. Dazu vgl. Antwort auf Falk.
Spricht nichts dagegen. Aber wieso sollte ich einen Code entwickeln, wenn es schon fertige gibt?
Das war auch meine erste Idee. Allerdings fehlt mir in Sachen Barcode die nötige Erfahrung, weshalb ich nach was Fertigem gefragt habe. Was mir da nicht klar ist - WIE werden die dicken und dünnen Balken überhaupt unterschieden? Kann man das mit einer einzigen Reflexlichtschranke sicher genug hin kriegen? Wird da also nur die Helligkeit eines Messflecks bestimmter Größe ausgewertet? Oder müssen es zwei oder gar drei Reflexlichtschranken sein? Oder am Ende sogar richtige Laser-Linienscanner? Letzteres glaube ich nicht so recht, weil es sonst keine Lesestifte geben dürfte. Wie das mit den unterschiedlichen und auch nicht unbedingt konstanten Lesegeschwindigkeiten im Detail organisiert wird, weiß ich auch nicht. Daher meine Unsicherheit mit diesem Thema. Die dicken und dünnen Balken könnten ja auch über das Zeitverhalten einer Lichtschranke ausgewertet werden. Welche Anforderungen sind dann an die Ziehgeschwindigkeit zu stellen? Wie weit darf man von der Konstanz abweichen? Wie schnell darf man drüberziehen? Geht's mit 1,5 m/s noch? Oder braucht man dazu dann schon wieder irgendwelche teuren Edelbauteile? Oder muss man einfach langsamer fahren?
Da es die Barcodes schon eine Weile gibt, hoffe ich doch, dass es solche Teile auch schon in preiswert gibt. Ich komme eher aus der mechanischen Ecke (Feinwerktechnik) und möchte mich mit der Elektronik nicht in den letzten Details verlieren. Lichtschranke mit Decoderchip und Daten an RS232 - so etwas könnte mir gefallen.
Insofern praktisch, als ja auch ein Computer mitfahren soll. Aber wie gesagt - das mit der Signalaufbereitung ist mir noch nicht so recht klar. Auf CPU-Ebene zu programmieren ist auch nicht grad mein Ding. Hochsprachen sind mir da allemal lieber.
Der Grund für einen selbstgebauten Code ist mir nicht recht klar. Wieso das Rad neue erfinden?
beides in einem wirst du nur für teures Geld bekommen. Nimm einen Barcodelesestift mit RS232 und einen Sensor (Licht, Mech. Kontakt, magnetisch) für die Positionsmarkierung. Oder einen Scanner und Code quer zu Fahrtrichtung.
Um ihn für den konkreten Zweck optimieren zu können und nebenbei noch Kosten zu sparen.
Das wäre schon die erste Optimierung: Natürlich würde man in deinem Fall einen Code wählen (oder selbst gestalten), der mit einer einzigen Balkenbreite auskommt. Die eigentliche Information steckt dann im Abstand zwischen diesen Balken.
Definitiv ja. Ich habe eine recht ähnliche Geschichte schon einmal realisiert.
Im Prinzip ist das so. Die Information steckt im zeitlichen Verlauf dieser Meßgröße.
Siehst du, das ist schon die erste Möglichkeit zur Optimierung. Wenn alle Balken gleich breit sind, läßt sich aus dem Signal selber die Information entnehmen, die zur Kompensation einer variablen Scangeschwindigkeit nötig ist. Einige existierende Barcodes machen es übrigens exakt genauso.
Die Verarbeitung der Daten kann natürlich in einer beliebigen Hochsprache erfolgen.
Wichtig ist eigentlich immer nur, daß die Erfassung der Daten in einer Umgebung mit definiertem Zeitverhalten geschieht. Naturgemäß hilft eine maschinennahe Sprache dabei, das sicherzustellen, ist aber nicht unbedingt notwendig. Unbedingt notwendig ist hingegen ein echtzeitfähiges Betriebssystem. (oder alternativ: die Abwesenheit eines Betriebssystems)
Weil es Kosten spart.
In unserer verrückten Welt sind leider nicht nur konkrete Implementierungen durchs Urheberrecht geschützt, sondern sogar naheliegende Anwendungen allgemein bekannter physikalischer Gesetze, sofern bloß mal irgendwann irgendein blasser Typ sich deren Anwendung für einen konkreten technischen Zweck hat patentieren lassen. Glücklicherweise kann man solche Patente relativ erfolgreich dadurch umgehen, daß man es halt ein klein wenig anders macht als der Patentinhaber und gleichzeitig den technischen Zweck etwas anders formuliert.
Was sollte ich denn da noch optimieren wollen? Ich brauche nur eine Identifikation zu lesen, was ich für ganz normalen Standard halte. Ist sie gelesen, gibt es einen Impuls, der der Motorsteuerung dann mit Infos aus der Datenbank quasi die Feintrimmung mitteilt. Außerdem: WELCHE Kosten sollten mit einem selbst erfundenen Code gespart werden können? Sind für die Benutzung gängiger Codes etwa Lizenzen zu bezahlen?
Wenngleich überlegenswert, kann ich leider keine besonders konstante Lesegeschwindigkeit garantieren.
Klingt schon mal ganz interessant.
Bei gängigen Codes aber wohl nicht nur. Sonst wären unterschiedlich dicke Striche ja sinnlos.
:-)
Demnach brauche ich doch gar nichts neue erfinden oder implementieren.
Die Verarbeitung ja. Aber erst mal müssen die Daten irgendwie in den Computer rein.
Eben. Wenn es um definiertes Zeitverhalten geht, habe ich schon diverse üble Erfahrungen hinter mir. Die schreien nicht grade nach Wiederholung. Mir wär's am liebsten, wenn's einen Chip gäbe, an den wird eine Reflexlichtschranke angeschlossen und hinten purzeln die fixfertigen Daten normgerecht an einer RS232 runter plus einem Impuls, wenn der Code fertig gelesen ist. Der geht direkt an die Motorsteuerung, die dann sagt, wo sie zum Zeitpunkt des Impuls grade war. Per Datenbankabgleich kann der Computer dann seine Korrektur ermitteln.
Ist das Verfahren, wie ich es mir ausgedacht habe, schon patentiert? Sind deshalb Lizenzgebühren auf Barcodes fällig? Das wäre natürlich übel. Kann ich mir kaum vorstellen.
Bessere Anpassung an die Lösung, aber man muß dann eben den Controller selber programmieren. Allgemein: Es gibt Codes mit 2 Strichbreiten aber auch welche mit 3 und 4 Breiten: wenn die Bewegungsgeschwindigkeit sehr konstant wäre, sind letztere kompakter. Der Code braucht links und rechts eine weisse Ruhezone die typisch 10x der dünnsten Strichstärke entspricht. Innerhalb kommen links und rechts die Start- und Stopzeichen, damit man Leserichtung bestimmen kann. Im Kern ist von Startzeichen aus gesehen der Datenteil gefolgt von einer Prüfsumme. Prüfsummen sind bei Barcodes traditionell mau, keine CRCs. Bei einem selbstgestrickten Code der wenig Daten enthalten muß kann man das alles zusammenwursteln, sodaß Fehlererkennung/Korrektur besser wird.
In einem Lesestift genügt es. Der kommt auch mit Umgebungslicht klar, hat allerdings eben direkten Kontakt. Würde man versuchen Umgebungslicht durch Takten des LEDs wegzubekommen hat man bald mit Geschwindigkeit, Grundrauschen Probleme.
Anderes Problem: können Codes und Lesekopf verschmutzt werden ? Das ist für optisches System genau so lästig wie Umgebungslicht. Es gab immer auch magnetische Lösungen ( vgl. Magnetstreifenkarten, magnetische Tinte für E13B "OCR"-Systeme und auch magnetische Barcodes ) wegen des Schmutzproblems. Das sind dann aber fast zwangsläufig Köpfe mit direktem Kontakt.
Softwareproblem, nicht sosehr kritisch. Vorausgesetzt die Signalaufbereitung war ok. Typische Schaltungen:
formatting link
D.h. mit Geschwindigkeit und Abstand moduliert man auch die Amplitude des Signals. Man braucht deshalb zwei Spitzenwert- detektoren die die Schwellen des Schmitt-Triggers nachführen. Man kann das Signal heutzutage auch per A/D-Wandler einlesen und die Funktionen in Software ausführen.
Für Stifte je nachdem wie selbstbewußt der Hersteller ist: 34 - 3700mm/sec bis 80 - 800mm/sec
Wenn man unbedingt ein Muster für Demonstrationszwecke aufbauen will: in geringen Mengen habe ich noch HBCR1611 Controller und HBCC1580 Lichtschranken:
formatting link
Stammen von ebay, kann ich preiswert abgeben. Wie man im Datenblatt sieht haben die eine Brennweite von 4mm die vorzugsweise nur +/-0,5 schwanken sollte. Das ist also etwas anderes als "5 mm +3 -2" Es ist allerdings die Frage, ob bezüglich Strichbreite wirklich die Werte für Lesestifte erreicht werden müssen. Die HP-Teile erreichen Auflösung die man mit selbstgestrickter Lichtschranke nicht erreicht, sind aber teuer und obsolet.
Soll das Ding irgendwann mal in Serie gefertigt werden ? Dann wäre es wohl angemessen sich mit jemand zusammenzutun der mit Schaltung & Controller weniger Berührungsängste hat.
an so etwas in der Art habe ich gedacht. die sind mir aber zu lang. Ich brauche ja nur das Ding vorne drin im Stift. Ist ja keine Hand da, die das Teil ergonomisch greifen müsste.
Verstehe ich nicht ganz. Beim Einkaufen piepst es doch immer, wenn ein Code gelesen ist. Genau diesen Pieps-Impuls könnte man doch abgreifen. Wozu dann noch ein extra Sensor? Die Fahrtrichtung ist bekannt. Ist die Codelänge bekannt, kennt man auch die absolute Position.
Bei der Gelegenheit: Ich gehe davon aus, dass die Codelänge in mm konstant ist. Wenn nicht, dann wär's zumindest interessant, um wie viel der Code etwa flattern dürfte und ob's einen einfachen Algorithmus zur Längenbestimmung gibt.
Da ich sozusagen allen Platz der Welt habe, ist dann wahrscheinlich der mit den 2 Strichbreiten der bessere. Richtig?
Das sollte kein Problem sein.
Das überrascht mich jetzt. Dachte eigentlich, dass eben das eine große Stärke dieser Codes wäre. Diese werden schließlich täglich milliardenfach gelesen.
Was ist das denn?
15 Zeichen sollten reichen.
Man könnte doch einfach eine kräftige Lichtquelle verwenden, die alles überstrahlt. Direkt in der prallen Sonne wird's nicht liegen. Und auf die paar Millimeter Distanz sollte eine LED schon für ordentlich Beleuchtung sorgen.
Halte ich eher für ein theoretisches Problem. Und wenn doch, dann ist das Teil leicht zu reinigen.
Kann ich mir gut vorstellen.
Von magnetischer Tinte für diesen Zweck habe ich noch nichts gehört. Kenne magnetische Flüssigkeiten nur im Zusammehang mit elektroviskosen Kupplungen oder zu hermetischen Abdichtung von Wellendurchführungen. Muss die erst noch aufmagnetisiert werden oder wird die einfach nur (dann auch sichtbar) auf die Unterlage gedruckt?
Das wäre angesichts der langen Verfahrwege und Edelstahlunterlage nicht so toll. Auf dem Zeug sieht man ja jeden Kratzer.
Klingt, als müsste es fixfertige Chips geben, die das alles schon können. Du hast mir doch schon einen Link genannt. Ist nicht der dort angegebene HBCR 161x von HP so ein Ding?
Klingt ja für meine Zwecke gradezu ideal.
Bin dran interessiert! Vor allem, wenn das Zeug auch künftig lieferbar ist für denn Fall, dass eine Serie draus wird.
Ich habe keine Ahnung, von welcher Preisregion da die Rede ist. Schickst du mir mal eine Ahnung?
Na ja - Brennweite hat nicht unbedingt was mit dem Leseabstand zu tun. Mit 50 mm Brennweite kann man ganze Bergketten fotografieren. Die sind etwas weiter weg als nur 50 mm. Wenn der Sensor im Fokus liegt, dann ist das Ding auf "unendlich" gestellt. Ist er weiter von der Linse weg, ist er wahrscheinlich für den Nahbereich focusiert. Ist der Sensor recht klein, ist die Tiefenschärfe wahrscheinlich hervorragend. Dann reicht's, wenn der Code irgendwo in der Nähe rumschwirrt und die Lage wäre ziemlich unkritisch. Mit nur 4 mm Brennweite stehen die Chancen zumindest schon mal ganz gut.
Da stehe ich mangels Erfahrung ziemlich neben der Spur.
Ist ein selbst gestelltes Projekt, das ich sporadisch immer wieder beackere. Nun ist die Hardware langsam konstruiert, so dass allmählich auch die Elektronik wichtig wird. Wenn die Chose dann gut genug funktionieren sollte (was ich doch schwer hoffe), werde ich versuchen, das Teil in die Serie zu kriegen. Am Besten mit Lizenzen. Aber auch eine Firmengründung ist nicht ganz ausgeschlossen. Spätestens dann werde ich hier im Forum mal nachhaken, ob wer mitmachen will. Da ist aber noch etwas hin. Es sei denn, dass jetzt schon wer - allerdings bis Geld sprudelt unbezahlt - einsteigen will. Das aber dann bitte über Mail.
Genau so ist es. Die Hardware ist allerdings noch nicht ganz fertig. Aber jetzt brauche ich halt die Baumaße für den ganzen elektrischen Krams. So ein Handscanner aus dem Baumarkt ist dafür definitiv zu groß.
Es sind die robusteren eben. Eigentümlich ist bei denen dass die Strichstärken nicht 1:2 sondern 1:2-3 variieren kann. Damit derjenige der sie druckt die Breite des gesamten Codes relativ konstant halten kann.
Optische Barcodes haben unten für Menschen leserbar den Inhalt als Ziffernfolge ausgedruckt. Das schränkt die Möglichkeiten beim Entwurf ein. Neue 2D-Barcodes sind nur noch maschinenlesbar da ist die Fehlersicherung auch etwas moderner.
Relativ sichere Prüfsumme wie man sie sonst heutzutage durchwegs verwendet. Braucht allerdings wenigstens 12 Bit und das ist für Barcode schon zu üppig, wären ja ca 3 BCD Zeichen.
Die E13B wurde in den 60er Jahren in den USA eingeführt und das war eine Tinte mit Metallpartikeln die dann auf die Schecks als Seriennummer gedruckt wurde. Sie wurde erst vom Lesegerät unmittelbar vor dem Lesevorgang magnetisiert und dann mit Köpfen wie bei Tonband gelesen. Meines Wissens gibt es heute Längenmeßsysteme basierend auf Metallstäben die lokal magnetisiert werden und dann von Leseköpfen abgetastet werden können. Für Festplatten gibts heute ja sehr empfindliche und kleine magnetische Köpfe vgl. GMR. Es gab schon in den 60er Jahren den Vorschlag die Metallwände von Kipploren-Waggons in Bergwerken lokal zu magnetisieren und dann wie Barcode auszulesen. Das wäre aus etwas Entfernung geschehen, vermutlich mit fluxgate, das war damals das empfindlichste was verfügbar war. Von der Firma Victor Rehm ( Stanzteile ) wurden auch mal magnetische Barcodes angekündigt die man z.B. in Skis mit einbauen könnte. Solche Ideen sind nicht schlecht aber durch RFIDs inzwischen chancenlos.
Ich bin mir da eben nicht sicher ob man das lokal dauerhaft magnetisieren kann. Dünne Hartmagnete bzw. Gummimagnete ( also Metallpulver in Gummi ) die man als Label aufkleben könnte wären vermutlich schon möglich. Dreck und Umgebungslicht ist man dann los, aber Aufwand steigt.
Der tut das für gängige Codes klaglos. Hab ich hier als Breadboard aufgebaut und soll als Referenzsystem bezüglich Lesesicherheit für meine eigene Implementierung dienen.
Die beiden sind für Prototypen ok, etwa 5 liegen hier rum, aber für Serie chancenlos.
Nur der Oldtimer HBCS-1100 scheint alle seine Nachfolger zu überleben:
formatting link
Hab ich hier noch einen rumliegen.
Bei Farnell ist der anscheinend 35 EUR / 1Stück. Deshalb sollte man sich die HP nur nehmen, wenn man die Auflösung wirklich braucht. Sonst ist Selbstgestricktes bei weniger Auflösung billiger.
Die Decoder-ICs sind alle schon sanft entschlummert:
formatting link
Die sind aber leicht durch eigenen Controller ersetzbar.
Solange es nur um einzelne Prototypen geht und es nicht zu eilig ist habe ich damit kein Problem, weil das Material ja schon lagert.
Tja, umgekehrt braucht man für Muster des Lesekopfs auch
Abmessungen.
Angaben zur Stromversorgung: letztlich 5V. Controller verheizt 25mA, Sensor 35mA ( max wäre 100mA da machts das LED aber wohl nicht lange )
Schnittstelle: aus dem Controller kommt mit 5V Pegel V24-Signal Klartext mit wahlweise 1200 / 2400 / 4800 / 9600 Baud. Kann ich optional noch Pegelwandler reinpfriemeln, damit man es auf PC an Terminalprogramm ansehen kann. Mal Zeichnung, machen was die Wunschabmessungen sind und auf Webseite stellen. Soweit nicht öffentlichkeitsfähig link darauf per mail schicken.
Ich habe den Thread verfolgt und möchte einfach mal eine andere Idee loswerden ;-) Die optische Abtastung eines Barcodes könnte je nach Umgebungsbedingungen störanfällig sein (Nässe, Verschmutzungen, Fremdlicht).
Mein Vorschlag wäre, zur Positionsbestimmung einfach vergossene RFID Chips auszulesen, die an bestimmmten Stellen des Fahrweges angebracht sind. Ob die Dinger im Fussboden vergossen oder in die Schiene eingelassen werden können, weisst Du natürlich besser als ich. Mit jedem Chip hättest Du eine eindeutige Identifikation des Messpunktes, berührungslos und unempfindlich gegen Verschmutzungen einer Optik etc.
Nur so eine Idee... wenns nicht passt, vergiss es einfach ;-)
Viele Grüße
Kai
--
Die Mailadresse wechselt jedes Quartal nach
dem Muster usenetQQYYYY@kai-ebersbach.de
Ist doch prima. Genau nach so etwas suche ich doch. Dann lässt sich das Ganze auch gestalterisch noch gut platzieren.
Selbst wenn der Code 20 cm lang werden sollte, wäre das noch kein technisches Problem. Wie's dann mit dem Design aussieht - mal sehen.
Mit magnetischer Tinte kenne ich nichts dergleichen. Ich kenne Metallbänder, Stangen und "Plastikmagnete", die zu Messzwecken verwendet werden.
Die allerdings mit nicht mal Haaresbreite über die abzutastende Oberfläche fliegen. Für meinen Einsatzfall ist das jenseits jeder Diskussion.
Es gibt spezielle Sorten mit denen das geht.
Aber gestalterisch nicht der große Hit. Das Ganze soll ja auch was her machen.
Wieso chancenlos für die Serie? Zu teuer? Abgekündigt?
formatting link
Welcher? HBCS-1100 oder HBCR1611?
Klingt, als könnte man Sebstgestricktes verwenden. Nur bin ich mit elektronik selberstricken nicht grade der große Zampano.
formatting link
Wie gesagt - mit hardwarenaher Programmierung hab' ich's nicht so.
Eilig ist die Sache im Moment wirklich noch nicht. Die Mechanik ist noch nicht fertig und damit könnte ich das Ganze jetzt sowieso noch nicht ausprobieren. Der ganze Klapperatismus war eine deutlich härtere Nuss, als ich anfangs ahnte. Aber nun weiß ich wenigstens, weshalb es Vergleichbares offenbar noch nicht zu kaufen gibt. Wo sitzt zu eigentlich? Könnten wir uns mal treffen?
Eben. Drum habe ich ja mal angefangen zu posten, weil mir Handscanner einfach zu groß sind.
Das sollte kein Problem sein. Netzteil muss auch noch definiert werden. Speisung 42 V AC, ca. 300 Watt auf 12 und 24 DC aufgeteilt. Dann müssen eben auch noch 5 Volt abgegriffen werden.
In einen PC muss das Gelesene auf jeden Fall rein.
Für den Sensor gilt: Je kleiner, desto eleganter sieht's aus. Daran kommt ein Kabel, das ca. 200..250 mm in einem relativ großen Bogen zum PC überbrückt. Da könnte man auch ein kleines Platinchen gut unterbringen. Aus Platzgründen wäre mir eine Computerkarte am Liebsten, die man einfach auf eine Backplane steckt. Aber da ist noch alles offen.
Störungen dieser Art sollten eher unwahrscheinlich sein. Fremdlicht vielleicht. Aber auch nicht üppig.
Ich fürchte, dass damit die Positionsgenauigkeit weit unter der von Barcodes liegt, weil die RFIDs ja für das Auslesen aus großer Distanz ausgelegt sind.
Bis Code und Piepser bei dir ankommen ist schon etwas Zeit vergangen. Diese Zeit muss nicht konstant sein. Der Piepser zeigt dir an, dass der Code erfolgreich dekodiert wurde und keine Position.
Das Problem ist in diesem Fall, daß die Bewegungsgeschwindigkeit sich zwar entlang des Codes in weitem Bereich kontinuierlich ändern kann, aber bezogen auf die Länge von einzelnen Strichen näherungsweise konstant bleiben muß. Deshalb kann man die Strichbreiten nicht fingerdick breit machen, nur weil die Sensoren schlechte Auflösung haben. Bzw. das Fahrzeug sollte sich nicht beliebig langsam bewegen.
Beides. Aber für Prototypen eben noch gut genug.
HBCS-1100: der einzige noch gefertigte Sensor von HP. Die Controller sind ohnehin abgekündigt.
a) Man kann im Kopf nur den Sensor haben, braucht aber trotzdem dort kleine Leiterplatte weil man den ersten Verstärker-Op direkt am optischen Sensor haben muß. Der Rest der Analogschaltung und Controller müsste dann irgendwo anders untergebracht werden. Zusätzliches Verbindungskabel hat dann Signale: 5V, GND, Aout, LED
b) man baut in den Kopf Sensor und Controller ein: 2 Boards gleicher Grösse die aufeinander gesteckt werden: Sensor & Analogschaltung und Controller. Im Seriengerät kann das eventuell auf 1 Leiterplatte reduziert werden, wenn man SMD verwendet. Verbindungskabel ab Controller wohl: 12-24Vdc, GND, V24-out Man bräuchte geschätzt die gewünschten Kantenlängen um zu wissen was von beiden gangbar ist. Sowie wie der Kopf befestigt wird. Offensichtlich wäre mechanischer Abgleich der die Brennweite miteinstellt wünschenswert.
Wenn man hohe Vorspannung ( >12V ) hat, kann man für das Sensor-LED Schaltregler machen. Das vermeidet unnötige Verlustleistung. Wenn man >>10kHz taktet stört der Ripple den Barcode nichtmehr. Der Controller kann in Seriengerät auch bei 5mA liegen. Meist ist lokale Erzeugung der 5V mit z.B. 78L05 angebracht, man will saubere 5V für den Analogteil will.
Germering = München/West. Am Monatsende ( 4. Mittwoch im Monat ) verschlägt es mich manchmal geringfügig nordwärts nach Oberschleißheim zum Stammtisch der örtlichen FORTH-Gruppe ( Programmiersprache speziell für Controller ). Ist aber nicht sicher ob sich das diesen Monat ausgeht. November wahrscheinlicher.
Metall verträgt sich nicht gut mit 125kHz Transpondern. Halbwegs geeignete Bauformen ( d.h. Ferritkern mit Spule ) sind ausserdem nicht wirklich billig.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.