Posts made by k2biotech

In the 3.1.0 Changelog, it says in upgrades that "after a tool change, the user Z coordinate is restored immediately instead of by the end of the next G0 or G1 command." Does anyone know of a way to override this?

I have 3 tools that I want to find Z offsets for, relative to T0. I'm currently trying to perform a Z probe (underbed piezo), set that location as my new Z = 0, then switch the tool and probe again. However, G30 S-2 causes the tool to slam down into the bed after I call for a tool switch (this doesn't happen with G30 S-1)

I think it's because of the Z coordinate restoration. The probe normally triggers at around Z = 25 so when G30 S-2 sets that location to Z = 0 and I try to perform a tool switch, it seems like the printer is trying to move down to "find" the original Z = 25 value even though it starts out at a lower value already so it can never find that position.

Does anyone have any suggestions on how I can remove the Z restoration feature without reverting my firmware back to an older version? Alternatively, does anyone have a more efficient way of finding Z offsets for multiple tools with a piezo on a moving bed? Thanks!

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

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!

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.

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