Z-Offset changes suddenly during first layer

Diamondback

I'm trying to print a dual color print atm and while the first layer worked fine, it's now really squishing things and digging through already printed filament on the following layers...

Here's an M122 while printing:

=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.2.2 running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DGM-917NK-F2MS4-7J9F2-3S86N-TYTWF
Used output buffers: 3 of 24 (21 max)
=== RTOS ===
Static ram: 23460
Dynamic ram: 75220 of which 80 recycled
Never used RAM 13320, free system stack 95 words
Tasks: NETWORK(ready,161) HEAT(blocked,308) DUEX(blocked,31) MAIN(running,378) IDLE(ready,20)
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:19:11 ago, cause: software
Last software reset at 2021-03-24 02:28, reason: User, GCodes spinning, available RAM 13980, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x10
Aux0 errors 0,0,0
MCU temperature: min 30.5, current 35.4, max 35.8
Supply voltage: min 23.7, current 24.1, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: position -12343, ok, SG min/max 0/1023
Driver 1: position 6131, ok, SG min/max 0/1023
Driver 2: position 4549, standstill, SG min/max 0/511
Driver 3: position 46000, ok, SG min/max 0/1023
Driver 4: position 0, standstill, SG min/max 0/1023
Driver 5: position 0, standstill, SG min/max not available
Driver 6: position 0, standstill, SG min/max not available
Driver 7: position 0, ok, SG min/max 0/1023
Driver 8: position 0, ok, SG min/max 0/1023
Driver 9: position 0, ok, SG min/max 0/1023
Driver 10: position 0
Driver 11: position 0
Date/time: 2021-03-24 02:48:11
Cache data hit count 1315166420
Slowest loop: 139.34ms; fastest: 0.17ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 1.7ms, write time 212.2ms, max retries 0
=== Move ===
DMs created 83, maxWait 85022ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 18369, completed moves 18330, hiccups 29, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state 3
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
Heater 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.4
=== GCodes ===
Segments left: 1
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is doing "G1 X-23.903 Y-16.126 E0.0159" 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
LCD 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: 213.79ms; fastest: 0.00ms
Responder states: HTTP(0) 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 0
WiFi firmware version 1.25
WiFi MAC address b4:e6:2d:52:f2:a9
WiFi Vcc 3.43, reset reason Power up
WiFi flash size 4194304, free heap 26848
WiFi IP address 192.168.1.31
WiFi signal strength -59dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0
=== DueX ===
Read count 14, 0.73 reads/min

I'm trying to let it run through, maybe the printed part gives some hints...

o_lampe

@Diamondback
Your Z motors are on the DUEX5, maybe you have some problem with the board connector? Interference or bad contact.
To evaluate it, you could trade places with Coupler and Extruders.

Diamondback

Yes, the three Z motors are on the Duex. I have been running this specific Z setup since about a year (with just a single fixed hotend rather than toolchanging) with no issues, so I would rule out any "design" issues.
However, I will check all the connectors again, that could certainly be an issue.

Diamondback

My Moai print completed overnight and there are various distinct issues:

It appears that after a really clean first layer (I watched that live) the Z is not dropping enough in the next layers, the first mm or so it really squishes the filament into the previous layer. After 5 or so layers, it works fine, probably because it finally adjusted to the "wrong" Z.
The squish only happens on T0. T1 is not affected. That's in line with another dual color print from a few days ago where the same issue showed.
In addition, any other layer than the first shows a weird Y axis offset. First layer is ok, everything after that not so much.

To me it appears that for some reason, the tool offsets are not used correctly...

I'm calibrating my tool offsets in X, Y and Z with the E3D vernier scale print.

Diamondback

Here's a scan of the underside of the Moai.
What you can see here is the following:

The thin green line indicates the normal outer perimeters (3 lines à 0.3mm for copper, 3 lines à 0.4mm for dark grey) I watched these lines lay down during the first layer and they were as good as I can hope for
Everything past the green line is filament that squished down from the following layers, it wasn't there when the first layer finished.
There is no meaningful offset in X or Y between the two filaments in the first layer, while later in the print there is

Squished first layers

Offset in Y (see the gap next to the ear)

Filament being squished out the front

o_lampe

@Diamondback
Does the gap reflect your y-offset, but in the wrong direction?
I've just started with dual tool stuff and was surprised to read that eg. for copy mode the offsets have reversed signs.
Meaning, the X-axis left from center gets a positive offset (although it's on the lower side), the U axis is on the right off the center and has a neg. offset.
Not sure about Z offset, but if you've set your offsets wrong, it would explain a lot. (but not the Random factor)

Diamondback

What surprises me is that the E3D offset calibration print works perfectly fine in terms of X/Y calibration. (In case you don't know that, it's basically a vernier scale that you print and then you can easily see what offsets there are currently)
Looks like this:
alt text

And of course that the X/Y offsets work fine for the first layer...

jay_s_uk

@Diamondback why not use TAMV? much easier for nozzle X/Y calibration https://github.com/HaythamB/TAMV

Diamondback

@jay_s_uk Yea that's supposed to be the next step, but I really think something is fundamentally wrong with my setup and the vernier print should work just fine for getting things to print in a useful manner.
I mean, even single extruder prints don't work due to the Z issue...

dc42

Have you checked that the 8 screws that hold the bed assembly to the linear rail slider are tight? I was getting wildly varying height maps, and the reason turned out to be loose screws.

EDIT: I see from an earlier post that you gave 3 Z motors, so it is not an E3D TC and the above probably doesn't apply.

Diamondback

@dc42 Yep, custom motion system, will check all the Z mountings anyway, good idea

Diamondback

I've just printed a portion of the Moai with switched extruders, so what was previously printed by T0 is now T1 and vice versa.

Observations:

T0 Z-Offset worked for about 3/4 of its layer, then it blocked the nozzle, I let it continue because T0 was the accents so no huge harm
T1 Z-Offset is spot on, first layer consistently looks as good as it used to look before the toolchanging hardware
T1 following layers are all perfectly aligned in X, Y and Z, this makes me think that my motion system itself is fine (ie no huge Z backlash issues or head positional issues)
T0 following layers show the known problem, not aligned properly, squishing in all directions...

This leads me to the following possible causes:

T0 tool is somehow broken or damaged and behaves differently than what is expected
T0 offsets are being messed with in software somehow

Diamondback

Oh wow, I think i finally figured out what's going on. At least something that is going on.

My hotend holder is deforming under the pressure from the extruder... This tilts the whole hotend, moving the nozzle in Y and Z.

I just noticed this very extremely when going from first to second layer, the first layer is fairly slow (30m/s) and the second is twice as fast.
The higher speed deformed the holder a lot more, giving an explanation for the perfect first layer and then the sudden issue with layer 2.

I'm not sure yet why it would cause issues during the first layer as it still sometimes does, but right now I'm printing beefier holders and then see if that helps.
T1 was also less affected since it's using a 0.4mm nozzle vs the 0.3mm on T0...

Fingers crossed that this is purely a hardware issue on my side and no obscure firmware thing

Diamondback

Yea, I think this was indeed the problem. After installing much stronger parts for the hotend holder, the nozzle does not dive anymore. (Btw these weren't stupidly small parts or bad filament, they were printed in carbon fiber reinforced nylon, which is much stiffer than anything else I have around, so that really wasn't on my radar...)