Problems with IDEX printer configuring

Phaedrux

3.2 final is available now. Please update by uploading the zip file to the system tab: https://github.com/Duet3D/RepRapFirmware/releases/download/3.2/Duet2and3Firmware-3.2.zip

Or if using the SBC and unstable branch use the instructions here: https://github.com/Duet3D/RepRapFirmware/releases/tag/3.2

@Visionary said in Problems with IDEX printer configuring:

-When switching heating off/on I get message:
"T-1 Warning: Obsolete use of S parameter on G1 command. Use H parameter instead."

This is because your tool change files are using G1 S moves instead of G1 H.

@Visionary said in Problems with IDEX printer configuring:

G1 S2 X-48 F6000 ; park the X carriage at -37mm

@Visionary said in Problems with IDEX printer configuring:

Error message: "T1" "Error: G0/G1 insufficient axes homed".

This is likely because you have G28 X Y in your tol change files, but your homex and homey likely also have Z movements that occur when the Z axis isn't yet homed?

Post your homing files.

Visionary

@Phaedrux

homeall.g

; Haq xy homing X,U,Y,Z-axes:
G91
G1 H2 Z7 F200 					; raise head 7mm to keep it clear of the bed
G1 H1 X-405 U405 Y-405 F3000 ;S1 ; coarse home X, Y and U
G1 H2 X5 Y5 U-5 F600              ; move 4mm away from the homing switches
G1 H1 X-10 U10 Y-10     ;S1      ; fine home X, Y and U
G1 H1 Z-380 F360                ; move Z down stopping at the endstop
G90

; Uncomment the following lines to lift Z after probing
;G91                    ; relative positioning
;G1 Z5 F100             ; lift Z relative to current position
;G90                    ; absolute positioning

homeu.g

G91 			  ; relative positioning
   
G1 H2 Z5 F2000    ; lift Z relative to current position
G1 H1 U475 F1800 ; move quickly to X axis endstop and stop there (first pass)
G1 U5 F6000       ; go back a few mm
G1 H1 U475 F600  ; move slowly to X axis endstop once more (second pass)
G1 H2 Z-0.5 F6000   ; lower Z again
G90               ; absolute positioning

homex.g

G91 			  ; relative positioning
   
G1 H2 Z5 F2000    ; lift Z relative to current position
G1 H1 X-475 F1800 ; move quickly to X axis endstop and stop there (first pass)
G1 X5 F2000       ; go back a few mm
G1 H1 X-475 F600  ; move slowly to X axis endstop once more (second pass)
G1 H2 Z-5 F6000   ; lower Z again
G90               ; absolute positioning

homey.g

G91

G1 H2 Z5 F6000    ; lift Z relative to current position
G1 H1 Y-405 F1800 ; move quickly to Y axis endstop and stop there (first pass)
G1 Y5 F6000       ; go back a few mm
G1 H1 Y-405 F600  ; move slowly to Y axis endstop once more (second pass)
G1 H2 Z-5 F6000   ; lower Z again
G90               ; absolute positioning

homez.g

G91               ; relative positioning
G1 H2 Z5 F6000    ; lift Z relative to current position
G1 H1 Z-380 F1800 ; move Z down until the endstop is triggered
G92 Z0            ; set Z position to axis minimum (you may want to adjust this)

; Uncomment the following lines to lift Z after probing
;G91              ; relative positioning
;G1 Z5 F100       ; lift Z relative to current position
;G90              ; absolute positioning

The homing files do have z-movement.

Phaedrux

They do, but they correctly use H2 so that's not the source of the errors. So that narrows it down to the G1 S2 commands and probably the G1 Z commands.

Visionary

I got rid of the errors (at least those that are given in normal use), but still got a few problems/unclear things to me:

Paneldue jogging doesn't work the same as DWC jogging: DWC works as intended but paneldue moves sometimes axes back to previous position (home) when trying to jog another axis. When trying to move those axes that went to previous position even by 1mm they move back to position where they were before going back.
When using tool 2 (U-axis extruder) to print DWC shows tool 2 coordinates as X-axis position instead of as U-axis position. Is this how it should work?
Standby temperatures set in Cura are not used during dual material/color printing. Instead standby temperatures are set to printing temperatures for both extruders for entire print job. I got around this by adding extruder start G-codes that set standby temperatures to extruders each time tool is changed. This though mean that standby temperatures are constant and are used with both extruders even when both extruders are not used.

