Eding verwendet Z phantasie Höhe

So wie du schreibst hört es sich eher nach einem Fehler im CAM Programm an.

EdingCNC fährt nur die Werte an welche im CAM aufgerufen werden.

Hi timka,

kannst du noch ein paar mehr Details geben? Welche Version von Eding nutzt du? Was ist "erste Bewegung"? Vor/Nach der Referenzierung, oder die erste Bewegung im Job?

Welche Sicherheitshöhe (ZUpDistance im Einstellungsmenü unter Spindel) hast du in Eding konfiguriert? (Und welche in deinem CAM)? Hast du vielleicht aus Versehen die Z-Höhenkompensation "ZHeightComp" aktiviert? Hast du unter Variables irgendwas im G54 Koordinatensystem-Offset stehen? Oder ein G92 offset definiert?

Schöne Grüße

Schallbert

Hi timka,

dann lass' uns das mal schnell zusammen eingrenzen:

Zitat von timka

Dann wird gestartet und Z Höhe ist aufeinmal nicht mehr Null sondern z.B. -3,41 mm

Das bedeutet, dass die Z-Achse runtergeht und Eding dir das auch noch anzeigt? Da du Servos hast die eine Rückmeldung über die erfolgte Bewegung geben kannst du dir damit also sicher sein, dass deine Ansteuerung (z.B. Midi-Steuerung) sauber ist und das Problem mit deinem Laptop oder der Kommunikation mit dem CNC Board zu tun hat - ansonsten sollte doch automatisch der Not-Aus losgehen wegen Wertebereichsüberschreitung / Schrittverlust.

OK, damit hätten wir weiterhin mindestens 3 mögliche Ursachen:

- Gestörte Kommunikation zur Maschine (Schutzleiter ordentlich angeschlossen, Absaugung und jegliche Peripherie wie Kühlung, Werkzeugwechsler, Zusatzachsen fachgerecht über den Sternpunkt am Gehäuse der Steuerung geerdet, Watchdog-Timer in EdingCNC schön klein eingestellt, FIFO-Puffergröße groß genug, Rechner hängt nicht kurz mit Befehlen hinterher?)

