Hallöchen, es wird langsam ernst (Vorläufer-Thread: Beitrag "Gesucht: Optischer Sensor f. absolutes Taktlineal (encoder stripe)") Ich suche jetzt ein Programm, das mir Taktlineale (encoder stripes) beliebiger Länge und Auflösung erzeugt, ebenso wie linearen Gray-Code. Unter Inkscape gibt es die sehr schöne Extension "Inkscape rotary encoder generator", aber eben leider nur für Drehgeber, nicht für lineare Geber. Vielleicht kennt ja jemand eine Extension für Inkscape oder auch ein anderes Programm (PS-Generator etc.), das mir vektorielle Grafiken solcher Lineale liefert? Ansonsten würde ich mich als Python-Laie wohl oder übel selbst drangeben müssen, und die Extension umzustricken versuchen. Zuerst aber hoffe ich mal auf Euch :-) Besten Dank für jeden Hinweis!
:
Bearbeitet durch Moderator
Chris D. schrieb: > das mir vektorielle Grafiken > solcher Lineale liefert? Ein Greycode wird ja um ein Bit erweitert, indem man den vorhandenen spiegelt und drankopiert, und das zusätzliche Bit in der Kopie auf 1 setzt. Das lässt sich ja auch in einem Grafikprogramm leicht machen, so dass man z.B. aus einer Basiszeichnung mit 5 bit durch 5 Kopieraktionen einen 10bit-Code machen kann. Natürlich hat so ein linearer Greycode auch seine Probleme: z.B. um 1 m in 0,01 mm Schritten aufzulösen, braucht man 17 bit. Mechanisch ist es schon sehr anspruchsvoll, 17 Spuren auf 1 m Länge exakt abzutasten, wenn sie nicht gerade mehrere mm breit sind. Georg
Weiß ja nicht, willst du das dann ausdrucken? Du kannst dich auch ggf. einfach drauf besinnen, dass PostScript ja eine Programmiersprache ist. ;) Regelmäßige geometrische Strukturen sollten damit kein großes Problem sein. Vor reichlich 20 Jahren habe ich bei den GUUG-Frühjahrsgesprächen mal einen Vortrag zu PostScript als Programmiersprache gehalten … Anbei etwas, was aus dieser Zeit noch übrig ist. (Den Vortrag selbst finde ich gerade nicht mehr.)
Georg schrieb: > Ein Greycode wird ja um ein Bit erweitert, indem man den vorhandenen > spiegelt und drankopiert, und das zusätzliche Bit in der Kopie auf 1 > setzt. Das lässt sich ja auch in einem Grafikprogramm leicht machen, so > dass man z.B. aus einer Basiszeichnung mit 5 bit durch 5 Kopieraktionen > einen 10bit-Code machen kann. Ja, das ist soweit klar. Aber es sollte schon automatisiert ablaufen. > Natürlich hat so ein linearer Greycode auch seine Probleme: z.B. um 1 m > in 0,01 mm Schritten aufzulösen, braucht man 17 bit. Mechanisch ist es > schon sehr anspruchsvoll, 17 Spuren auf 1 m Länge exakt abzutasten, wenn > sie nicht gerade mehrere mm breit sind. Ja, aber so eine hohe Auflösung kommt für meine Anwendungen eh nicht in Frage - da steht schon das Spiel der Schlitten dagegen. Ich werde vermutlich auch mit inkrementellen Gebern beginnen, um erstmal die mögliche sichere Auflösung zu ermitteln. Jörg W. schrieb: > Weiß ja nicht, willst du das dann ausdrucken? Jepp :-) > Du kannst dich auch ggf. einfach drauf besinnen, dass PostScript ja eine > Programmiersprache ist. ;) Regelmäßige geometrische Strukturen sollten > damit kein großes Problem sein. Vor reichlich 20 Jahren habe ich bei > den GUUG-Frühjahrsgesprächen mal einen Vortrag zu PostScript als > Programmiersprache gehalten … Anbei etwas, was aus dieser Zeit noch > übrig ist. (Den Vortrag selbst finde ich gerade nicht mehr.) Ja, ich hatte gestern noch einige Beispiele im Netz zu PS gefunden, aber mich dann doch für eine gruselige Quick n' dirty - Lösung via Tcl/Tk entschieden. Dort kann man ja auch PS exportieren :-) Trotzdem Danke für die Hinweise.
Moin, hat sich zufällig schon jemand mit diesem Barcode beschäftigt? http://www.ebay.de/sch/i.html?_from=R40&_nkw=barcode+latte&_sacat=0
MaWin schrieb: > Was zahlst du für so ein Programm? Nichts :-) Wie oben geschrieben habe ich mir das schon selbst zusammengehackt. hp-freund schrieb: > Moin, > hat sich zufällig schon jemand mit diesem Barcode beschäftigt? > > http://www.ebay.de/sch/i.html?_from=R40&_nkw=barcode+latte&_sacat=0 Interessante Anwendung. Das kannte ich noch gar nicht. Bei Wikipedia steht allerdings, dass solche digitalen Nivellierlatten "mit einem Invarband ausgestattet sind, auf denen ein herstellerspezifischer Binärcode aufgetragen ist". Offenbar gibt es da keinen allgemein verwendeten Code.
Chris D. schrieb: > herstellerspezifischer Binärcode Das heißt aber doch auch das es mehrere Möglichkeiten gibt, oder? Mit dem Niv wird damit automatisch Höhe(Position auf der Latte) und Entfernung registriert. Ich denke da an so einen: http://de.rs-online.com/web/p/fotodetektor-arrays/7857692/ der über den Barcode gleitet.
hp-freund schrieb: > Das heißt aber doch auch das es mehrere Möglichkeiten gibt, oder? > Mit dem Niv wird damit automatisch Höhe(Position auf der Latte) und > Entfernung registriert. > > Ich denke da an so einen: > > http://de.rs-online.com/web/p/fotodetektor-arrays/7857692/ > > der über den Barcode gleitet. Ja, so etwas in der Art hatte ich ja in dem anderen Thread gesucht, allerdings direkt für Gray-Code. Solche Zeilensensoren gibt es allerdings auch mit fertig digitalisiertem Datenstrom. Ob der Latten-Code da geeigneter ist? Ich denke eher nicht. So wie das für mich aussieht, spielt es ja eine Rolle, wie die Striche/Felder oberhalb und unterhalb der zu messenden Höhe aussehen. Es wird dort offenbar ein Bild der gesamten Latte oder zumindest eines Ausschnitts gemacht und dieser dann verglichen. Man benötigt dann für solch einen Code einen recht breiten Sensor. Ich nehme an, Du würdest den Sensor dann längs zur Code-Richtung verwenden wollen? Oder habe ich etwas übersehen? Beim Gray-Code benötigt man nur die Daten des aktuell betrachteten Segments und hat sofort seine aktuellen Position. Edit: Das ist aber eine durchaus sehr interessante Lösung, die ich so noch nicht bedacht hatte: der Code wäre nämlich bei einem Kippspiel eines Sensors im Vorteil, wenn das Spiel in die Nähe der Strichbreite kommt. Interessant :-)
:
Bearbeitet durch Moderator
Vor 20 Jahren habe ich mit so etwas gearbeitet, kann mich aber nicht mehr so genau erinnern. Ich glaube man musste ca. 15 - 20 cm auf der Latte sehen damit das funktioniert hat. Übertragen auf die 400Dpi könnt das mit dem Sensor reichen, vermute ich.
Chris D. schrieb: > Kippspiel eines Sensors im Vorteil Das Niv hat eine leicht schiefe Latte sogar herausgerechnet, und wenn der Lattenhalter zu Müde war eine Fehlermeldung gezeigt.
Je mehr ich darüber nachdenke, desto interessante erscheint mir diese Art der Kodierung. Offenbar ist solch ein Code genau für solche Randbedingungen (Verkippen) besser geeignet als die üblichen Codes. Der Sensor ist zwar länger, allerdings kann man die Auflösung so einfach durch Verlängerung des Sensors steigern und das ist meist einfacher, als die Breite raufzusetzen. Jetzt muss man sich nur noch einen pfiffigen Code ausdenken :-) Sehr, sehr interessant - vielen Dank für den Tipp!
:
Bearbeitet durch Moderator
Falls Du etwas herausfindest, lass es uns bitte wissen. Ich könnte mir vorstellen das es auch für Roboter Bauer interessant ist, die könnten ein paar Streifen an die Wände kleben und somit genau die Entfernungen ermitteln.
Gerne :-) Ja, für solche "verkippresistente Codes" gibt es sicher eine Fülle von Anwendungen. Jetzt für meinen Geber der Kolbenstange werde ich aber wohl erstmal einen simplen Quadraturgeber bauen. Dann muss man halt beim Einschalten zur Initialisierung einmal ganz Zurückfahren, aber ich brauche die Lösung jetzt schnell und einfach - da reicht das wohl ;-) Aber das behalte ich auf jeden Fall mal im Hinterkopf für weitere Experimente mit linearen Absolutwertgebern. Damit sollten sich auch mit billigsten Schienen sehr hohe Auflösungen realisieren lassen.
Chris D. schrieb: > Jetzt für meinen Geber der Kolbenstange werde ich aber wohl erstmal > einen simplen Quadraturgeber bauen Dann kannst du auch einfach eine Zahnstange einbauen, robuster gehts nicht. Georg
Georg schrieb: > Chris D. schrieb: >> Jetzt für meinen Geber der Kolbenstange werde ich aber wohl erstmal >> einen simplen Quadraturgeber bauen > > Dann kannst du auch einfach eine Zahnstange einbauen, robuster gehts > nicht. Zu spät ;-) Taktlineal ist schon aufgeklebt und Sensoren aufgelötet. Ich werde wohl nachher irgendeinen ATtiny nehmen, um die Umsetzung zu Takt/Richtung vorzunehmen. Allerdings nur für 0,5mm Auflösung. So genau ist die Hydraulik (sind nur einfache Magnetventile) ja eh nicht und zur Fehlererkennung (Hydraulik kaputt, Teil nicht korrekt ausgestoßen etc.) reicht es allemal.
Angehängte Dateien:
-
TrimbleBarcode50cm.png
52 KB
Ich habe mir die 50 cm Trimble Latte genauer angesehen. Besteht nur aus 2 + 2 Elementen. Das sind Felder fester Breite mit oder ohne Mittelstrich. Diese können auch negiert sein. Das macht 4 Möglichkeiten. Hoffentlich war das wirklich Trimble und nicht nur ein Beispielbild.
Jedes Feld ist 1cm breit, es liegen auch mal 2 Gleiche nebeneinander.
So ähnlich arbeiten auch lineare Wegmesssystemen wie bspw. dieses hier: http://www.pepperl-fuchs.de/germany/de/classid_822.htm Die Codeschiene enthält dabei eine binäre Pseudozufallssequenz und wird von n Lichtschranken abgetastet. Bis zu einer gewissen Maximallänge kann aus der von den Lichtschranken erfassten n Bit langen Teilsequenz des Codes eindeutig auf die deren Position innerhalb der Gesamtsequenz geschlossen werden. Das verlinkte System erlaubt absolute lineare Positionsmessungen in einem Bereich von bis zu 327m bei einer Auflösung von 0,8mm. Solche Systeme werden bspw. in Hochregallagern eingesetzt. Ich kann leider auf die Schnelle keine gute Beschreibung der zugrunde liegende Theorie finden. M.W. wird zur Auswertung der erfassten Codesequenzen eine Kombination aus Look-Up-Tables und pfiffiger Algorithmen benutzt, aber Genaueres weiß ich auch nicht.
Angehängte Dateien:
Vielleicht finde ich ein Patent oder eine DIN dafür. Oder jemand erkennt im Bild eine Folge und kann diese fortsetzen. Habe den Elementen noch Zahlen zugeordnet.
Hallo, man könnte einen Greycode auch der Länge nach statt nebeneinander anordnen, dazu muss man allerdings eine eindeutige Trennung einführen. Bei z.B. 10 Bit kann man z.B. 3 bit links vom Separator und 7 bit rechts davon auswerten, das ergibt eine eindeutige Position. Den Separator kann man auf einer 2. Spur unterbringen oder man benutzt einen ternären Code, also Felder für 0, 1 und Separator. Bei näherem Nachdenken muss das garkein Greycode sein, weil sich ja das Problem der parallel wechselnden Bits nicht stellt, es müsste jede eindeutige Zählsequenz verwendbar sein. Zur Auswertung erfasst der Sensor (bei ternärer Codierung) n+1 Bit, eines davon ist der Separator. Aus den n bits und der Lage des Separators ergibt sich die Position. Georg
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.