Toolchanger Setup Continue...

Chriss

@droftarts Thanks for grounding me again. I may have misunderstood the docu of G10.

I may have overlooked that:

In your G10 tool offset setting commands (these G10 commands have axis letter parameters and a P parameter but no L parameter), specify the offsets of the nozzle or cutting head relative to the HRP.

I will drop the L parameter than and see how it behaves than.

Cheers, Chreers

Chriss

@droftarts I'm a bit confused about the concept behind that offset to be honest. My tools get picked up and dropped off correctly as long as I have no offset configured.
It turns into a nightmare if I have offsets configured for obvious reasons.
So I tend to change the offset now in the tpost file and turn it back to X0 Y0 in the tfree file but that seams to me like a ugly hack. It would be far more convenient if the offset would be removed automatically removed when the tfree gets executed.

Cheers, Chriss

engikeneer

@Chriss what you want is to use G53 in front of yiur G1 commands in your toolchange files. That means it considers the G1 command to be in machine coordinates, not tool coordinates, so doesnt apply the offsets.

More generally have you read up on the E3D toolchanger and motion system? You could probably get 90% of the eay there with your comissioning by just cribbing their config files and setup guides. No point reinventing the wheel! There are probably similar materials also available for the Jubilee and other toolchanger printers if you look too.

https://github.com/e3donline/RepRapFirmware-SD

https://e3d-online.zendesk.com/hc/en-us/sections/6186313376413-ToolChanger-Motion-System

Chriss

@engikeneer Thanks for the tip with G53, that is indeed what I was looking for. I id implemented "my way" in the meantime which simply sets the offset to x0y0 in the tool files. But that is a ugly hack indeed.
I had a look at the e3d's git repo to get some ideas how they did it. And they do not use they do not use the G53 there, which is a bit surprising. The command may be to new for their retired product.

Anyway, I will work on the calibration for now and will play with the G53 later.

gloomyandy

@Chriss Have you seen the e3d toolchanger configuration files created by dc42? They may be of interest:
https://github.com/Duet3D/RRF-machine-config-files/tree/master/E3D_Tool_Changer

The associated blog posts might also be worth reading:
https://miscsolutions.wordpress.com/2020/03/02/converting-the-e3d-tool-changer-to-duet-3-with-hemera-tools-part-1/

Chriss

@gloomyandy Yes, I saw Davids configs indeed. I use many of his plastic parts for my Hemeras and did some modding on them. But thanks for bring them back up.

I always struggle a bit with using other peoples configs to be honest. I like to understand how things work in detail. And this printer is not a new build, I convert a RR VCore into a toolchanger, so I have a working config and need to add the toolchanging "only". Anyway, I used Davids settings for the coupler and some more ideas. But you are right, I have overlooked the G53 in his tools related files.

Cheers, Chriss

dc42

@Chriss for clarification, the HRP of an E3D toolchanger is normally taken to be the position of the Z probe switch on the tool pickup.

I use G53 in the tfree and tpost files because I prefer to use machine coordinates in those files, not nozzle coordinates. That means I can adjust the nozzle offsets for each tool to get perfect registration between all the nozzles, without having to update the tool change files every time I adjust them.

G53 is not needed in the tpre files because there is no tool loaded at that point, so no tool head (i.e. nozzle) offsets to apply.

HTH David

droftarts

@Chriss For an explanation of 'HRP' (Head Reference Point) see https://docs.duet3d.com/en/User_manual/Tuning/Defining_tool_and_Z_probe_offsets

Ian

Chriss

@droftarts Thanks... That helped indeed a lot to get a better/full understanding about the concept.

@dc42 Thanks for the further explanation David! I understand it now and I switched over to the G53 concept in the meantime. Going "my way" was not very successful.

I have a other questions about the tool change itself. The Prusa slicer, which I use here, acts a bit stupid in my understanding, It sets the tool with G10 to the standby filament temp instead using M568 and the R option. I do that manually via the start code now, like this:

M568 P0 R{global.tool0_standby}
M568 P1 R{global.tool1_standby}
M568 P2 R{global.tool2_standby}
M568 P3 R{global.tool3_standby}