- Irgend ein Offset der manchmal einfach so kurzzeitig reinhaut (Guck' dir im Bildschirm "Variablen" mal die Werte an die Eding so gerade verwendet, checke nochmal G54-G59.2 und G92 sind auch wirklich OK?)

- Unbewusste manuelle Eingriffe (z.B. Handrad gibt ein Signal aus obwohl es das nicht tun sollte, irgendwas im Hintergrund sagt Eding es soll die Achse verfahren?)

Ich weiß, das sind mal wieder sehr viele Dinge auf einmal, aber ich fürchte, du wirst die möglichen Ursachen koordiniert und Stück für Stück ausschalten müssen, denn solche sporadischen Fehler sind meiner Erfahrung nach die gemeinsten.

Wenn du nach all dem immer noch nicht weiterkommst, kannst du auch bei Eding direkt ein Ticket aufmachen und die Leute dort mal reinschauen lassen.

Viel Erfolg!

Schallbert

HI timka,

Wie du schon sagtest, ist ein Kommunikationsfehler unwahrscheinlich, da EdingCNC die geänderten Werte ja selbst anzeigt. Um eine zu langsame Kommunikation dennoch auszuschließen, könntest du die Werte InterpolationTime und FifoTime versuchshalber hochsetzen, z.B: auf 10ms/1000ms - damit kann der Puffer dann 100 Zwischenschritte speichern, die mit bis zu 100Hz ausgewertet werden (statt 50 Zwischenschritte bei 200Hz), das gibt dir 4x mehr Luft nach oben. Nachteil hier ist möglicherweise, dass sich die Maschine irgendwie verzögert anfühlen oder geringfügig an Genauigkeit verlieren könnte.

Du kannst auch mal probieren, das keyboard time-out runterzusetzen, etwa auf 0,1s und damit sichergehen, dass Eding nicht irgendwelche Probleme mit Tastatur/Maus/sonstwas als "verfahr' doch mal Z nach irgendwo" interpretiert.

Ansonsten gehe ich davon aus, dass dein Rechner fix genug ist, keinen Zugang zum Internet hat und unter einem älteren Betriebssystem wie Win7 läuft, da die weniger patch-wütig sind.

Wenn das alles noch immer nichts bringt, lege ich dir den Support von Eding ans Herz - genug Daten hast du ja dann sammeln können (super zur Diagnose wäre noch ein Video wo der Fehler gerade auftritt) und hoffe, du hältst das Forum auf dem Laufenden bezüglich einer Lösung

Schönen Abend

Schallbert

Noch eins, fällt mir gerade ein:

Du hast nicht zufällig selbstgeschriebene oder modifizierte Makros im Einsatz...? Die können ziemlich fiese Fehler machen, wenn man z.B. nach einem G91 vergisst, nach G90 zurück zu schalten usw.

Gruß

Schallbert

Zitat von Schallbert

Noch eins, fällt mir gerade ein:

Du hast nicht zufällig selbstgeschriebene oder modifizierte Makros im Einsatz...? Die können ziemlich fiese Fehler machen, wenn man z.B. nach einem G91 vergisst, nach G90 zurück zu schalten usw.

Gruß

Schallbert

GEIL wie hier geholfen wird, lese am Rande zwar nur mit, da ich zur Zeit Estlcam nutze, aber Wahnsinn was "du/ihr" so alles aus dem Stehgreif an Tipps so raus schüttet

Zitat von timka

. Man kennt es ja aus anderen Foren, dass sich jeder angesprochen fühlt, obwohl er keine Ahnung hat.

Ja auch das kenne ich, anstatt Tipps und Tricks zu geben, kommen so Sachen wie " Kauf das doch fertig. " oder " mach doch nur 2 statt 4 Achsen für deinen Anhänger"....

Hi, danke euch für die Blumen

Zitat von timka

Aber meinste wirklich das es daran liegt, da dies beim ersten Schritt der Maschine passiert.

Es ist halt möglich, dass sich das System beim Programmstart kurz verschluckt, weil der Puffer zu Anfang leer ist und der Rechner ganz plötzlich ein Haufen Kommandos ausführen muss, die vorher nicht kamen, weil das System da noch praktisch im Leerlauf war. Ausschließen würde ich das jedenfalls erst, wenn das Problem trotzdem noch auftritt.

Also direkt wenn du F4 / Start drückst, passiert das Verrutschen in Z. Und nur in Z, nicht auch X oder Y. Und: die Maschine korrigiert das nicht mehr, sondern fährt dann mit veränderter Z0 Höhe weiter, Zeigt etwas an wie -3mm? So hatte ich dich jedenfalls verstanden. Als hätte die automatische Z-Kompensation zugeschlagen aber G43 (Werkzeuglängenkompensation) ist ja aus hast du geschrieben, das kann's also nicht sein. G53 (Absolute Koordinaten verschieben) wäre noch so ein Kandidat für sowas, ist aber meist Teil eines Makros.

Um Handeingaben auszuschließen, versuch' doch mal zu joggen während ein Job läuft. Das darf eigentlich nicht gehen.

Zitat von timka

das Problem bei der Ausführung des Werkzeuglängenmakros schonmal aufgetreten ist, kann man dann nicht Fifo Time und G90 / G91 ausschließen?

Das Problem kannst du sicher ausschließen, wenn nach jedem Kommando G91 wieder ein G90 kommt, was auf absolute Koordinaten zurück stellt. Das ist aber leicht herauszufinden, wenn du dir deine macro.cnc genauer anschaust.

Das mit der FiFo Zeit ist nicht sicher auszuschließen, weil der bei jedem Kommando von Eding an die Maschine benutzt wird, egal ob Makro, Job, oder sogar Verfahren per Hand/Jograd. Aber es ist halt nicht der wahrscheinlichste Fehler.

Zitat von timka

Habe nur eine Veränderung für die Vermessung eingefügt

Was genau ist das für eine Veränderung?

Wenn ich noch einen Tipp geben darf, ich würde jetzt versuchen, den Fehler auf Teufel komm' raus zu reproduzieren, zur Not denselben Job 20x in der Luft fahren lassen (Natürlich sofort abbrechen, wenn der Fehler nicht auftritt, Reset drücken, Job nochmal starten). Und wenn du dann immer noch nicht den Fehler siehst, nach jedem Job-Start-Stop Zyklus Eding neu booten. Einfach um ein Gefühl für das Problem zu bekommen. Dann ein Video parat haben wo das System von allein verfährt und ab damit zum Eding Support.

Sorry, dass ich nicht wirklich helfen konnte.

Schallbert

Hi timka,

gern, danke. Ich habe hier noch etwas für dich, das du mal beobachten kannst (Aus dem EdingCNC Handbuch):

Während der Initialisierung wird das Koordinatensystem ausgewählt, das durch Parameter 5220 angegeben wird. Ein Wert von 1 bedeutet: das erste Koordinatensystem (G54 ist aktiv), ein Wert von 2 bedeutet das zweite Koordinatensystem (G55) und so weiter.

Du solltest also währed deiner Experimente mal diese Variable im Variablen-Tab eingeben und beobachten, was die Maschine so macht.

Parallel dazu kannst du die Parameter 5211-5216 überwachen, sie gehören zum Versatz der Absolut-Koordinaten G92(.1, .2, .3).

Denn "Zusätzlich werden die Parameter 5211 bis 5216 auf die Versätze der X-, Y-, Z-, A-, B- und CAchse eingestellt. Der Versatz für eine Achse ist der Betrag, um den der Ursprung verschoben werden muss, damit die Koordinate des gesteuerten Punkts auf der Achse den angegebenen Wert hat."

Wenn also 5220 auf 1 steht und 5211-5216 alle auf 0, dann arbeitest du im "Standard Koordinatensystem" und alles ist gut - dann kannst du Koordinatensysteme als Fehler endgültig ausschließen.

Schöne Grüße

Schallbert

Das hört sich nach einem ganz typischen Verhalten an wenn man Entweder beim Abnullen im falschen Koordinatensystem unterwegs war (G55 abgenullt aber der GCODE nutzt G54) oder aber die Länge vom Fräser mit dem man abnullt war nicht richtig gespeichert oder wird beim Programmstart neu geladen (Bin mir bei Eding nicht sicher aber denke dort wird das auch mit einem G43 geladen).

Schau mal ob in einem GCODE der das Problem schon mal gezeigt hat in den ersten Zeilen was von G54 G55 G56 etc.... steht oder ein G43 H irgendwas.

Wenn bei einer dieser Zeilen dein Z ohne Maschinenbewegung springt war da in der Richtung was nicht richtig.

Ganz häufiger Fehler den ich schon öfter gesehen habe:

- Maschine wird angeschaltet.

- Fräser wird eingespannt (ohne ihn zu vermessen oder per T* M06 auf den Fräser zu wechseln)

- Z 0 wird gesetzt

- Programm wird gestartet.

- Entweder wird der Fräser sogar per Längenmessung noch mal neu vermessen oder aber "nur" die Länge per G43 aus der Tool Table geholt wo noch irgendwas altes steht

- Z Höhe passt so überhaupt nicht

- User bekommt es früh genug mit, stoppt das Programm

- Versucht es noch mal neu, setzt Z noch mal neu

- Plötzlich funktioniert es

Ein verwandter Fehler, den ich vor kurzem hatte:
Nach dem Messen der Z-Höhe auf dem Werkstück wird eine Position 5 mm über dem Sensor angefahren.

Wenn diese Fahrt die Limits (z Max) überschreitet, dann wird die komplette Messung ignoriert.

Der Job lässt sich dann aber trotzdem starten, die Höhe passt aber nicht. -> Schreckmoment...

Aber du schreibst ja auch, dass das nicht nur nach Sensor-Messung passiert, daher vermutlich nicht die gleiche Ursache.

Vielleicht trotzdem für den ein oder anderen interessant.

Hey krizlee,

Zitat von krizlee

Vielleicht trotzdem für den ein oder anderen interessant.

Ich habe für dieses klare Makro-Problem mal ein "issue" in meinem Github Repo aufgemacht. Lass uns solche Probleme dort sammeln, dann können wir wenn wir das Makro in Zukunft versionieren direkt die Problembehebung referenzieren.

Bei dem ursprünglichen Thema hier ist die Ursache denke ich noch nicht 100% gefunden - sollte das ebenfalls im Makro liegen machen wir dafür natürlich auch ein Ticket auf.

Guten Rutsch!

Schallbert