Question Plötzliches Versetzen des Werkstücknullpunktes

Hallo Zusammen,

wir besitzen eine StepCraft 420, USB Vollversion mit SC500 Spindel und sind mit der Performance der Maschine an sich sehr zufrieden. Wir haben jedoch ein Problem:

Die Maschine / die Software (was, bleibt herauszufinden) versetzt während der Bearbeitung gerne willkürlich den Werkstücknullpunkt. Ein Foto eines entsprechenden Bearbeitungsergebnisses habe ich angehängt. In dem gezeigten Fall ist der Z-Nullpunkt um ~8mm nach unten gewandert und die Z-Achse ist dieser Änderung gefolgt. Ansonsten sah das NC-Programm in diesem bearbeitungsschritt keine Bewegung der Z-Achse vor - also können keine Schrittverluste aufgetreten sein.

Die Bearbeitung erfolgte mit einem 1mm Fräser, Zustellung 0.2mm, in Plexiglas.

Hat jemand ähnliche Probleme, bzw. gibt es dafür Lösungsansätze?

Vielen Dank für die Hilfe,
- Christian

Kann man ja ganz einfach ausprobieren. Einfach mal Nullpunkt ganz nach oben legen und die Datei nochmal in der Luft abfahren lassen. Muss man nichtmal g-code für verstehen.

Aber wenn es willkürlich ist, dann tippe ich eher auf die Fräsparameter (Vorschub und Drehzahl), an der noch Verbesserungsbedarf besteht. Plexiglas ist ziemlich unnachgiebig was das betrifft. Späne absaugen kann auch hilfreich sein, weil das die Gefahr verringert, dass sich Späne in der Fräser-Nut verkeilen und durch die Reibung aufheizen, schmelzen ....

Kann natürlich auch sein, dass die Fräsparameter gerade so passen, aber die Z-Achse nicht fest genug verspannt ist (die 1kg-Einstellung in der Anleitung).

Hallo Christian,
Lösungsansätze gibt es immer
Ist das reproduzierbar? Lass doch das Teil mal in der Luft fräsen. Was zeigt die Vorschau von Estlcam? Und in der Not - was steht im Gcode.
Wenn ich mir das Bild so ansehe vermute ich aber das der Fräser einfach gefressen hat und ein Stück aus der Spannzange raus gezogen wurde dann wäre damit ja auch der Nullpunkt verstellt.... Also eher in Richtung richtige Spannzange und fest genug angezogen.

Hallo,
ich hatte so ein ähnliches Verhalten beim Fräsen von Holz mit einem 1mm Fräser. Die Z-Achse ist dabei ebenfalls immer tiefer gewandert. Nachdem ich die Vorschubwerte reduzierte, war der Spuk vorbei.
Ich kann mir die Sache nur so erklären dass sich der rechtsgewendelte Fräsers durch den Vorschub in das Material gefressen hat und dadurch die Spindel in die Tiefe gezogen wurde.
Hat wer eine bessere Erklärung für dieses Phänomen da ich ehrlich gesagt einem 1mm Fräser derartige Kräfte nicht ganz zutraue (der bricht doch eher)?

Gruß
Helmut

Was dann dafür spricht, dass die Z-Achse noch nicht fest genug eingestellt ist.

Hallo Andreas,
in meinem Fall habe ich beim Zusammenbau überprüft (gemessen) dass die Achse richtig eingestellt ist. Auch hängt bei mir nur eine Proxxon an der Achse.
Oder muss man die Achse entgegen der Anleitung so schwergängig einstellen dass sie nur mit etlichen kg bewegt werden kann?

Gruß
Helmut

Hallo zusammen,

vielen Dank für die Anmerkungen, ich versuche das mal der Reihe nach abzuarbeiten.

1) Der Fehler taucht auch in Luft auf
2) Fräsparameter, Lockere Z-Achse: Nein, die Softwareanzeige der Maschinenposition springt vom Sollwert auf einen willkürlichen Wert, die Maschine versucht dann, den Sollwert wiederherzustellen. Sieht man auch im Fräsbild, das noch eine Weile gut bleibt, bis dann die Zustellung zu hoch wird und das Plexi aufschmilzt. Das gleiche passiert uns auch willkürlich in allen anderen Achsen.
3) Spannzange: Wir arbeiten mit einem Fahrion ER11-Spannzangensatz von Hoffmann, da haben wir alle Größen vorrätig. Die Spannzangen sind neu und passen immer zum Fräser. Ich kann ausschließen, dass es da ein Problem gibt.

Allgemeine Einstellung der Maschine: Der Fehler tritt in allen drei Achsen und immer willkürlich auf, auch in Luft. Das Fräsbild ist zufriedenstellend bis der Fehler auftritt. Es gibt auch kein "allmähliches Tieferwandern" - der Werkstücknullpunkt springt um und erst dann folgt die Maschine.

Ich tippe ehrlich gesagt eher auf ein Übertragungsproblem. Passt symptomatisch eher zum "Internetsachen sind ein Problem".

Gruß, Christian

liegt eher an der USB übertragung/ schnittstelle

Nach der Beschreibung denke ich auch mehr an die Kommunikation.
Versuch es mal ohne andere USB geräte, zumindest aber ohne andere USB Geräte an dem Hub der Fräse.
Außerdem die Energiesparoptionnen des USB Anschlusses ausschalten - obwohl das eher für den Verlust der Verbindung sorgt.
Liegt das USB kabel frei von anderen Kabeln die da ev. rein stören können?
Und Jens schreibt öfter von einer Durchkontaktierung auf dem USB modul die genau über einem ungenutzten Befestigungspunkt liegt die man im falle des Falles isolieren sollte.

Hth

Hast du die Möglichkeit an einem anderen PC/Laptop zu testen? Wenn da das gleiche Problem auftritt, dann bleibt nur noch das USB-Kabel oder die USB-Karte selbst.

Moin,

diese Problem hab ich auch und es ist nicht reproduzierbar. Allerdings tritt dieser Fehler bei mir nur auf, wenn ich den Fräsjob anhalte. Dann verstellt sich manchmal ein Parameter des Nullpunktes. Meistens ist es der X-Nullpunkt, aber Y- und Z-Nullpunkt waren schon betroffen.





Ich hatte darauf hin Herrn Lewetz um ein Update gebeten und bekommen, aber auch da tritt der Fehler noch sporadisch beim Anhalten des Fräsjobs auf.

Eine Lösung für das Problem hab ich leider auch noch nicht gefunden, außer, den Job vollständig durchlaufen zu lassen.

sswjs, aka jens

Vielleicht hilft ja ein downgrade auf ne ältere Version eher?

Wie kann denn das Problem an der USB Schnittstelle/Karte/Kabel sein wenn die Anzeige in der Software einen falschen Wert anzeigt? Es gibt ja keine Rückmeldung, somit kann das Problem nur bei WinPC NC sein, wenn der G-Code in Ordnung ist. Ich hatte zuletzt ja auch des öfteren Probleme mit dem Soll/Ist Wert. Da ich kein WInPC mehr habe konnte ich an Hr. Lewetz auch keine weiteren Daten liefern.

Ich würde vorschlagen das Log zu aktivieren und an Hr. Lewetz zu senden, vielleicht kann er ja das Problem auflösen

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.

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.

Als Inschenör hat mans schon schwer!

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

Moin,

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

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

MagIO2 wrote: 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

MagIO2 wrote: 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,

HOT2014 wrote: 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?)