Plötzliches Versetzen des Werkstücknullpunktes

Moin,

Meiner Meinung nach sendet das USB-Board die Position an das Programm zurück.

Das wäre zu schön um wahr zu sein. Das USB-Board ist ein reiner USB-Parallelumsetzer der zu allem Überfluß auch noch den Kopierschutz beinhaltet.

WinNC-USB installiert einen Echtzeitkernel, der nie gebraucht würde, wenn das USB-Modul, Arduino gleich, die Maschine steuern würde. Deswegen gibts es auch so Probleme, wenn wieder mal Windows nach Updates im Internet sucht...

...außerdem ist meiner Meinung nach Windows das falsche Betriebssystem, um Maschinen zu steuern. Aber das nur am Rande.

Allerdings fiel mir beim Schreiben des Beitrags gerade auf, das ich bei meinen XP die Updatefunktion tot legen sollte. Möglicherweise taucht der Fehler dann nicht mehr auf. Die Log-Datei werd ich auch mal aktivieren und bei einem erneuten Fehler Herrn Lewetz zukommen lassen.

WinPC schickt an das Board den g-code ...

Nein, das macht es nicht. Dazu ist es nicht in der Lage. Es nimmt nur Kommandos entgegen, welche Leitung des Parallausgangs zu aktivieren oder zu lesen ist. Kannst dich gerne davon überzeugen, die Kommandotabellen kannst du ja in WinNC-USB selber editieren.

Mit der nächsten richtig übertragenen g-code-Zeile wird also wieder zurück auf die richtige Höhe gefahren.

Definitiv nicht. Es wird mit den falschen Koordinaten der ganze Job bis zu Ende gefahren. In meinem gepostetem Foto ist die eingekreiste Tasche, rechts unten, die erste und damit die richtig Gefräste. Alle weiteren Taschen sind falsch, inklusive der kompletten Ausfräsung.

Im Moment steht meine Fräse wegen dem Problem, da ich keine Lust auf zerfäste Teile hatte. Da ich nun aber weis, ich bin nicht der Einzige mit diesen Problemen, denke ich jetzt ernsthaft darüber nach dein Parallelinterface nachzubauen und auf Linux-CNC umzusteigen.

sswjs, aka Jens

Meiner Meinung nach sendet das USB-Board die Position an das Programm zurück. WinPC schickt an das Board den g-code und simuliert nicht auch noch die Bewegung der Maschine. Wenn da dann in der Übertragung was schief läuft, dann kommt es zu dem Fehler. Ist im übrigen die einzige Erklärung warum laut Christian dieser Fehler auch wieder korrigiert wird, denn die Steppi hat ja keine Messeinrichtung und kann damit Fehler wie sie bei Schrittverlusten auftreten garnicht erkennen/korrigieren. Mit der nächsten richtig übertragenen g-code-Zeile wird also wieder zurück auf die richtige Höhe gefahren.

Ja, er fährt dann auf die "neue" richtige Höhe. Spricht aus Z=-0.02 (in WS-Koordinaten) wird auf einmal Z=8 (weil das KS versetzt wird). Die Maschine fährt daraufhin 8.02 nach unten.

Ich würde sogar vermuten, dass das Problem genau genommen zwischen USB-Chip und Mikrocontroller besteht. Ich kenne das z.B. vom AVR, dass es dort Tabellen gibt bei welchen Übertragungsraten welche Bitfehlerrate auftritt. Tendenz ist da je höher die Übertragungsrate und je ungünstiger das Verhältnis zur uC-Taktfrequenz, desto höher die Fehlerrate.

Ich vermute auch ein Übertragungsproblem - nur sowas muss doch im Protokoll abgefangen werden? Ich werde trotzdem mal anfangen, USB Anschlüsse und Computer durchzutauschen. Das ist nur leider sehr Zeitaufwänding. Ich verwende das USB Kabel, das Stepcraft mitgeliefert hat - das ist allerdings recht lang. Vielleicht fange ich einfach mal damit an.

