Werkzeuglängenmessung

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Werkzeuglängenmessung

      Hallo,
      eine kurze Frage an Alle die eine Touchprobe und den Touchscreen unter LinuxCnc verwenden.
      Wenn ich die Anleitung richtig verstehe und da brauche ich Bestätigung, funktioniert das mit dieser Oberfläche wie folgt:
      Zuerst misst man mit der Probe die Höhe des WL Sensors auś und danach die Höhe des Werkstücks. Damit sind beide z-Positionen bekannt, bzw. deren Differenz und mit dem Fraser kann man danach auf den WLZ fahren und weiss wieviel Abstand zum Werkstück ist. Aber ich denke das funktioniert nur, wenn der z-Nullpunkt auf der Werkstückoberfläche liegt, richtig?
      Bei mir liegt der Nullpunkt im Moment immer auf der geplanten Aufspannfläche und die positive z- Koordinatenrichtung zeigt nach Oben. D.h ich habe meine Programme immer mit positiven z-Maßen gemacht, weil mir das logischer/einfacher erschien.
      Wie macht ihr das mit der Probe?
      LG Albert
      Nur Fliegen ist schöner.

    • Eigentlich sollte die Lage von Werkstück 0 egal sein - die Verrechnung erfolgt immer gegen den WZL und damit ist das irrelevant.

      Ablauf:
      1) Du misst ein Werkzeug ein (Einwechseln, mit dem Sensor vermessen)
      2) Du nimmst dieses Werkzeug und tastest damit dein Werkstück/ deinen Nullpunkt an (Taster, Ankratzer, Lichtspalt)
      3) du setzt Z=0 in deinem Werkstückkordinatensystem (idR G54)

      Ab jetzt kannst du das Werkzeug tauschen, neues WZ einspannen, wieder vermessen und gut ist. Der WZL bleibt dabei ortsfest.
      Ggf. hilft ein Blick in das entsprechende Macro von gmoccapy oder - und das ist mir lieber - in das M6 Remap von Probe_screen.
      github.com/verser-git/probe_sc…/macros/manual_change.ngc

      Hilft dir das?

    • Mit einem 3D-Taster würde ich das Werkstück nicht mehr mit einem Werkzeug (Fräser) antasten - das macht der 3D-Taster. Mein geplanter gedanklicher Ablauf ist:

      1. 3D-Taster einspannen und gegen WZLS vermessen.
      2. Z-Antasten mit 3D-Taster (ob nun OK Werkstück oder OK Opferplatte ist egal)
      3. Werkstück X/Y antasten mit 3D-Taster
      4. Auf Fräser wechseln und gegen WZLS vermessen
      5. Fräsen
      6. Wechseln
      7. Fräsen
      8. Wechseln
      9. Fräsen
      10. (...)
      11. Aufhören weil fertig
      Gruß

      Andreas

    • So langsam kriege ich einen Vogel mit der Werkzeuglängenmessung.
      Also die Vermessung der Toolsensor (TS) Höhe und der Werkstückhöhe funktioniert inzwischen.
      Aber wenn ich ein Programm starte, dann fährt er zu der Wechselposition und normalerweise erscheint dann die Meldung, dass man mit "ok" bestätigen soll, wenn das Werkzeug gewechselt ist. Aber die kommt nicht und und deshalb steht das Programm.
      Kann es sein, und nun kommen wir zu dem 2. Problem, dass sowohl die Touchprobe, als auch der TS elektrisch gesehen auf den gleichen Eingang gehen müssen, also elektrisch "verodert" sein müssen? Der Teil fehlt mir nämlich gerade noch. Alternativ könnte man denke ich, es auch in der HAL machen.
      Vor dem Gebrauch der Touchprobe war die Verschaltung für den Werkzeuglängensensor nämlich so in meiner HAL:
      net werkzeuglaenge <= hm2_5i25.0.7i76.0.0.input-03-not
      net werkzeuglaenge => motion.probe-input

      Damit funktionierte bislang die Werkzeuglängenmessung mit den Settings wie hier in Kapitel 6 beschrieben Auto tool measurement. Allerdings musste ich die Sensorhöhe manuell ermitteln, wie schon oben geschrieben.

      Die Hal Verbindungen die bei Gmoccapy beschrieben werden, sind jetzt rausgeflogen, da ich die Oberfläche von vers.by benutzen will und daher die Verbindungen wie dort im Manual angegeben verwende.

      Jetzt habe ich in Fenja.hal:
      net werkzeuglaenge <= hm2_5i25.0.7i76.0.0.input-03-not
      net werkzeuglaenge => motion.digital-in-00
      net probe-input <= hm2_5i25.0.7i76.0.0.input-04
      net probe-input => motion.probe-input

      und in custom_postgui.hal

      # tool change
      # in case they were linked already
      unlinkp iocontrol.0.tool-change
      unlinkp iocontrol.0.tool-changed
      net tool-prep-loopback iocontrol.0.tool-prepare <= iocontrol.0.tool-prepared

      Was ja so noch nicht funktionieren kann, weil ich mit motion.digital-in-00 noch nix weiter mache.
      Eigentlich muss ich doch die Signale "werkzeuglaenge" und "probe-input" auf ein Oder-Glied geben und dessen Ausgang geht auf "motion.probe-input" oder?

      Bitte um kurze Bestätigung, dann würde ich das morgen probieren. Heute gehe ich nicht mehr in den Keller.
      LG Albert
      Nur Fliegen ist schöner.

      The post was edited 1 time, last by millingpenguin ().

    • Also das mit dem "verodern" in Software geht, auch wenn ich demnächst noch aus der NC Probe eine NO Probe machen muss, sonst ist es blöd wenn ich sie abstecke :). Aber das soll jetzt nicht das Thema sein.
      Das eigentliche Problem, dass die Quittierungsmeldung nicht kommt besteht immer noch. Manchmal frage ich mich, ob ich der einzige Depp auf dieser Welt bin, der solche Probleme hat :cursing: .
      Beim Debuggen bin ich nun bei folgendem Stand:
      In der ini steht ja die Zeile
      REMAP=M6 modalgroup=6 prolog=change_prolog ngc=manual_change epilog=change_epilog
      D.h. er ruft sobald der M6 Gefehl kommt die Datei manual_change auf, was er auch macht.

      In der manual_change.ngc steht am Anfang dieser Code drin (ich habe nur den Teil hier eingefügt, wo er auch hinläuft)

      ; manual toolchange with automatic tool length probe

      o<manual_change> sub
      ;(debug, in change tool_in_spindle=#<tool_in_spindle> current_pocket=#<current_pocket>)
      ;(debug, selected_tool=#<selected_tool> selected_pocket=#<selected_pocket>)

      ;otherwise after the M6 this information is gone!
      #<tool> = #<selected_tool>
      #<pocket> = #<selected_pocket>

      ; we must execute this only in the milltask interpreter
      ; or preview will break, so test for '#<_task>' which is 1 for
      ; the milltask interpreter and 0 in the UI's
      O100 if [#<_task> EQ 0]
      (debug, Task ist Null)
      O100 return [999]
      O100 endif

      ;first go up
      G90
      G53 G0 Z[#<_ini[AXIS_2]MAX_LIMIT>-1]
      ; then move to change position
      G53 G0 X[#<_ini[CHANGE_POSITION]X>] Y[#<_ini[CHANGE_POSITION]Y>]
      G53 G0 Z[#<_ini[CHANGE_POSITION]Z>]

      ; cancel tool offset
      G49

      ; using the code being remapped here means 'use builtin behaviour'
      M6

      Die Maschine läuft exakt bis zu M6

      Hat Jemand eine Idee, warum da nix mehr passiert?
      LG Albert
      Nur Fliegen ist schöner.

    • Hi an alle,

      ich möchte mir auch einen Wlz von vers.by zulegen. Jetzt habe ich eine Frage. Andreas hat den vers.mux angesprochen. Leider finde ich dieses Gerät nicht. Entweder bin ich zu doof dafür oder sonst etwas.

      Noch eine blöde Frage dazu. Kann ich den Vers WTSR als Wlz an einem "festen Ort" ,zum Beispiel in eine Art Halterung aus POM stellen und die Länge des Fräsers ablesen lassen und zugleich als Nullpunktfinder auf dem zu fräsenden Werkstück verwenden?

      Ich hoffe man versteht was ich meine.

    • millingpenguin wrote:

      Also das mit dem "verodern" in Software geht, auch wenn ich demnächst noch aus der NC Probe eine NO Probe machen muss, sonst ist es blöd wenn ich sie abstecke :). Aber das soll jetzt nicht das Thema sein.
      Das eigentliche Problem, dass die Quittierungsmeldung nicht kommt besteht immer noch. Manchmal frage ich mich, ob ich der einzige Depp auf dieser Welt bin, der solche Probleme hat :cursing: .
      Beim Debuggen bin ich nun bei folgendem Stand:
      In der ini steht ja die Zeile
      REMAP=M6 modalgroup=6 prolog=change_prolog ngc=manual_change epilog=change_epilog
      D.h. er ruft sobald der M6 Gefehl kommt die Datei manual_change auf, was er auch macht.

      In der manual_change.ngc steht am Anfang dieser Code drin (ich habe nur den Teil hier eingefügt, wo er auch hinläuft)

      ; manual toolchange with automatic tool length probe

      o<manual_change> sub
      ;(debug, in change tool_in_spindle=#<tool_in_spindle> current_pocket=#<current_pocket>)
      ;(debug, selected_tool=#<selected_tool> selected_pocket=#<selected_pocket>)

      ;otherwise after the M6 this information is gone!
      #<tool> = #<selected_tool>
      #<pocket> = #<selected_pocket>

      ; we must execute this only in the milltask interpreter
      ; or preview will break, so test for '#<_task>' which is 1 for
      ; the milltask interpreter and 0 in the UI's
      O100 if [#<_task> EQ 0]
      (debug, Task ist Null)
      O100 return [999]
      O100 endif

      ;first go up
      G90
      G53 G0 Z[#<_ini[AXIS_2]MAX_LIMIT>-1]
      ; then move to change position
      G53 G0 X[#<_ini[CHANGE_POSITION]X>] Y[#<_ini[CHANGE_POSITION]Y>]
      G53 G0 Z[#<_ini[CHANGE_POSITION]Z>]

      ; cancel tool offset
      G49

      ; using the code being remapped here means 'use builtin behaviour'
      M6

      Die Maschine läuft exakt bis zu M6

      Hat Jemand eine Idee, warum da nix mehr passiert?
      Spontan leider nicht. Was manchmal weitere debug info gibt, ist ein Start von linuxcnc aus der Konsole heraus. Manche Infos werden nur in dieses Fenster gedumpt. Vielleicht findest du es ja so.

    • Hallo Guido,

      die ganze Geschichte ist echt komisch. Ich habe gestern eine simulierte Maschine in Virtual Box auf meinem Desktop aufgesetzt und da läuft alles.
      Es liegt auf jeden Fall an dem Python Skript von der Touchprobe, vielleicht auch zusammen mit meiner Konfiguration.
      Ich werde denke ich den Rechner noch einmal neu aufsetzen und vielleicht auch eine Minimalmaschine ohne meine Erweiterungen einbauen. Vielleicht liegt es auch an dem Gamepad was ich zur manuellen Steuerung einsetze. Das ist die letzte Geschichte, die ich noch nicht ausprobiert habe. Aber das ist nur ein Strohhalm. So langsam gehen mir die Ideen aus.
      LG Albert
      Nur Fliegen ist schöner.

      The post was edited 1 time, last by millingpenguin ().

    • Hallo Albert,

      das klingt wirklich komisch. Ich kann nur anbieten einmal in die Config zu gucken und mit meiner abzugleichen. Diese ist online unter besagter github Adresse zu finden.

      VG

      Guido

      Nachtrag: gerade das Pythonscript schmeißt seine Fehler in die Konsole - da kommt nichts?

    • Hallo Guido,
      ich habe die Maschine noch nicht aus der Konsole raus gestartet, werde ich aber nachher machen.
      Meine config lade ich später gerne hoch. Aber du glaubst nicht, wie oft ich sie schon mit deiner verglichen habe :D .
      Hat vielleicht nix damit zu tun, aber gestern wollte ich die tooltable mit tooledit laden und bekam die Fehlermeldung dass der Parameter Q nicht floating, sondern Integer sein muss. Auf der Testmaschine könnte ich die aber laden. Beide Systeme sind übrigens frisch aufgesetzt und haben die gleichen Updates. Der Rechner an der Fräse ist nur ein alter HP und mein Hauptrechner brandneu. ;(
      LG Albert
      Nur Fliegen ist schöner.

    • Also erst einmal so halb bis 3/4 Entwarnung.
      Die Meldung für den Werkzeugwechsel erscheint jetzt und er misst auch :D .
      Was ich getan habe, ist in der custom_postgui.hal Datei die beiden unlinkp Befehle auszukommentieren.

      # tool change
      # in case they were linked already
      #unlinkp iocontrol.0.tool-change
      #unlinkp iocontrol.0.tool-changed

      Aber ehrlich gesagt gesagt weiss ich nicht warum man dies machen muss, weil es an der Stelle richtig ist und auch nach Anleitung. In meiner ursprünglichen config, bevor ich die Touchprobe hatte, war es auch so.
      In der probe_screen.hal Datei werden sie dann normalerweise auf das richtige Signal gelinkt.

      net tool-change probe.toolchange-change <= iocontrol.0.tool-change
      net tool-changed probe.toolchange-changed <= iocontrol.0.tool-changed
      net tool-prep-number probe.toolchange-number <= iocontrol.0.tool-prep-number

      Das würde ja bedeuten, das zuerst probe_screen.hal durchlaufen wird und danach die custom_postgui.hal und die trennt die Verbindung wieder ;( .
      Warum funktioniert es dann in meiner simulierten Maschine ohne die Auskommentierung?
      Ich bin zwar froh dass es funktioniert, würde es aber schon noch gerne verstehen, deshalb hänge ich meine komplette Config als zip Datei an.

      Als nächstes werde ich mal diesen sch... Lüfter an meiner PI9130 abklemmen und einen größeren und leiseren verbauen. Durch die vielen Stunden neben der Fräse, habe ich fast einen Hörsturz bekommen, so laut ist die Steuerung <X .
      Files

      • Fenja.zip

        (824.62 kB, downloaded 4 times, last: )
      LG Albert
      Nur Fliegen ist schöner.

    • Das wundert mich jetzt auch ein wenig. Die Riehenfolge der Scripte ist mir nicht bekannt, ich hätte aber auch getippt, dass die letzte die POSTGUI ist. Dem schein aber nicht so zu sein. Man könnte vermuten, dass Probe Screen ja in GMOCCAPY Embedded wird und daher dort erst seinen Call erhält. Das erklärt aber nicht, warum du es AUSkommentieren musstest.

      Nachtrag:

      Ich habe jetzt mal in deine Files geguckt:

      warum hast du ind er probe_screen.hal die Verweise auf die GMOCCAPY Befehle?

      Source Code

      1. net tool-change gmoccapy.toolchange-change <= iocontrol.0.tool-change
      2. net tool-changed gmoccapy.toolchange-changed <= iocontrol.0.tool-changed
      3. net tool-prep-number gmoccapy.toolchange-number <= iocontrol.0.tool-prep-number

      Vgl: github.com/GuiHue/myfenjalinux…be_icons/probe_screen.hal

      Ich habe mit einem anderen Fenjauser schon einmal per WhatsApp so eine Geschichte gejagt. Er hatte ebenfalls irgendwo gmoccappy Reste und damit ein riesen Theater mit Offsets...

      Nachtrag:
      Mehr kann ich gerade von unterwegs nicht nachvollziehen. Es ist wieder so eien Zeit im jahr, wo das Hobby nur Virtuell verfolgt werden kann:(.

    • Philipp wrote:

      Hi an alle,

      ich möchte mir auch einen Wlz von vers.by zulegen. Jetzt habe ich eine Frage. Andreas hat den vers.mux angesprochen. Leider finde ich dieses Gerät nicht. Entweder bin ich zu doof dafür oder sonst etwas.

      Noch eine blöde Frage dazu. Kann ich den Vers WTSR als Wlz an einem "festen Ort" ,zum Beispiel in eine Art Halterung aus POM stellen und die Länge des Fräsers ablesen lassen und zugleich als Nullpunktfinder auf dem zu fräsenden Werkstück verwenden?

      Ich hoffe man versteht was ich meine.
      Hi,

      musst Serguei direkt anschreiben;). Das Teil ist noch nicht im Shop gelistet, aber schon verfügbar. Meins ist schon unterwegs.

      Einen Vers WTSR als WZLS und als mobilen Nullpunktfinder zu verwenden ist nicht üblich. Du brauchst das Werkstück in Z auch nicht separat antasten, wenn Z-Opferplattenhöhe und die Dicke des Werkstücks bekannt sind ;) Ein "von hinten durch die Brust ins Auge-Lösung" ist bpsw. hier (funktioniert bei mir absolut zuverlässig).

      Kauf Dir einfach einen Toolsetter und eine Touchprobe und gut ist. So machen es die meisten und die Jungs aus der Industrie auch ;)
      Gruß

      Andreas

    • Hy Andreas,

      Achso!!! Ich habe mich jetzt auf vers.by mit einem Konto angemeldet. Ich dachte, dass sicher ein Newsletter kommen wird in dem das angepriesen wird.

      Stimmt Andreas...
      Der Spruch meines Großvaters trifft hier zu: Warum einfach wenn es auch kompliziert geht... :thumbsup: :thumbsup:

      Ich werde deinen Rat beherzigen und das so machen wie du geschrieben hast.

    • Hallo Guido,
      habe gerade nachgeschaut, die probe_screen.hal ist richtig. Du warst im falschen Ordner drin. Ich benutze den mit 1024x768. Den anderen hatte ich im Rahmen meiner Versuche benutzt zum rumspielen. Also es bleibt nach wie vor rätselhaft.
      Ich lasse es jetzt so und freue mich, bis es mich wahrscheinlich beim nächsten Problem einholt.
      LG Albert
      Nur Fliegen ist schöner.
    https://www.daswetter.com/