[3.5 RC1] Toolchanges messing up Z height?
-
Hey,
very weird problem here... Currently trying to do a 4 tool print on my toolchanger... I carefully calibrated X, Y and Z offsets of all tools to the point where the first layer goes down pretty perfectly.
Things become weird and when the printer does the second layer... My tool order on the first layer is T0, T1, T2, T3, second layer is T3, T0, T1, T2.Everything is fine until the printer switches to T0 on the second layer, at that point it adds like an 0.5-0.7mm offset on the Z axis and keeps printing way too high. Weirdly enough, the T3 (so the first tool being used) on that layer works perfectly fine with the correct Z height.
While things are going wrong with T0, DWC displays the correct Z height (0.4mm), so I assume something is wrong with the offsets?
I haven't printed past T0 on the second layer to see what the remaining two tools will do since I don't want to waste even more filament...Babystepping is at 0 and is not being touched during the print.
How do I even start to debug this? Has anyone seen something similar?
I've attached some images of the issue. Black is T0, beige is T1, green is T2, yellow is T3. All 4 first layers are perfect, second yellow layer is also perfect, second black layer is way too high.
-
undefined Diamondback marked this topic as a question
-
This happens every time btw, by now I have 4 of these failed attempts with the same symptoms. Restarted the printer inbetween as well.
Looks like we someone on the E3D discord server has the same issue:
https://discord.com/channels/756501859702800426/761238228690403328/1164609195987972097 -
@Diamondback What was the last version that worked correctly? Have you tried going back to that version?
-
@gloomyandy Seems to be new with RC1, I haven't seen such an issue on any of the previous 3.5 betas (b4 is what I used last).
Gonna roll back to b4 I guess and see...
-
@gloomyandy It's working fine on 3.5b4.
-
Hi,
@Diamondback Does any of your tool change routine (tpre#.g, tfree#.g, tpost#.g) contains
G92command?I am also fighting with similar Z axis drift issue. At this point of my investigations it seems like this issue is related to the use of the
G92command, with or without Z argument, in the RRF3.5.0rc1 firmware.In my case, the issue occurs quasi-randomly whenever using the
G92command in either a gcode print file or a system macro.
I say "quasi-randomly" in the sense that not every execution of aG92triggers the bug, but when the bug occurs printer coherently acts as if the last movement of the Z axis before the G92 command was properly executed but not being tracked ( @dc42ms.coords[Z_AXIS]variable not updated at some point between the beta4 and rc1 ?), not as if one board had randomly hung, or executed some corrupted data. I say "coherently act" because:- on system ①, I am using 2 separated 1HCL boards each controlling 1 of the 2 independent Z axis motors of the printer. From time to time I observed Z axis drift higher than 6mm upon executing a single system macro. Random data corruption or system interrupt on a single board would surely result in randomly tilting the bed left or right, which I do not observe at all
- on system ②, the 2 independent Z axis motors are controlled by the same 3HC board. "Expectedly" no bed tilt is observed here too. Meaning this issue is probably independent from the board use (i haven't tried to plug both Z motors on the 6HC main board though).
- both systems ① and ② exhibit the issue with RRF 3.5.0rc1, not with 3.5.0b4 or 3.4.xxx
@Diamondback Note that I have no intention on hijacking your thread, I am only providing additional info relevant to your problem which I suspect could help RRF developers to quickly find the origin of the problem and come with a solution.
-
@jp-douarvil-0 I think you should start a new thread and in it post details of the way you are using G92. It is fairly unusual to use G92 during a print.
-
No, i'm not using G92 during my print at all. It's being used for the homing process of the coupler axis once, but that's about it.
