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

pl7i92 wrote:

Das wird ja immer besser
nicht das das noch ein thema in der arduino community wird da stagnierts bei grbl


Bei dem wetter Fährt man Cabrio

da bin ich rausgewachsen - das hab ich mit mitte 20 gemacht...


ernsthafte "semi-echtzeit" kann man mit dem arduino und ethernet wohl vergessen.
was aber gehen sollte: displaysteuerung und konzentrator fuer inputs und/oder drehwinkelgeber.

ich habe jetzt erst mal stepper und geber gekoppelt und grundsaetzlich funktioniert es.
wie genau und wie zuverlaessig teste ich die tage mal.

wicki wrote:

pl7i92 wrote:

was aber gehen sollte: displaysteuerung und konzentrator fuer inputs und/oder drehwinkelgeber.
.

das laeuft jetzt (also der drehwinkelgeber mit dem arduino)
mal testen, ab wann er edges verliert.

wenn ich die daten ascii (dann sinds 12) oder binaer (dann sinds 4 bytes) rausschreibe und
ich mache das serial bei 115200 dann sind das im besten falle 11kHz/4 also koennte ich rund 3000
datentelegramme/sekunde absetzen.
brauche ich aber ja gar nicht: ich denke, eins pro ms sollte reichen.
und das ja auch nur, wenn es ein sich aenderndes signal ist.


wenn der arduino wirklich 5usec fuer eine IO-operation braucht, dann muesste sich ja frequenzen
von 10kHz damit messen lassen.
und wenn der geber 1600 edges pro turn liefert, dann sollten 5 umdrehungen/sekunde noch messbar sein.


die frage ist aber: wie lange belegt ein serial.write die CPU? denn in dieser zeit kann ich ja nicht
messen

ich steuere die motoren jetzt im halbschritt an. habe also 400 schritte pro umdrehung. 5 umdrehungen/sekunde
sind 2000 schritte, sind 2kHz am motor.
das macht das raspberry locker mit.
und ich fahre dann mit 5u/sec. sind ca. 16mm/sec und das sind 960mm/minute bei 120/mm ausfloesung.

das ist keine rakete, aber damit kann ich leben und sollte voll innerhalb eine grossen sicherheitsbereichs liegen.

dann werd ich jetzt mal testen, ob das stimmt....

wicki wrote:

dann werd ich jetzt mal testen, ob das stimmt....

also was ich jetzt wohl mit sicherheit sagen kann:
dieser arduino ist so grottenlahm, dass er es nicht schafft, zwischen 2 pulsen
einen long wert in eine ascii-zeichenkette zu wandeln.

entweder also zu fuss machen oder den log-wert binaer ins telegramm packen.

mit scheint, die arduino-c-implementation ist so ganz gluecklich gewaehlt....

in der tat....

dieses arduino-teil hat deutlich schwaechen.
die pin-abfragen mit digital-read sind auch ganz furchtbar langsam.
direkter port-io verbessert das schon deutlich.

ich frage mich, ob es was bringt, das in assembler zu machen.

wäre es nicht schon an der Zeit dies in Git zu integrieren und auf Anregungen der internationalen Users zu warten hoffen und mit ihnen
am Projekt zu arbeiten

pl7i92 wrote:

wäre es nicht schon an der Zeit dies in Git zu integrieren und auf Anregungen der internationalen Users zu warten hoffen und mit ihnen
am Projekt zu arbeiten

im prinzip ist das richtig. ich glaube, dass diese sehr simple linCNC-schnittstelle durchaus
potenzial hat.
aber wie "in Git integrieren" ?
auf github?
"Am 4. Juni 2018 wurde bekannt gegeben, dass Microsoft GitHub für umgerechnet 6,4 Milliarden Euro kaufte"
der zusammen mit google, oracle und co. wohl mieseste sotwarekonzern der welt?

ich glaube nicht, dass ich da meinen code hochladen moechte....
ein eigenes repository auf eigenem server anlegen?
ja, koennte ich machen. aber:
das habe ich noch nie gemacht und ich weiss nicht, ob sich der aufwand lohnt
und sich jemand dafuer interessiert.

daher uebertrage ich meine notizen z.zt. auch nicht mehr ins englische.
linuxCNC ist schon ein ziemliches nieschenprodukt.
und das raspberry/arduino-treiberpaket ist dann noch eine niesche in dieser niesche.

ich finds recht cool, dass man ein drahtloses riesendisplay einfach irgendwo als DRO
hinstellen kann oder komplexe schaltaufgaben und steuerungen im <100usec-bereich
mittels raspberry oder arduino als linCNC-client abwickeln kann.
ob man das nun braucht, ist eine andere frage

aber wenn jemand mitachen moechte: einfach melden....


munter bleiben

wicki

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

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.....