LinuxCNC mit rasberry-PI als IO-Interface -

Wicki W. schrieb:
> Ich baue grade an einer Loesung, um ein Raspberry-PI als
> IO-Interface zu verwenden.
> Der PC erhaelt eine "virtuelle" Parallelschnittstelle" und
> linuxCNC wird mit einem modifizierten Parport-Treiber
> verwendet.

Warum muss es unbedingt der RasPi sein?

Der BeagleBone Black, oder andere Boards die auf TI-Sitara-CPUs 
aufbauen, halte ich da wegen den PRU-Einheiten für viel besser geeignet.

Da gibt es unter dem Stichwort MachineKit auch fertige Images etc. für.

Gerd E. schrieb:
> Warum muss es unbedingt der RasPi sein?

Weil den jeder mehrfach in seiner Bastelkiste hat?

Wicki W. schrieb:
> gibt es hier jemand, der linuxCNC verwendet?

Ja, ich hatte mal angefangen das mit einem Bananenkuchen zu machen. Dann 
fehlte die Zeit das weiter zu betreiben. Als Busprotokoll hatte ich mir 
CANBus ausgesucht. Den RT-Kernel habe ich ebenfalls compiliert. LinuxCNC 
ist ebenso übersetzt. Jettz ginge es daran das ganze mit Machinekit zu 
verheiraten. Platinen sind fertig und die würde ich sogar unbestückt 
verschenken, wenn ich einen / ein paar Mitstreiter fände.

VG

Jörg

Otto schrieb:
> Du weißt schon das du die in Linuxcnc integrierte SPS verwenden kannst.


linuxCNC ist im prinzip eine SPS....

nur benoetigt es halt spezielle hardware.
z.b. ein parport oder eine mesa-karte.

MBs mit parport sind inzwischen selten - mesa-karten
exotisch und zu teuer zum "nur mal ausprobieren".

ein PI hat jeder....

munter bleiben

wicki

Wicki W. schrieb:
> mesa-karten exotisch und zu teuer zum "nur mal ausprobieren".

Genau und deshalb habe ich CAN genommen. Die Chips sind tonnenweise zu 
erchwinglichen Preisen verfügbar und die Verdrahtung ist sinple.

Den Stepper-Motor-Treiber will ich ja noch in CAN implementieren. Im 
Prinzip suche ich genauso Mitstreiter um die Mesa-Karten zu ersetzen.

CAN hat auch den Vorteil, dass es Servos dafür gibt.

wicki schrieb:
> ich verstehe nicht ganz...
> was hast du fuer eine hardware gebaut?

Einfach einen Pi-CAN-Bus adapter

VG

Jörg

Jörg B. schrieb:
> Genau und deshalb habe ich CAN genommen. Die Chips sind tonnenweise zu
> erchwinglichen Preisen verfügbar und die Verdrahtung ist sinple.
>
> Den Stepper-Motor-Treiber will ich ja noch in CAN implementieren. Im
> Prinzip suche ich genauso Mitstreiter um die Mesa-Karten zu ersetzen.


das klingt spannend... ;-)

ich habe aber mit CAN noch nie was gemacht.
aber einfacher als USB wirds wohl zu handlen sein...

schick mit doch mal ne mail.

wo steckst du denn geographisch? ich bin am niederrhein.

gruss

wicki

Wicki W. schrieb:
> schick mit doch mal ne mail

erledigt.

also stand der dinge ist jetzt der:

der linuxCNC-treiber laeuft und der schickt seine
daten ueber eine raw-eth-interface mit dem raspberry
aus und ueber die GPIO des raspberry werden die motoren
gesteuert.
funktioniert auch alles.
man hat also einen haufen IO-ports im linuxCNC um damit
was zu tun.

