RRF 3.4 Beta 7 | Tool-Offsets Issue

CR3D

Dear Community,

i have big issues with my IDEX system and Tool Offsets. I hope I can convey it clearly and understandably:

Tested with RRF 3.4 Beta 7 and RRF 3.4 RC1

I want to print this calibration print:

The G10 P1 in the config-override.g says following:

The process should be following for a layer height of 0.2mm:

Z = 0.20mm
First T0 prints the skirt and the first green layer -> Toolchange -> then T1 prints the first layer of white square
Then Layer Change
T1 prints the second layer of the white square -> Toolchange -> then T0 prints the green layer
Then Layer Change
T0 prints the second layer of the white square -> Toolchange -> then T0 prints the green layer

What really happens:

Start T0 with Z=0.2mm everything is fine....

Toolchange T1 -> Z-Axis moves to Z=-0.03mm (Tool-Offset of Tool 1)

Second Layer + Tool 1 active -> Z-Axis moves to 0.40mm??? Why!?

Toolchange to Tool 0

Second Layer + Tool 0 -> Z-Axis moves to Z=0.72mm -> loose Layer

Picture of the loose layer with Z=0.72mm

Next Layer -> Layer 3 -> Z-Axis moves to Z=0.60mm!?? -> squeezed Layer

Picture of the squeezed layer with Z=0.6mm (lower layer height then layer two with 0.72mm)

