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
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?
Du weißt schon das du die in Linuxcnc integrierte SPS verwenden kannst. https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=2ahUKEwjok4_Ol5rgAhVFL1AKHXOeBkwQFjAAegQIAxAB&url=http%3A%2F%2Flinuxcnc.org%2Fdocs%2F2.6%2Fhtml%2Fladder%2Fclassic_ladder.html&usg=AOvVaw2_3XQD-TRKRRXlH8TGe_eG Gruss Bernd
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
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
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
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.
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
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...
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?
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
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. "
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
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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 ...
:
Bearbeitet durch User
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 ?
Hi Ich habe mal schön lange mal rumgefust . Es gibt die Möglichkeit wenn noch das Projekt läuft, mal schreiben. Gruß
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.