RRF 3.4 Beta 7 | Tool-Offsets Issue

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.

VoodooBane

@sebkritikel I actually figured it out... lol I was doing a negative value on my T1 z-offset. But I changed, I got rid of the negative sign on the Z offset. it is working now. the layers are going down now.

Only wish I could use a fork of slic3r that allowed you to adjust the z-hop, z-retration, etc in the slicer itself instead of the firmware.