Als Inschenör hat mans schon schwer! 😆

PS: könnte natürlich auch durch die Optokoppler kommen.

Dem Inschenör ist nichts zu schwör 😉

Noch ein Nachtrag:

Gibt es denn alternative Betriebsumgebungen für die Maschine? LinuxCNC ist mir bekannt, habe ich aber noch nie verwendet. Ist das mit Parallelschnittstelle annährend Echtzeitfähig?

Gruß, Christian

Moin,

Ist das mit Parallelschnittstelle annährend Echtzeitfähig?

Das Desktopsystem sicher nicht, aber Linux besitzt einen Echtzeitkernel der Maschinensteuerungen ermöglicht. Damit ist LinuxCNC ausgestattet wenn man es als Linux-CD runterläd.

sswjs, aka Jens

Meine Sicht:
Naja, ein PC ist natürlich immer ne unvorhersehbare Lösung. Das fängt ja damit an, dass jeder unterschiedliche Hardware hat. Daraus resultieren dann auch Differenzen selbst in einer ansonsten nackten OS-Installation. Wollen mal garnicht damit anfangen welche Differenzen auftreten, wenn man da auch noch Software installiert.

Von daher gibt einem eine LinuxCNC-Installation ein System, welches noch am ehesten eine vergleichbare Umgebung bietet. Aber auch da kann es passieren, dass der Kompatibilitätstest sagt, dass die Hardware geeignet ist und trotzdem taucht dann im Betrieb ein Problem auf, das nur sporadisch vorkommt, einem aber ein Werkstück zerfräst.
Das große Problem sind einfach die Interrupts.

Ich denke, dass Lösungen mit einem externen Motion Controller einfach besser geeignet sind, weil da alles vorhersehbarer ist. Die laufen mit einer selbst entwickelten Firmware und nicht mit einem ausgewachsenen OS. Nur ... auch da wird noch mit Interrupts gearbeitet und eine solche Software kann man de facto nicht auf alle erdenklichen Programmlaufpfade testen. D.H. selbst wenn das Teil die internen Tests überstanden hat, kann es immer noch Probleme geben, die erst bei recht seltenen Umgebungsparametern zu Tage treten.

Demnach wäre meine Rangliste:
1. Mein eigener Controller, der aber erst noch gebaut werden will 😆
2. Motion Controller + PC Software ( z.B. Arduino + EstlCAM oder UC100 + UCCNC oder Controller + Mach3 ...)
3. Parallel Karte + LinuxCNC
4. Parallel Karte + Mach3
und wie ich gerade gelernt habe und obwohl ich es nun ein Jahr genutzt habe 5. USB-Board + WinPC NC

(vielleicht gibt es ja da noch einen Unterschied zwischen g-code- und plt-Dateien? Vielleicht ist plt zuverlässiger, sonst hätte es mir doch auch auffallen müssen? Vielleicht ist das ja der Kern des Problems?)

Hallo,
ein Übertragungsproblem kann ich mir eigentlich nicht vorstellen denn die Fräse kann nur ganz wenige Signale wie Endschalter an den PC zurücksenden, aber keine Positionen, dazu bräuchte man schon Encoder an der Maschine.
Wenn die Maschine plötzlich die angezeigten Koordinaten ändert dann kann das nur am Computer oder der Steuersoftware liegen; evtl. ausgelöst durch Störsignale die von der Fräse kommen und falsch verarbeitet werden. Auch Spannungsspitzen durch elektrische Aufladung wären als Ursache denkbar.

Gruß
Helmut

Hallo,

also quasi ein Übertragungsproblem in die andere Richtung? Das wäre auch eine Möglichkeit. Wie schalte ich das Logging ein? Dann könnte man mal schauen, ob was in den entsprechenden Dateien steht, nachdem das Problem wieder aufgetaucht ist.

