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