Moin, ich benötige mal einen Schubbs in die richtige Richtung. Ich habe zwei alte Notebooks auf denen ich Linuxcnc installiert habe. Ein Cybercom MD6001 (integrierter Parallelport) mit single core Athlon K7. Mit einigen manuellen Eingriffen ging dann sogar Clicktouch auf dem Touchpad und mit nolapic startet auch der latency test (28ms Jitter). Für alle weiteren Kernelparameter zeigt sich die Kiste unbeeindruckt, bzw. es verbessern sich nicht die Jitter Werte. Der zweite Notebook, ein Compaq nx6325 mit single core Sempron macht allerdings extreme Sachen. Starte ich den latency test, sehe ich noch kurz das Fenster, dann schaltet der NB hart aus. Also kein Vorspiel, mit Prozessen die runtergefahren werden, sondern ein Klacken und die Kiste ist aus, als ob ich einen Sack Schrauben reingeworfen hätte. Wiederholbar. Es ist noch keine Par port Karte verbaut (PCMCIA oder Express Card), da ich mir erst die Latency Werte ansehen wollte, bevor ich die kaufe. Der Compaq hat Bios Settings für integrierte Ser + Par Schnittstellen die wohl über die optionale Docking Station rausgeführt werden. Aktiviert / deaktiviert ohne Änderung. Ansonsten lässt das Bios keine irgendwie interessanten Einstellungen zu. Im Grub war lapic gesetzt. Mit acpi=off nolapic apm=off probiert, mit gleichem Ergebniss.
BIOS Batterie geprüft? Ansonsten hält eventuell das Netzteil (oder der VRM auf dem Mainboard) den Last Spike nicht mehr aus. Könnte man mit anderen Lasten mal probieren, z.B:
1 | bzip2 </dev/random >/dev/null & |
Jim M. schrieb: > BIOS Batterie geprüft? Das Bios behält seine Einstellungen und die Uhr geht. Es ist KEIN Lastproblem. Ich kann die Kiste bis zum Stillstand mit Arbeit zumüllen, ohne Ausfall. Nein, das ist schon LinuxCNC das hier ganz kräftig etwas anspricht, von dem es tunlichst seine Finger lassen sollte. Scheint irgendwie ins Power Management reinzutreten. Entferne ich noacpi etc., bekomme ich nur noch eine Fehlermeldung, statt Absturz. 1000 Kernelparameter probiert, von spontaner annihilation und recovery gefriggel bis zum rumbocken mit Fehlermeldung ist alles dabei. Nach gefühlten 100Stunden endloser Frustration bin ich nun auf debian buster + rt kernel gegangen und versuche mich am buildbot um die 2.8 zu bekommen. Absolut fantastisch! Kann ich jedem empfehlen, der auf Schmerzen steht und seine Zeit gerne Blockweise sinnlos verbläst ohne sich auch nur einen mm von der Stelle zu rühren. Massive Probleme Paketabhängigkeiten aufzulösen. Statt einfach alle benötigten Pakte zu installieren, muss ich das per Hand stück für stück machen, weil buster das nicht gebacken bekommt. Mal sehen wie viele Tage ich noch dabei verblase.
Nimm halt irgendeinen anderen Rechner, 15järige Thinkpads mit PP gibt bei ebay etc für ein paar €.
Rote T. schrieb: > Nimm halt irgendeinen anderen Rechner Geht nicht, dann nächster Rechner... Ich werde wohl eines der gut funktionierenden mini-ITX Boards besorgen. Also alle drei alten Notebooks, die auf ein neues Leben hoffen, ab in die Tonne.
Es liegt defintiv an Debian. Wheezy stürzt hauptsächlich beim Latenzy test ab, aber hin und wieder auch unmotiviert vorher. Buster stürzt schon deutlich häufiger ab und kann linuxcnc nicht installieren weil Pakete fehlen und sich auch nicht nachistallieren lassen. Bei Stretch (32 & 64bit) geht der NB schon während der ersten Installationsschritte aus. Text / Grafik Install, ob out of the box oder geflutet mit kernel Parametern, die mal komplett dem Bios / ACPI trauen und mal alle Verantwortung dem kernel übergeben. Linux Mint wird ohne Probleme installiert. Laststest ist unauffällig.
Wenn du damit richtig fräsen willst, sind Notebooks mit Parportkarte meiner Erfahrung nach wenig geeignet.
habe bereits einen Styroschneider (4 Achsen) mit altem PC, Linux CNC und Parallelport im Einsatz. Studiere nun schon länger an einer Fräse herum. Was wäre dann da die Empfehlung um die mit Linux CNC zu betreiben? Gibts ja nebst Parallelport glaub nur die Möglichkeit mit mesa ethernet Karten... Oder dann halt doch was GRBL-Stil und ohne CNC Linux. Bei Linux CNC müsste man doch irgendwie definitiv vom Parallelport wegkommen, das wird einfach immer mühsamer mit der PC Hardware. Gruss DL
Ja, hast Du wohl recht. Der Jitter wird relativ hoch sein. Später soll es das ASRock Q1900B-ITX werden. Davor muss ich aber noch einiges über Linux und Linuxcnc lernen. Dazu dient die ganze show gerade, auch wenn das in überhaupt keinem Verhältniss steht so viel Zeit in einen NB Dinosaurier zu stecken. Berbog schrieb: > Welchen Kernel nutzt du denn ? Gerade dabei den RT Kernel zu installieren. https://gnipsel.com/linuxcnc/uspace/linuxmint19-rt.html Hängt, weil ich noch Schwierigkeiten habe QT auf die Kiste zu bekommen. Wie immer zwischen mir und Linux hangel ich mich von nicht funktionierender Anleitung, zu nicht funktionierender Anleitung und gebe seitenweise Kommandos ein, die ich kaum verstehe und von denen irgendjemand, irgendwo im Netz sagt, das das so geht, was sich dann regelmässig als nicht so einfach herausstellt. Sehr frustrierend für einen bekennenden Win User, aber was mir an Wissen fehlt muss ich eben durch Zähigkeit auswetzen. Was ist denn mit geeigneten Boards überhaupt an Steprate möglich? Ich kenne die Latency Liste, aber die ist ja sehr rudimentär. Ich baue gerade einen Stepdriver mit Schrittinterpolation, daher müssen es keine dramatisch hohen Stepraten werden um vibrationsarm zu arbeiten. Die Positioniergenauigkeit werde ich durch fantastische Microschrittauflösungen ohnehin nur auf dem Papier verbessern können. Interessant wäre auch was das Problem an DoubleStep im Linuxcnc ist, denn es muss ja eines geben das das nicht standartmässig aktiviert ist. 16 x in + 16 x out will ich durch die lsrio16 shift register Funktion bekommen. 16/tel Base-Period langt ja für vieles. Endschalter auch, oder müssen die zwangsläufig schnell sein?
DL schrieb: > Bei Linux CNC müsste man doch irgendwie definitiv vom Parallelport > wegkommen, das wird einfach immer mühsamer mit der PC Hardware. Ich denke das torpediert das gesammte Konzept von Linux CNC. Fast alles was jetzt der PC tut, müsste dann die externe HW tun. Was ist denn genau Dein Problem mit dem Parport? Niedrige Latenz ist mit geeigneten Boards ja wohl möglich und Parport Karten gibt es für kleines Geld. IO Karten tun genau das, was der uralte Parport auch tut. Irgendwelche in + outs in den Adressraum legen. Würde ich heute sowas bauen und mit Industrietauglichen IO Treibern und Schutzgefriggel versehen, hätte es nicht mehr den anrüchigen touch eines parports, währe aber im Kern auch nicht mehr als das. Rechenleistung ist auf PCs mehr als reichlich verfügbar und das Latenzproblem scheint mir lösbar. ESTLCAM gefällt mir z.B. gut. Aber da setze ich entweder auf Parport ohne RT oder auf AVR Arduinos die Christian in ASM programmiert und deswegen den Schritt zum STM32 scheut. Der GBRL Kram kann was er kann und dann ist Schluss. Willst Du irgendwann mehr, Werkzeugwechsel, mehr Achsen, PLC, Jogweel etc. gehts mit der nächsten HW von vorne los, die kein Stück billiger ist als die Mesa Karten. Daher brauche ich Linuxcnc zwar derzeit überhaupt nicht, will es aber haben, weil meine Ansprüche sich steigern werden.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.