Wie ist eigentlich generell die Kommunikation aufgebaut? Sendet WinPC direkt Steppersignale über USB an die Maschine oder funktioniert das so wie der Smoothstepper, der Din-Code verarbeitet und daraus erst Steppersignale erzeugt? Im ersten Fall hast du sicherlich recht - der Impuls, das WS-Koordinatensystem zu ändern, kann dann kaum von der Maschine kommen, sondern von der Steuerungssoftware.

Gruß, Christian

Hi,
ich hatte mal ein Problem mit dem 3D Druckkopf, der förderte Material ohne einen Befehl zu bekommen.
Dann versetzte er mir auch den Nullpunkt.

Die Lösung war in meinem Fall das Netzgerät.
Nachdem ich dieses gegen ein Laptopnetzteil ausgetauscht hatte, lief die Schose wieder.
Wenn ich das alte Netzteil auch nur mit einem anderen Verbraucher anschließe dann geht der Zauber der sebständigen Bits und Bytes wieder los.
Checkt mal in die Richtung.....
Könnte sein, das es reicht einen Netzstecker 180* verdreht einzustöpseln - das kennt man aus der HiFi-Technik, so bekommt man Brummstörungen weg.

Gruß Stefan

Hallo,
meines Wissens setzt die Winpcnc USB Karte die Befehle nur von USB auf Parallel um, ist also mehr ein Adapter und nicht mit dem Smoothstepper vergleichbar.
Nicht umsonst haben CNC Steuerungen oft Optokoppler zum Schutz in der Verbindung mit dem PC; ob dies bei der SC Steuerung der Fall ist kann ich nicht sagen.
Für meine CNC Maschine habe ich extra einen alten Stand-alone XP-PC nur mit der Fräsensteuerung der nicht am Netz hängt und noch mit der Originalkonfiguration seit über 5 Jahren läuft da es bisher keine Probleme gab.

Gruß
Helmut

Es geht um Übertragungsprobleme VOM PC AN das USB BOARD. Denn irgendwie muss das USB-Board ja wissen welche Schritte es generieren muss.
Auch wenn, wie es Jens erklärt hat, die WinPC Software etwas mehr macht, als nur den g-code zu senden, dann wird aber trotzdem nicht jeder Schritt realtime übertragen. Das funktioniert nämlich Prinzipbedingt per USB nicht. USB ist keine Schnittstelle um realtime Signale zu übertragen.

Es wird also so sein, dass WinPC das übersetzen des g-code in ein binär-Format übernimmt. Vielleicht auch sowas wie: zum Zeitpunkt t1 mache x,y,z Schritte ...
Das würde dann in der Tat erklären, dass der Fehler über den Rest der Fräsung hinweg bestehen bleibt. (Ich hatte da den Eingangs-Post anders verstanden)
Auf jeden Fall wird der Controller dann eine Weile selbständig laufen, bis diese Position erreicht ist. In der Zwischenzeit möchte aber das Fenster am PC auch die aktuelle Position anzeigen. Und die kommt für mein Verständnis vom Controller zurück.
Das ist natürlich auch nur die Position wie sie vom Controller mitgezählt wurde und ist nur dann deckungsgleich mit der aktuellen Position, wenn es keine Schrittverluste gab.

Aber eigentlich ist das ein Problem, um das sich andere kümmern müssten, zumal es ja jetzt offensichtlich gehäuft vorkommt. Wenn ich mal Zeit und Lust habe, dann könnte in die serielle Kommunikation natürlich mal reinlauschen. Natürlich sind die Bemerkungen von mir nur Vermutungen, die auch durchaus weit gestreut sind. Aber das ist nunmal die Vorgehensweise, wenn man solche Bugs finden möchte. Der kann sich überall verstecken!

Z.B. könnte es auch ein Bug in der Controller Software sein, der nur bei der Übertragung von bestimmten seltenen Bitpattern auftritt. .... Aber dazu bräuchte man auch Einblick in den Sourcecode.

