Mal wieder: Arduino und Rapsberry als Treiber-Boards - Deutsches Howto

zwischenergebnisse mit arduino zum auswerten eines 1600 edges/umdrehung-drehwinkelgebers:

ansteuerung des schrittmotors (1/2-schritt) mit 1.6kHz - (160 u/min)
resultiert dann in rund 6.5kHz (6339,56kHz) am ausgang des gebers.

das wird vom arduino noch recht zuverlaessig erfasst und ueber einen ringbuffer
seriell mit 115kbaud ausgegeben.
_aber_......

das problem ist wohl die hohe aufloesung von 1600 edges/turn und wenn der schrittmotor
im halbschritt laeuft, dann "federt" er beim anhalten scheinbar leicht zurueck und es wird
eine rueckwaertsbewegung erfasst (1 oder 2 1600stel).
(bei hoehren drehzahlen habe ich eine geringere fehlerqoute als bei sehr langsamen
drehzahlen. vielleicht ist es auch ein mechanisches problem durch vibrationen)

vermutlich waere es klueger, einen encoder zu verwenden, der genau so viel signale/umdrehung
wie auch der motor macht.
oder ich zaehle nur 4 vollstaendige rechtecksignale als einen schritt.

wie machen das andere?

seit 1982 werden 80er Chips eingesetzt mit 1mhz
in asm programmiert die dann ein TTL produzieren und ein Richtungssignal setzen Haidenhain TNC <200
ein flipflop reduziert das Signal auf 1 Takt
ist aber nicht das wahre wenn ich volle Signalqualität wegen Rechnerleistung reduzieren muss 2019

ist aber nicht das wahre wenn ich volle Signalqualität wegen Rechnerleistung reduzieren muss 2019

wieviel kHz koennen die denn verarbeiten?
ich kriege mit dem arduino momentan 13kHz abgetastet, die werte umgerechnet und
mit 115kBaud ausgegeben. theoretisch fuer 8 encoder.
ich nehme an, das mit asm noch mehr geht - und ein raspberry sollte das ganz locker
mit mehr als 20 kHz schaffen.
da ist dann auch bei den gebern das ende erreicht.

oben der output eines encoderkanals, unten das abtastsignal des arduino.
ab 10kHz wird es etwas grenzwertig.
(den frequenzanzeigen des oscs. darf man nur bedingt trauen - mehr als ein grober
richtwert sind die nicht)



ich bastel gerade die linCNC-reader componente und bin mir grad noch nicht sicher,
ob ich direkt lesen oder via shmem die daten annehmen soll.
im moment tendiere ich zu shmem.

jetzt habe ich die abtastrate mit dem arduino auf 20kHz hoch bekommen.
aber richtig testen kann ich nun doch noch nicht:
grad eben hat sich der gestern eingetroffene 600p/r- encoder (der tatsaechlich
2400 edges/turn lieferte) stillschweigend verabschiedet.
kein output-signal mehr da :S

und das mit den 20kHz muss ich auch nochmal revidieren:
erfassen kann ich zwar so schnell - aber wenn ich die erfassten daten
ausgebe, dann sackt die abtastrate auf 7kHz ab

muss ich doch noch was dran optimieren.....

ich habs getan....

(aber noch nicht veroeffentlicht - weil: muss noch testen)
ethsh.comp kann jetzt die daten aus bis zu 5 encodern einlesen, die
von einem arduino seriell ankommen.
sie werden von einem userpace-reader angenommen und per shmem
an linCNC weitergreicht.
der reader liefert die jeweils aktuellen daten mit 115kbaud an. aber nur, wenn
sich werte aendern. ansonsten wird die position 1xsekunde uebertragen.
das protokoll ist einfach:

byte
6 x STX
1 x endodernr
4 x encoderposition

der arduino kann 4 encoder mit bis zu 20kHz einlesen. (8 sollte auch gehen,
aber wer braucht das?) und die encoder koennen selbst auch nur bis 20kHz.

leider hat einer der encoder (400/600 p/r bzw. 1600/2400 e/r) wohl einen wackler
(der 600er). mal liefert er daten, mal nicht. kann also noch nicht richtig mit
mehreren achsen testen.

aber nun koennte ich mal wieder hilfe gebrauchen:

in ethsh.0.par-00.pos steht jeweils die aktuelle encoderposition.
wie koppel ich das nun am sinnvollsten an linuxCNC an ?

wie sage ich ihm also:
verwende ethsh.0.par-00.pos als position-fb
?

gibt es da irgendwo eine beispiel-config, die ich mir ansehen sollte?

vielleicht eine, die das vorgehen bei nur einer achse beschreibt?

waere prima, wenn mir da jemand helfen koennte.


wicki