That works so far and I'm happy. But now comes Prusa into the game. The slicer change the temperate of the tool to standby temp now. That should not be a problem because I changed the standby in the start code. You see the "T1" than which does the tool change drill. Next is a G10 with P1 which is OKish. And the next M116 is my problem.

[...]
G1 E-1 F7200
; Filament-specific end gcode
G10 S100 P0 ; set temperature ;cooldown
T1
; Filament gcode
G10 S215 P1 ; set temperature
M116 ; wait for temperature to be reached
[...]

The M116 makes the printer to wait till the previous tool has reached its designated temperature which is the standby temp than (100°C in this case). That confuses me a bit. I understood M116 that it does not wait for "parked" tools since 3.5 anymore:

Note that in v3.5, the scope of tool heaters to wait for is limited to the heaters of the currently selected tool of the selected motion system.

I'm not sure how to overcome that to be honest. The only thing I can think of is to change the main temperature back to the printing temp via the tfree script. But not sure to what will lead me that.

Any ideas?

Cheers, Chriss

mikeabuilder

@Chriss - I'm also one of those people that wants to know how things work in detail and ended up writing my own macros for tool changing on the printer we are building at our maker space. Our tool changer is a modification of the Jubilee tool changer, which was a modification of the ESD tool changer. Here are some concepts we learned along the way - meaning things I got wrong at least once before getting it right.

X and Y Tool offsets

We designated tool0 to have X and Y offsets of 0. Why not? it makes stuff easier when setting up the other tools.
We designed a two-color part that we print to help us dial in the offsets. Its two concentric square, like two square donuts nested together. Here are the stl files. XY_nozzle alignment inner ring.stl XY_nozzle alignment outer ring.stl If the X offsets are perfect, the total with of the right and left sides of the "donut" should be equal if they aren't equal, the different is twice the amount the offset needs to be changed. Same with the Y direction. We eyeball the alignment the first time, then use calipers to get the final adjustment.

Z offsets

Each tool needs to have it's Zoffset set independently. We didn't designate roo0 to be the origin because we make Z offset changes often.
We use baby steps to make final adjustments to the Z offset and we wrote a macro that will read the current baby steps and z-offset form the object model, and change the z-offset to "roll in" the baby steps if baby steps have been set. We run this macro whenever we park a tool (ie run tfreeN.g).

Moving outside soft limits

We set the X and Y soft limits of the machine so that prints can't drive the printhead into the tool docking area. This menas that when we dock or undock a tool, we need to allow moves outside the limits (M564 S0). When we move back inside the limits after we pick up a new tool, we need to disallow moves outside the limits (M564 S1). Be sure to put and M400 (wait for moves to finish) before the M564 S1 or RRF may discover you are outside limits. We crashed the tool several times while learning this one.

tpre vs tpost

This one confused us for a while until we understood that the "event" that the "pre" and "post" refer to is the changin of the tool number in RRF. This means that during a tool change RRF has no "awareness" the tool offsets, extruder settings, etc while it is running tpreN.g. If you have any gcode command in tpreN that has a parameter for "current tool", "current heater", "current extruder", "current filament", etc, they probably should be in the tpostN.g file.

simplifying the macros

All three of our tools have the same docking procedure, with only the X location of the dock different. We ended up writing a single macro for each of tfree, tpre and tpost, using an input parameter for the X location of the dock. We called these macros tfree_all.g, tpre_all.g, and tpost_all.g. In the actual tpostN.g file, we just use an M98 to call our macro. With this setup, we can tweak the parking macros in one place.

The slicer

We normally use PrusaSlicer and have one line of custom gcode for each tool. This line sets the standby temperature for the tool, based on the nozzle temperature set in the slicer. We did this to try to minimize the time a tool takes to re-heat after it's been picked up. We started with 25*C below active temperature, but this was giving us about 30sec of wait time per tool change and it felt like forever. When we kept the nozzle temperature at the active temperature we had some problems with the plastic melting beyond the cold-break when the tool was docked for a long time.

PanelDue

In PrusaSlicer, the extruder numbering is "1-based" - and RRF it's "0-based". this leads to confusion for users when they are using the slicer. We can change the labeling for the tools in DWC to align with the Slicer numbering. Our main user interface is the PanelDue and we have not found a way to change the tool numbering on it.