Hallo,

weißt du, wie man das Logging bei WinPC NC einschaltet? Dann könnte man mal schauen, was das Programm im Fehlerfall macht.

Wir werden jetzt erstmal unter leider erhöhtem Halbzeug- und Fräserverbrauch ein paar Sachen fertigstellen und die Angelegenheit weiter beobachten. Gottseidank läuft die Maschine bei uns nicht im wirklichen Produktivbetrieb. Eine Fehlersuche ist so zeitaufwändig, dass dann wohl eher ein Umbau auf LinuxCNC und Parallelkarte erfolgen wird.

Gruß, Christian

Hallo Christian

weißt du, wie man das Logging bei WinPC NC einschaltet?

siehe hier www.lewetz.de/test/Win-Protokoll.pdf

Gruß
Raimond

Moin,

... dann wird aber trotzdem nicht jeder Schritt realtime übertragen. Das funktioniert nämlich Prinzipbedingt per USB nicht. USB ist keine Schnittstelle um realtime Signale zu übertragen.

Ups,daran hab ich noch gar nicht gedacht. Aber jetzt machen die Monoflops (HC74123) in den Motoransteuerleitungen Sinn. Und eine (echte) Realtimeansteuerung ist nicht nötig.

Es wird also so sein, dass WinPC das übersetzen des g-code in ein binär-Format übernimmt. Vielleicht auch sowas wie: zum Zeitpunkt t1 mache x,y,z Schritte ...

Echte Aussagen, wie's von WinNC-USB angesteuert wird, wird nur Herr Lewetz machen können. Allerdings bin ich der Meinung, daß es für jeden Schritt eines Motors auch ein Befehl geben wird. Denn sonst wäre ein Stoppen mitten in z.B G01 X400.00 nicht möglich. Auch hab ich beobachtet, daß manchmal zum Anfang zurückgefahren wird, um die ganze Strecke noch einmal abzufahren und manchmal nicht. Fährt er nicht zurück, ist Job versaut.

Auf jeden Fall wird der Controller dann eine Weile selbständig laufen, bis diese Position erreicht ist.

Glaub ich nicht, der Echtzeitkernel spricht dagegen. Außerden war sicherlich das USB-Modul nur eine Notlösung weil viele Rechner keinen Parallelport mehr besitzen.

Aber eigentlich ist das ein Problem, um das sich andere kümmern müssten, zumal es ja jetzt offensichtlich gehäuft vorkommt.

Korrekt.

Ich hab jetzt noch einmal in meinen zerfästen Acrylhaufen gesucht und festgestellt, daß der Versatz sowohl mit dem 19V- als auch beim 30V-Netzteil vorkommen. Allerdings werd ich mal Stefans Tip mit dem Drehen des Steckers ausprobieren und mich morgen mal ans Probefräsen machen. Acrylreste hab ich hab jetzt genug... :S

sswjs, aka Jens

Ich bleibe bei meiner Theorie, gestützt von folgendem Satz aus der WinPC Beschreibung:
"WinPC-NC USB nutzt zur Ansteuerung in Echtzeit die kleine Zusatzbox ncUSB und koppelt damit die zeitkritischen Aufgaben vom Windowsrechner ab."

Guten Morgen zusammen,

das ist interessant, also fungiert die USB Box als geschrumpfte Steuerung, an die der DIN-Code oder bewegungsbefehle gestreamt werden. Leider haben wir den Versatz des Nullpunktes immernoch, auch mit gedrehtem Netzteilstecker, kürzerem USB-Kabel und ohne den PC anderweitig zu belasten.

Der Fehler tritt etwa einmal alle 20min auf, lässt sich aber nicht provozieren. Wir haben Herrn Lewetz informiert - mal gucken, ob er eine Idee zur Fehlerbehebung hat.

Gruß, Christian