aber:
soifz
beim raspberry ist bei weniger als ca. 500usec. ziemlich
die luft raus.
dann wird so eine motor-schaltphase mal 50 oder auch mal
150 usec.
also zur erzeugung von sauberen motor-steps nicht wirklich
zu gebrauchen. es laeuft zwar, aber es hoert sich scheisse an.... :-(

was zu ueberlegen waere - und was wahrscheinlich gehen wird:

ich brauche kein OS mehr, wenn das ding einmal gestartet
worden ist. und die kommunikation ist ja nur
low-level-eth-socket.

nach dem start der kommunikation koennte man den ganzen kernel
tot machen und nur noch einen thread laufen lassen.

hat jemand n tip, wie man da am besten vorgeht?

vielleicht statt "init" einfach nur dieses C-programm starten?

das konnte doch schon die loesung sein - oder ?

munter bleiben

wicki

Wicki W. schrieb:
> hat jemand n tip, wie man da am besten vorgeht?

die im BeagleBone Black integrierten PRUs verwenden - die sind genau für 
solche Anwendungen gedacht.

Gerd E. schrieb:
> die im BeagleBone Black integrierten PRUs verwenden - die sind genau für
> solche Anwendungen gedacht.

dann kann ich auch gleich eine mesa-karte nehmen.
die ist genau dafuer gedacht.

darum gehts mir aber nicht.
ich will wissen. ob das mit dem rasPI geht.
ich werde nachher mal das timingverhalten in den runleveln
1 und S testen.

Hans schrieb:

> ausreichend gut funktioniert grbl am arduino...
>
> Und wieso den rpi als parallel Port Ersatz???

weil ich linuxCNC vom konzept her einfach klasse finde.
und man nicht auf fraesen, drehmaschinen oder oder 3-drucker
beschraenkt, sondern deutlich flexibler ist.
aber dass man ein parport auf dem MB braucht, das finde ich
doof....


werde mir nun aber doch mal ein arduino ordern.
testen kann mans ja mal...

Hans schrieb:
> Naja >100us scheint schon die latency vom Kernel zu sein...

die liegt ein kleines bisschen darunter - daher will ich
den kern ja auch gern los werden wenn die software laeuft.

ich kriege locker>100k befehle abgearbeitet und erzeuge mit
einem solchen loop noch rechteckwellen mit <0,3usec.

nur leider wird dieses schoene rechteck immer wieder mal
zerschossen. weil der kernel meint, da gaebe es wichtigeres
als meinen thread.
deswegen will in den kernel ja gern wieder loswerden.


Sumpfhead schrieb:
> - RT Kenel (machst du schon?)

jupp


> - einen, oder zwei CPU Cores vom scheduler befreien (via boot parameter
> möglch).


> - mittels taskset deinen wichtigen Prozess mit hoher Prio auf die
> freie(n) CPUs legen

das kannte ich noch nicht. wo find ich da was zu ?


> Obs hilft?

im runlevel "S" verbessert sich das schon etwas.
gefaellt mir aber noch nicht.
ich feil grad noch dran rum

raeusper

> im runlevel "S" verbessert sich das schon etwas.
> gefaellt mir aber noch nicht.
> ich feil grad noch dran rum

das oben ist eine 2.7MHz welle, die von einer c-schleife erzeugt wird.
das oszilloskop erkennt das auf dem bild aber aufgrund der
kernelbedingten "loecher" als 170Hz.

und das unten ist eine origial linuxCNC-generierte stepper-welle.
eigentlich sollten alle gleich lang sein: aber differenzen
von mehreren 100usec? das soll der kernel verbrechen??

http://erste.de/merke.jpg

warum heisst das image nun "merke" ?

weil ich mir jetzt dick und fett notiere:

DU SOLLST KEIN usleep() IN RT-programme einbauen!!!

hatte ich wohl zum test auf der sendenden seite gemacht.
und dann den fehler auf der rasPI seite gesucht.
(weil: timingprobleme muessen ja vom rasPI kommen)


soifz


also nun mal weiter testen....

und so lern ich zumindest nun auch mal n adruino kennen

Sumpfhead schrieb:
> - mittels taskset deinen wichtigen Prozess mit hoher Prio auf die
> freie(n) CPUs legen
> Obs hilft?


guter tip -  es scheint zu helfen ;-)
habe testweise mal 2 CPUs fuer den CNC-treiber reserviert und diese
zugewiesen.
er benutzt aber scheinbar nur eine davon. scheint aber keine 
timing-probleme mehr zu geben. einmal ist aber das ganze rasPI 
abgschmiert.
was aber auch daran liegen kann, dass ich es nicht in den runlevel
1 oder S geschickt habe, sondern auch noch X und div. netzwerkkram
laufen hatte.

mal sehen, wie sich das nun im einsatz bewaehrt....

Wicki W. schrieb:
> und so lern ich zumindest nun auch mal n adruino kennen

Deshalb habe ich mich für CAN entschieden und die Steps macht mir der 
externe Motion Controller :-) So ist closed Loop auch möglich :-)

Weshalb verwendest Du einen alten acht Bitter? ;-) CMSIS oder mbed sind 
für mich die besseren Alternativen. Als Entwichlungsumgebung finde ich 
platformio hilfreich...

Mein Projekt ruht, weilich neben dem Studium auch noch Geld verdeinen 
muss...

Jörg

Hi zusammen,

nun ist es benutzbar:

http://erste.de/rasPiCat.html

der naechste Schritt ist jetzt:

Errorhandling einbauen (falls die Kommunikation abbricht oder
gestoert ist), Geschwindigkeitsoptimierung und dann mal versuchen,
ob das auch auf ein Arduino-Board portierbar ist.

Theoretisch muessten 30kHz pro Pin machbar sein bei einem
100Mbit-Interface. Das sollte auch fuer flotte Motoren reichen.

Feedback waere schoen.....

Munter bleiben

Wicki

also das mit nem arduino und eth-shield  sieht bislang ehr
frustig aus:

wesentlich schneller als 1ms bekomme ich es momentan nicht - vom
zeitpunkt des versands eines 30 byte grossen pakets bis zum
setzen des zugehoerigen OUT-pins des arduino

wenn so ein loop max. 110kHz / 8usec erzeugt:

 digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage 
level)
 digitalWrite(led, LOW);

wo soll dann auch die rechenzeit her kommen, um noch eth-pakete zu
lesen, filtern und zu verarbeiten ?

wenn man aber mit einigen 100 usec. zufrieden ist, kann man
den arduino per ethernet zusammen mit linuxCNC benutzen.

den treiber mache ich gelegentlich mal fertig....


kann ein mega 2560 mehr ?

Wicki W. schrieb:
> kann ein mega 2560 mehr ?

Wie ich Dir schon geschrieben habe, ist das Problem der interne Takt der 
MCU.  Die AVRs takten höchstens runter und nicht hoch.

Was du da entwickelst ist einen Servotreiber. In der Industrie wird das 
so gemacht, dass der Treiber nur noch die Anzahl der Schrite bekommt, 
alles Andere macht er dann selber. (Anfahrtsrampe, PID Regelung, 
Abfallrampe, Referenzierung, ...)

Wicki W. schrieb:
> also das mit nem arduino und eth-shield  sieht bislang ehr
> frustig aus:

Nimm doch den ETH-Shield und bau ihn auf einen Nucleo-Board. Dann mit 
MBedOS weiter..

VG

Jörg


VG

Jörg

Jörg B. schrieb:
> Nimm doch den ETH-Shield und bau ihn auf einen Nucleo-Board. Dann mit
> MBedOS weiter..


wieder neue hardware? wieder ne andere IDE ?
ich glaube, fuer meine zwecke reichen mir jetzt
die raspberry- und die arduino-loesung.
zumal ich ins raspberry ja noetigenfalls noch servofunktionalitaeten
einbauen koennte.

100usec. reichen mir ja eigentlich schon als signallaufzeit.
auch fuer stepper-generierung. solange die verzoegerung konstant ist,
ist das ja egal.
und ob die antwort auf eine endschalter 100usec. verspaetet eintrifft -
damit kann man leben.

ich bin auch ziemlich sicher, dass man da noch mehr als 100 usec.
rausholen kann, auf der rasPI-seite.

na, mal schauen.... ;-)

Wicki W. schrieb:
> wieder neue hardware? wieder ne andere IDE ?

Nicht unbedingt. Arduino IDE geht auch. => Arduino Framework

Übrigens: Kennst Du eclipse? Bestimmt doch, dann kennst Du auch True 
Studio.


... wir verfolgen zwei grundsätzlich verschiedene Ansätze ...

Jörg B. schrieb:
> Übrigens: Kennst Du eclipse?

ja... leider...
krieg ich schuettelfrost von... ;-)
nur vom dran denken.


> Bestimmt doch, dann kennst Du auch True Studio.

das kenne ich nicht. dann lieber n SM-studio
- ich steh mehr auf bash und vi


> ... wir verfolgen zwei grundsätzlich verschiedene Ansätze ...

jau... das sieht so aus.

trotzdem koennten wir bei gelegenheit mal drueber sprechen.

was an der stelle fuer CAN spricht wuerde mich durchaus interessieren.


munter bleiben

wicki

Wicki W. schrieb:
> das kenne ich nicht. dann lieber n SM-studio
> - ich steh mehr auf bash und vi

Dann magst Du auch bestimmt Dominique und PlatformIO, gelle? ;-)

VG

Jörg

Aktueller Stand der Dinge:

http://erste.de/ethraw/readme.de.html

ca. 400Hz mit Arduino
da ist mit dieser Hardware via Ethernet wohl auch
nicht viel mehr raus zu holen

ca. 5kHz mit Raspberry - da geht sicher auch noch deutlich mehr

hi nochmal,

das ist jetzt der aktuelle stand der dinge:

http://erste.de/ethraw/readme.de.html

nun bin ich gerade dabei, einen drehwinkelgeber (1600 edges/turn)
zu integrieren.
raspberry und arduino schaffen das beide. aber:

wenn ich mit dem arduino die erfassten daten serial rausschaffen
will, dann denn benoetigt natuerlich die uebertragung per
serial.write auch CPU-zeit, waehrend der ich keine impulse
mehr zaehlen kann.

ein solches datentelegramm ist mindestens 4 bytes gross.

wie lange ist die CPU waehrend des sendens blockiert?

ist es sinnvoller 4 mal ein byte zu schreiben, statt 4 (
bzw. 10, wenn man ascii und nicht binaer scheibt) auf einmal?

ist es machbar/sinnvoller versand oder zaehlen auf eine ISR
umzustellen?

jemand eine meinung dazu?

Huhu.

ist das Projekt noch am Leben ?

Wie schauts mit dem LBP16-Protocol aus ?