Then Toolchange to Tool 1 -> Layer 3 -> Z-Axis moves to Z=0.41mm (that is 0.01mm more then T1 in Layer 2!

Layerchange to Layer 4 (Tool 1 still active) -> Z-Axis moves to 0.80mm!

Toolchange to Tool 0 -> Z-Axis moves to Z=1.11mm (that is 0.41mm more than in layer 3

Toolchange to Tool 1 -> Z-Axis moves to Z=0.79mm (-0.01mm over Layer 3)

Toolchange to Tool 0 -> Z-Axis moves to 1.51mm (that ist 0.4mm more than in layer 4)

and so on and so on...

Here a picture of the layers...

M122

=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.0rc1 (2022-02-09 10:26:56) running on Duet WiFi 1.02 or later + DueX5v0.11
Board ID: 0JD0M-9P6M2-NWNS0-7J9D0-3S46R-KV2VM
Used output buffers: 3 of 24 (16 max)
=== RTOS ===
Static ram: 23852
Dynamic ram: 76352 of which 0 recycled
Never used RAM 8204, free system stack 102 words
Tasks: NETWORK(ready,13.0%,236) HEAT(notifyWait,0.1%,331) Move(notifyWait,1.9%,283) DUEX(notifyWait,0.0%,24) MAIN(running,85.0%,442) IDLE(ready,0.1%,30), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:26:16 ago, cause: software
Last software reset at 2022-02-12 10:49, reason: User, GCodes spinning, available RAM 8736, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Step timer max interval 0
MCU temperature: min 33.3, current 35.9, max 36.6
Supply voltage: min 23.1, current 23.7, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/144/144, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: pos 12892, standstill, SG min 0
Driver 1: pos 9593, standstill, SG min 0
Driver 2: pos 10705, standstill, SG min 0
Driver 3: pos 28880, standstill, SG min 0
Driver 4: pos 0, ok, SG min 0
Driver 5: pos 0, standstill, SG min 0
Driver 6: pos 0, standstill, SG min 0
Driver 7: pos 0, standstill, SG min n/a
Driver 8: pos 0, standstill, SG min n/a
Driver 9: pos 0, standstill, SG min n/a
Driver 10: pos 0
Driver 11: pos 0
Date/time: 2022-02-13 21:49:27
Cache data hit count 4294967295
Slowest loop: 14.28ms; 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 4.2ms, write time 2.8ms, max retries 0
=== Move ===
DMs created 83, segments created 34, maxWait 163850ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 7803, completed 7802, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state 3
=== AuxDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 2 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by USB
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) 1
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
=== DueX ===
Read count 1, 0.04 reads/min
=== Network ===
Slowest loop: 27.70ms; 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.26
WiFi MAC address f4:cf:a2:68:45:20
WiFi Vcc 3.50, reset reason Power up
WiFi flash size 2097152, free heap 26648
WiFi IP address 192.168.188.67
WiFi signal strength -74dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

@dc42 please check this... We have to finish this machine in these days ... Thank you in advance

@PCR i think this also can be one problem why our Tool Offset macro does not work well...

Regards Christian

oliof

for a full picture please let us know:

full config.g
full config-override.g
your tpre#.g files
any tool change macros by your slicer
whether you use mesh bed compensation on this test print.
possibly the sample gcode file you're using

CR3D

@dc42

Unfortunately, the issue has not yet been resolved with 3.4 (stable).

Up to version 3.4 beta 4 everything worked.
I noticed the error for the first time in beta 6 and now again with 3.4.

We made a video to show it again.

After downgrading from 3.4 to 3.4 beta 4 everything worked as expected.

There must be a bug in one of the versions!

Video:

https://we.tl/t-9OXBVcGegW

dc42

@cr3d did you read this item from the RRF 3.4 upgrade notes:

After changing tool, RRF no longer moves the new tool head to the coordinates at which the old tool head was at when the Tn command was actioned. In most situations this should not matter, because GCode generators usually generate commands to move to the correct XYZ position after generating a Tn command. Usually, they restore XY before Z. However, Cura does it the other way round, which risks dragging the tool head across the print. Therefore when using Cura, or in any other situations in which you want to restore the old behaviour, we suggest you add command G1 R2 X0 Y0 Z2 Fxxx followed by G1 R2 Z0 Fxxx to the end of your tpost#.g files, if you don't already use those or similar commands.

CR3D

@dc42 ok thank you!

I overread this section... in this printer series we tested it today there wasn´t this section in the tpost.g

if that was the solution, i take everything back and claim the opposite!

Thank you for your prompt reply

Regards Christian

sonderzug

@cr3d
Hi Christian,

one thing that came to my mind, which you might want to check - are you using firmware retraction and different z-hop heights in M207? This seems to be a problem with my setup (E3D Toolchanger), especially when trying to use G10/G11 as a retract/unretract move at tool change.
I have to say though that my machine is still running at an older 2.x version of RRF, so I'm not sure what might have changed, especially in regards to the behaviour of RRF 3.4 and onwards like David posted before.

best, Niklas

CR3D

@dc42 said in RRF 3.4 Beta 7 | Tool-Offsets Issue:

@cr3d did you read this item from the RRF 3.4 upgrade notes:

After changing tool, RRF no longer moves the new tool head to the coordinates at which the old tool head was at when the Tn command was actioned. In most situations this should not matter, because GCode generators usually generate commands to move to the correct XYZ position after generating a Tn command. Usually, they restore XY before Z. However, Cura does it the other way round, which risks dragging the tool head across the print. Therefore when using Cura, or in any other situations in which you want to restore the old behaviour, we suggest you add command G1 R2 X0 Y0 Z2 Fxxx followed by G1 R2 Z0 Fxxx to the end of your tpost#.g files, if you don't already use those or similar commands.

Sorry @dc42 DC42 that I still have to take up the topic, but what you claim here is simply not the case! The whole topic always worked without any problems before the update and since the update the new tool has moved exactly to the old position! This leads to many collisions and should be restored to the way it was before as soon as possible.

The required command is in tpost.g.

;wait for tool 1 heaters to reach operating temperature
M116 P1 S5

;go to
G1 X328 Y65 F50000 

;unretract
G11

;clean
M98 P"clean1.g"

;PCF fan on
M106 R2

G1 R2 X0 Y0 Z2    ; restore position 2mm above
G1 R2 X0 Y0 Z0    ; restore position

In the pictures you can see the left tool in front of the tool change to X=0mm and the right one in park position.

After the tool change, T1 (because it moves to the old position of T0) crashes into T0.

He also makes unnecessary movements during the print. The principle may work for tool changers, but not for IDEX printers.

It works so far, even if the print head is always somehow in the middle of the print bed before the tool change. But it often happens that this is also in the extreme positions and then there is a crash.

Please help or a solution.

As I said before all the changes, everything was perfect and it worked.

CR3D

@dc42 any idea or better a solution for this?

T3P3Tony

@cr3d said in RRF 3.4 Beta 7 | Tool-Offsets Issue:

G1 R2 X0 Y0 Z2 ; restore position 2mm above

By having this command you are moving the T1 to the position of T0 before the tool change was commanded. I think that's not what you want to do if you are first parking T0 using some gcode in the print file, and then commanding the tool change.

is that what is happening? It would be good to share part of a gcode file you are printing along with all the tool change macros so we can understand what behaviour is happening in more detail.

CR3D

@t3p3tony Thank you for your Answer!

The command was just integrated because it was prescribed in the change log that it should now be used like this.

Basically, we've used it before because it's good to move over the component first and then lower Z when changing tools.

As I said, it just doesn't work anymore since the update!

No Gcode is necessary at all, this also happens if you last had the tool far outside and after the tool change the print head wants to go back to the old position and then crashes.

T3P3Tony

@cr3d said in RRF 3.4 Beta 7 | Tool-Offsets Issue:

after the tool change the print head wants to go back to the old position

yes, this is the purpose of the G1 R2 command so in that sense its working as intended - returning the tool head to the position of the previous tool. If you remove the G1 R2 commands from the ~~print~~ Tool change file, what happens?

dc42

@cr3d I am reviewing your thread. You have reported two different issues:

The tool not being at the correct height after a tool change, when the tools have different Z offsets; and later:
Tools crashing into each other during a tool change.

In order that I can make progress, please provide:

Your complete config,g file
Your complete tool change files, and any macro files that they invoke;
The GCode file you are trying to print (at least up to and including the first few tool changes);
A description of what the issue(s) that you have at present, using firmware 3.4.2rc3.

CR3D

@dc42

I will make a new documaetation with the newest Firmware tomorrow.

The issue with the incorrect height after the tool change was fixed from you!

The only problem is the handling of the tool position (old position of the previous tool) after the toolchange... this is not working.

dc42

@cr3d if it's just the height that needs to be corrected after a tool change to allow for the new tool Z offset, then you could use just G1 R2 Z0 at the end of the tpost file so that X and Y are not moved. This should be sufficient if the slicer always generates a travel move after the T command and before the first extruding move.

T3P3Tony

@cr3d does the slicer always generate a travel move to the new tool start position after the tool change command? If so then please see if DC42s solution works.

VoodooBane

So I am having this issue of the u-axis not having the same Z-height on the X axis .. this is assumed by the T1(the second extruder) not laying down a layer...

My bed is pretty darn flat. I have both of my Z-axis rods independent and I have them auto tram...

I figured out that for Slic3r (any kind of Slic3r fork) with RepRap firmware the retractions, Z-lift values, and speeds NEED to be in the setup in RRF firmware, and all of the settings need to be disabled in Slic3r. I do not know how I found this out.

Source: https://blog.prusa3d.com/slic3r-and-marlin-configuration-for-reprap-firmware-retraction-2_3686/

I am running a V-cast 1.5 please see the link: https://myhub.autodesk360.com/ue2a0f85b/g/shares/SH35dfcQT936092f0e43f11e68d181475a37
The only difference to that model is that I am running a different extruder and hot-end.

Can anyone help me with this problem and find a solution? It seems no one has found a fix or what they did to fix it.

All my .config files are attached; please tell me if you see something wrong.

bed.g
config.g
homeall.g
homeu.g
homex.g
homey.g
homez.g

VoodooBane

Also here are my tool files;

tfree0.g
tfree1.g
tpost0.g
tpost1.g
tpre0.g
tpre1.g

jay_s_uk

@VoodooBane you're best off starting a new thread rather than hijacking someone elses

VoodooBane

@jay_s_uk Ah yes will do. My mistake. Did mean to hijack anything..lol I will start a new thread. Sorry about that.

sebkritikel

@VoodooBane said in RRF 3.4 Beta 7 | Tool-Offsets Issue:

@jay_s_uk Ah yes will do. My mistake. Did mean to hijack anything..lol I will start a new thread. Sorry about that.

If you get a chance to make a new thread, please upload a sample gcode file. I haven't been able to reproduce the issues described by @CR3D on my IDEX machine.