mikrocontroller.net

Forum: PC Hard- und Software LinuxCNC mit rasberry-PI als IO-Interface -


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi zusammen,

gibt es hier jemand, der linuxCNC verwendet?

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.
Die Port-Stati des PC werden dabei als raw-Ethernet-Pakete
ausgetauscht und Latenzzeiten von weniger als 50usec. sollten
machbar sein.
(ja, ich weiss: es gibt Mesa&Co - aber das war mir zu teuer und
zu exotisch. Ein rasPI ist echte Massenware)

Momentaner Projektstatus:

http://erste.de/rasPiCat.html

Das System funktioniert (echte beta-Tests stehen noch aus)

Falls es hier jemand gibt, der sich dafuer interessiert, freue
ich mich ueber Rueckmeldungen.
Schoen waere es, wenn sich ein passionierter C-Entwickler mit
RT- und raw-Ethernet-Erfahrung meldet.
Aber auch reine Anwender, die nur ein Maschinchen mit einem
Motherboard ohne Parport (und das ist ja heute leider die Regel)
steuern und diese Loesung mal ausprobieren wollen, sind
mir herzlich willkommen ;-)

Benoetigte Hardware fuer den Test:
Ein rasberry PI, ein PC mit Ethernet-Karte, eine 08/15-China
TB6xxx-Schrittmotor-Steuerkarte.
Die aktuellen TB6600-China.Klone fuer weniger als 20 EUR/Stk.
funktionieren direkt am GPIO-Port des rasPI.

Munter bleiben

Wicki

Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> Warum muss es unbedingt der RasPi sein?

Weil den jeder mehrfach in seiner Bastelkiste hat?

Autor: Otto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Jörg B. (jbernau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: wicki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi joerg,


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

ich verstehe nicht ganz...
was hast du fuer eine hardware gebaut?

fuer alles was nach dem ttl-pegel kommt, benutzer ich die billig
ta66xx-module aus china. billger kann man sie nicht selbst bauen,
glaube ich.
oder spricht du von etwas anderem ?

das problem ist momentan der RT-raw-eth kram.
einer der entwickler ist verstorben und daher ist rtnet.org
wohl festgefahren.

da liegt momentan m.e. das hauptproblem.
im userspace habe ich das zeugs gaengig. und es funktioniert auch.
nur kann ich keine latenzzeiten von <125usec wirklich garantieren.


gruss

wicki

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg B. (jbernau)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg B. (jbernau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wicki W. schrieb:
> schick mit doch mal ne mail

erledigt.

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja >100us scheint schon die latency vom Kernel zu sein...

Billig und ausreichend gut funktioniert grbl am arduino... das ist noch 
billiger als ein rpi ...

Und wieso den rpi als parallel Port Ersatz??? Wenn dann gleich Linux cnc 
am Pi! Aber die Probleme damit hast du ja schon entdeckt...

73

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Sumpfhead (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zwei Sachen könnte helfen:

- RT Kenel (machst du schon?)
- 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


Obs hilft?

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sumpfhead (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://xmodulo.com/run-program-process-specific-cpu-cores-linux.html


"Add the kernel parameter "isolcpus=<CPU_ID>" to the boot loader during 
boot or GRUB configuration file. Then the Linux scheduler will not 
schedule any regular process on the reserved CPU core(s), unless 
specifically requested with taskset. "

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: Sumpfhead (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Coole Sache ...

Autor: Jörg B. (jbernau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Jörg B. (jbernau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.... ;-)

Autor: Jörg B. (jbernau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

: Bearbeitet durch User
Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg B. (jbernau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wicki W. (wicki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.