Dumbfounded ! Firmware bug in 3.4 beta 6?

GeneRisi

@dc42 OK, I will now

; tpost0.g
; called after tool 0 has been selected

;heatup
M116 P0

;prime nozzle
;M98 Pprime.g

;mesh levelling on
G29 Q1

;PCF fan on
;M106 P2 S255

G1 R2 X0 Y0 Z2
G1 R2 Z0 F360

; tpost1.g
; called after tool 1 has been selected

;heatup
M116 P1

;prime nozzle
;M98 Pprime.g

;mesh levelling on
G29 Q1

;PCF fan on
;M106 P4 S255
G1 R2 X0 Y0 Z2
G1 R2 Z0 F360

The Free and pre files have not changed.

T3P3Tony

@generisi with the image with the two cross prints you showed. Do you mean that T0 and T1 printed one of the crosses perfectly aligned and then the next time T1 was used it printed the miss aligned cross?

GeneRisi

@t3p3tony Hi Tony, T1 printed the cross in one location and T0 printed the cross in the other location. Even when repeating the sequence a second time, T1 prints in one location and T0 in the other location.

If the order is switched, so that T0 is used first, then T1, the crosses align as expected. This is also true if the sequence is T0, T1, T0, T1.

FWIW, many years ago, I used to be a programmer and when I think about this, uninitialized values that are referenced comes to mind... FWIW

@dc42 , is there some level of debugging I can turn on that might provide you some helpful information?

dc42

@generisi I have a theory about what us happening. Tool offsets are usually ignored in system macro files. So I think the G1 R2 X0 Y0 Z0 command at the end of config.g is ignoring the tool offsets. This obviously isn't wanted in this case.

I will do some tests to confirm or refute this theory.

GeneRisi

@dc42 I only added this line after the exchange with @T3P3Tony above; I did, however, use G1 R2 Z0 before communicating with Tony. As an alternative, I can remove the G1 R2 command and use Simplify3d's internal state variables to restore the X, Y and Z locations. Let me know whether this would be a helpful test.
Gene

I removed the G1 R2 commands from the tpostx macros. It didn't change the outcome.
Gene

Why would the tool offsets matter for a move that simply gets the new tool head near the area where it will be used? The printing doesn't occur until a few gcode commands after this move. Aren't the tool offsets applied to every gcode move command?
Gene

GeneRisi

@dc42 Is there something I can do t help debugging this?

GeneRisi

@dc42 I found the problem.

When tool T1 was being returned, the Y "parking" coordinate was off by 1 mm. The tool parking location didn't budge but the firmware thought that the tool location was 1mm beyond where it actually was. The machine is a corexy (E3D), so even though only the Y coordinate was off, I suspect it affected both the x and y location from the the firmware's perspective.