Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    Tool switch causes Z dive after Z-probing with piezo

    Scheduled Pinned Locked Moved
    Tuning and tweaking
    2
    5
    182
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • k2biotechundefined
      k2biotech
      last edited by

      Hi, I'm having an issue with tool switching after Z probing with a piezo.

      My setup is 3 side-by-side syringes mounted on the Z axis, while the bed holds a Petri dish that moves on the X and Y axes. I have an underbed Precision Piezo for detecting the locations of the syringe needles so I can set Z offsets between them, and an endstop mounted at the top of the Z axis for initial homing.

      I'm essentially trying to find Z offsets between the needles before each print (instead of hard coding the offsets) since there will likely be variation when future users load the syringes and needles. In order to set offsets between the needles, I'm trying to probe the bed using T0 and set that location as my Z=0 using the command G30 S-2. After, my plan is to set relative offsets for the other tools by probing then using G31.

      However, I'm running into an issue where after I perform G30 S-2 (which runs fine, the Z axis stops moving when the needle hits the bed), my next tool switch does not work correctly. If I then use the command T1, the Z axis lifts up, then moves to the correct X- and Y-coordinates, but then rapidly moves down and does not stop, so I have to Emergency Stop. You can see in the image I've attached here, which is after an Emergency Stop, that the new tool (left) has moved to a position where the old tool's needle (right) is far below the print bed. In that picture, the new tool's needle is removed since the needles keep breaking.

      Needle Error Forum.PNG

      I've noticed that after tool switches, the Z axis moves back down to the location it was before I commanded it to lift up using tfree, but I'm not able to find this command anywhere in my tool switching files so I can't see if my issue might be due to the printer trying to find an absolute position using the new Z = 0. However, I think this would mean it's actually trying to go below the new Z=0 which I haven't enabled.

      Does anyone know how to resolve this issue for tool switching after setting a new Z=0, or a possible workaround for it so I can find offsets between my needles? Also, how can I access that line of code where the Z-axis moves back down to its position prior to the tool switch?

      Thanks so much!

      Config and Tool Switch Files (nothing in tpost):

      config.g
      tfree0[1].g
      tfree1.g
      tfree2.g
      tpost0.g
      tpost1.g
      tpost2.g
      tpre0.g
      tpre1.g
      tpre2.g

      1 Reply Last reply Reply Quote 0
      • Phaedruxundefined
        Phaedrux Moderator
        last edited by

        What firmware version?

        Can you provide the results of M122 and M98 P"config.g"?

        I notice you're using x256 microstepping on all axis. After doing some movements, can you check M122 for a hiccup count? It should be 0, more than 100 or so would indicate possibly missing steps.

        Z-Bot CoreXY Build | Thingiverse Profile

        1 Reply Last reply Reply Quote 0
        • k2biotechundefined
          k2biotech
          last edited by

          Hi, thanks so much for the response!

          My firmware version is 3.11 and I'm using a Duet 2 Wifi.

          Here are the results from M122 after my homing sequence. Does this indicate missed steps?

          3/24/2021, 4:57:20 PM	
          M122
          === Diagnostics ===
          RepRapFirmware for Duet 2 WiFi/Ethernet version 3.1.1 running on Duet WiFi 1.02 or later + DueX5
          Board ID: 0JD0M-9P6B2-NJ4S8-6JKDL-3S46M-KS6YM
          Used output buffers: 3 of 24 (23 max)
          === RTOS ===
          Static ram: 27980
          Dynamic ram: 95528 of which 44 recycled
          Exception stack ram used: 616
          Never used ram: 6904
          Tasks: NETWORK(ready,364) HEAT(blocked,1224) DUEX(suspended,160) MAIN(running,1828) IDLE(ready,80)
          Owned mutexes:
          === Platform ===
          Last reset 03:03:49 ago, cause: power up
          Last software reset at 2021-03-18 22:33, reason: User, spinning module GCodes, available RAM 6888 bytes (slot 1)
          Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task MAIN
          Error status: 0
          MCU temperature: min 35.2, current 35.6, max 36.0
          Supply voltage: min 12.1, current 12.1, max 12.3, under voltage events: 0, over voltage events: 0, power good: yes
          Driver 0: standstill, SG min/max not available
          Driver 1: standstill, SG min/max 0/171
          Driver 2: standstill, SG min/max 0/323
          Driver 3: standstill, SG min/max not available
          Driver 4: standstill, SG min/max not available
          Driver 5: standstill, SG min/max not available
          Driver 6: standstill, SG min/max not available
          Driver 7: standstill, SG min/max not available
          Driver 8: standstill, SG min/max not available
          Driver 9: standstill, SG min/max not available
          Date/time: 2021-03-24 16:57:14
          Cache data hit count 4294967295
          Slowest loop: 6.60ms; fastest: 0.13ms
          I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
          === Storage ===
          Free file entries: 10
          SD card 0 detected, interface speed: 20.0MBytes/sec
          SD card longest read time 3.6ms, write time 0.0ms, max retries 0
          === Move ===
          Hiccups: 2448(0), FreeDm: 169, MinFreeDm: 167, MaxWait: 139347ms
          Bed compensation in use: none, comp offset 0.000
          === MainDDARing ===
          Scheduled moves: 50, completed moves: 50, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
          === AuxDDARing ===
          Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
          === Heat ===
          Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
          === GCodes ===
          Segments left: 0
          Movement lock held by null
          HTTP is idle in state(s) 0
          Telnet is idle in state(s) 0
          File is idle in state(s) 0
          USB is idle in state(s) 0
          Aux is idle in state(s) 0
          Trigger is idle in state(s) 0
          Queue is idle in state(s) 0
          Daemon is idle in state(s) 0
          Autopause is idle in state(s) 0
          Code queue is empty.
          === Network ===
          Slowest loop: 201.74ms; fastest: 0.09ms
          Responder states: HTTP(2) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
          HTTP sessions: 1 of 8
          - WiFi -
          Network state is active
          WiFi module is connected to access point 
          Failed messages: pending 0, notready 0, noresp 12
          WiFi firmware version 1.23
          WiFi MAC address f4:cf:a2:e3:28:fe
          WiFi Vcc 3.38, reset reason Unknown
          WiFi flash size 4194304, free heap 23560
          WiFi IP address 192.168.2.109
          WiFi signal strength -56dBm, reconnections 0, sleep mode modem
          Socket states: 0 0 0 0 0 0 0 0
          === DueX ===
          Read count 0, 0.00 reads/min
          

          And M98 P"config.g" returns the following (as a note, I'm not using Heater 0 which is my heated bed; I'm running at room temp for now):

          M98 P"config.g"
          HTTP is enabled on port 80
          FTP is disabled
          TELNET is disabled
          Error: bad grid definition: X range too small
          Warning: Heater 0 appears to be over-powered. If left on at full power, its temperature is predicted to reach 365C
          

          Thanks!

          Phaedruxundefined 1 Reply Last reply Reply Quote 0
          • Phaedruxundefined
            Phaedrux Moderator @k2biotech
            last edited by

            @k2biotech said in Tool switch causes Z dive after Z-probing with piezo:

            Hiccups: 2448(0)

            That may indicate some missed steps or micro pauses, but 2000ish isn't too bad. It's probably not too high because you're not trying to move very fast.

            The trinamic drivers will internally interpolate from x16 microsteps to x256. So I would suggest trying x16 microsteps with interpolation to see how it goes. I don't know if you're application warrants that high a microstepping level, but I kind of doubt it.

            I think the bad grid definition error is coming from this line M557 X0:0 Y0:0 S1 ; define mesh grid Maybe just comment that line out entirely if you're not going to use mesh compensation.

            I'll see if I can get DC24 to take a look at the tool change z movement and explain what's happening, because I'm not really sure.

            Z-Bot CoreXY Build | Thingiverse Profile

            k2biotechundefined 1 Reply Last reply Reply Quote 1
            • k2biotechundefined
              k2biotech @Phaedrux
              last edited by

              @phaedrux
              Hi, thanks so much for your help! Just wondering if you or DC24 have any updates on the tool change Z movement issue?

              1 Reply Last reply Reply Quote 0
              • First post
                Last post
              Unless otherwise noted, all forum content is licensed under CC-BY-SA