Phaedrux

What paneldue firmware version are you using?

For the cura standby temps, it might make more sense to set the standby temp with G10 and then use your tool change macros instead of relying on cura to set the temps.

Visionary

@Phaedrux
I'm not sure which version paneldue firmware is, but I got it from Reprap configurator 1,5 - 3,5 months ago. Is there way to check it?

Phaedrux

Yes you can check the PanelDue firmware version in the setup page on the PanelDue.

And update it like this
https://duet3d.dozuki.com/Wiki/PanelDue_Firmware_update

Visionary

I got the printer working otherwise but:

X-axis positions relation between extruders seems to change randomly. This is seen as offset on dual color/material prints. Something seems to affect homing accuracy.
Something caused offset on print bottom infill in relation to walls of the print. The other side of the print has more outer walls than the other even though they slicer shows the same amount of lines.
I need stealthchop tune move macro

Phaedrux

Is the Z axis intentionally compressed for shorter prints?

Maybe try some IDEX calibration prints to get it tuned in?

There are many variations. Here is one.
https://www.thingiverse.com/thing:4565745

Visionary

The print objects are compressed on purpose to shorten print time and minimize print material usage. I've tried printing "proper" dual calibration models but those are hard to check for alignment because the tips of the spikes are often quite nonuniform (especially when prints don't seem to stick well to my print bed that is made of glass). Printing two cubes with the other on top the other allows feeling the edges of the cubes on each side. It should be accurate.

I just found a post that explains possible causes of inaccurate homing:

@dc42 said in Z homing fails often after update from 3.1.1 to 3.2:

It's as I expected. If two endstops are triggered with a delay of about 2.2ms between them, only the first one is registered until another input changes. When the delay is shortened to 1ms or lengthened to 5ms, the problem does not occur.

Now I can test fixes.

So I changed homingall.g move distances so that each axis is home slightly different time than the others. I'm still testing if this is the case.

Visionary

Repeating same print job without changing offsets in config or changing any slicer settings resulted with two prints that had different offsets on X/U-axis. The difference was 0,5 mm.

I also tested repeatability of X- and U-axis endstops by homing them and moving back 10 to 100mm and homing again and repeating. They seemed to be fine as difference for each measurement was within 0,05 mm.

I'm not sure what causes this. Position of Y-axis doesn't matter and Z-axis moves very slowly and it too has variance with position, but that is most likely just because heat expansion.

Visionary

I solved the issue with first layers (brim) not aligning with body of the part. It was caused by lost steps when tools are switched and the other extruder went to its minimum axis location and hit the other extruder slightly. This only happens with first layer and not with higher layers.

I still have problems with setting offsets. If I calibrate the extruders with any calibration object to correct offsets, offsets on prints will eventually change to something else and a new calibrations is required. This happens relatively randomly and I got about 10 print jobs done with one calibration and after that even the calibration was hard as correcting the values did not give the results it should have.

Visionary

I think found the issue: printed parts (ABS) on X- and U-gantries were attached by M3 bolts were loose. The printed part had given in slightly. Weird thing is that it didn't seem to affect one extruder printing (no shifted layers during printing).

Small frog dual color.png

dc42

I'm glad you solved it. Nice frog print!

Visionary

@dc42

Thanks. I still need to do some tuning, but I think I'm getting close. It is possible to see some inconsistencies in black parts of the frog (green glitter hides those inconsistencies). I had line width set
to low (0,38) on the frog, which probably causes the issue along with not quite right extrusion multipliers.

I'll probably post more detailed description on my machine on "my Duet controlled machine" -section when I got the time.

dc42

FWIW I printed the same frog some time ago.

alt text

Visionary

@dc42

Nice!

In your print layers are consistent so lines don't bulge randomly as in mine.