Duet toolchange post behavior

kazolar

I noticed toolchange behavior changed at some point, and am not sure why. Now after postX.g runs z is restored automatically. I don't want it to do that, it doesn't make sense for an IDEX (or more -- I have 4 independent tools) to do that. I lower the bed 0.6mm when I park a tool, and I want it to stay lowered when the new tool comes back to xy position, I have my slicer set to move xy to correct position then adjust z, so I don't want duet to restore Z -- I see this code -- my only option is to comment it out.

		// Restore the original Z axis user position, so that different tool Z offsets work even if the first move after the tool change doesn't have a Z coordinate
		// Only do this if we are running as an FDM printer, because it's not appropriate for CNC machines.
		if (machineType == MachineType::fff)
		{
			currentUserPosition[Z_AXIS] = toolChangeRestorePoint.moveCoords[Z_AXIS];
		}

T3P3Tony

@kazolar i will move this to feature requests as this auto restore behaviour should be an option. Its certainly used by the e3d tool changer.

Have to see what @dc42 thinks about how to setup the restore/not restore option as having it as a switch on the Tn command would be a pain as most slic3rs would need tweaking to output anything other than Tn

As a work around can you not have the tool change macros do anything in Z? As you are using your slicer to restore the Z height, can you no use it to put the initial Z0.6 ove in before the tool change as well?

kazolar

There is nothing I can do in the macros, as based on the code the z position is stored before the macro is executed and z is restored after the other macro is executed...since I have my other tweaks to the firmware that I make to ad additional steppers, I build my own firmware, so I commented this code out. E3d tool changer is not the only multi tool configuration, but even that, s3d issues a specific instruction after the too change to set z, nothing tricky about that, only tricky part is to move it to target XY prior to moving it to z, the key in tool change operations is to restore z AFTER xy is moved to where the next printing operation will happen. I am not sure how firmware can handle it, but my idea was to have gcode which saves z and gcode which restores it, so it can be added in the slicer or macros.

T3P3Tony

@kazolar I meant if you are using s3d to carry out other functions why not have it add the 0.6 and remove it from the tool change macro.

kazolar

@T3P3Tony s3d only allows me to add the tool change operation which executes post tool selection, not pre

NitroFreak

For my lifting hotend i tell the printer to raise the Z by a relative amount (G92 G1 Z5 ) before the toolchange. I do not lower it afterwards, when the print resumes it automatically lowers it again while travelling to the XY place.
I dont know if that is what you want to do?

kazolar

@NitroFreak I have a relative lift of 0.6mm in the freeX.g command, then then park the old tool to it's appropriate corner, then in the postX.g script the selected tool is wiped and then slicer gcode moves it to the appropriate xy location, then to its appropriate z position, this allows the tool travels to occur without colliding with the print and without contamination. At some point the firmware was changed to restore the z position prematurely. Which I don't want to do...hence I commented it out in the source code and built a new binary, I did a few calibration tests and it works much better, no nasty contamination stringing.