Feature request: Definition of tool head distance for dual extruder support

[stohn]

When using a dual extruder the active tool head / hot end is selected by the "T" gcode (T0, T1, ...).

Since most machines will have multiple tool heads / hot ends arranged next to each other there will be a distance (most likely in X direction) between them.

Here my thoughts:

==> There should be an option in "Configuration.h" to allow the definition of the distance of the tool heads relative to the first (standard) tool head.

==> When the tool head is changed with the "T" gcode the appropriate distance should be selected, the tool head distance should be positioned (so the newly selected tool head is exact at the same position the old tool head was before the "T" gcode) and all new moves should use the new distance settings as offset.

Maik

[bkubicek]

I don't have a dual-head machine. How is this done usually? Is the shift is currently handled by the slicing software?

[stohn]

Currently there is almost no support for multi extruder inside of the slicing software.

ReplicatorG-Dualstrusion-Branch is sending a special GCode in startup code to setup different coordinate systems and whenever a tool head change is done it also changes the coordinate system for this specific toolhead (multiple gcodes sent to change tool head).

Slic3r just sends the tool head change command (T0, T1, ...) and expects everything to work inside of the machine

In my eyes the tool head distance is a configuration to be done in the machine/firmware (All other machine related settings like length of x,y,z length, stepper rates, ... is done there, why not the fixed distance of the tool heads?).
This also would ensure that the same gcode file could be used on different machines with different tool head distances.

I created an experimental patch for this which I'm testing right now:

In "Configuration.h" I added this lines (I used a lot of defines to make the binary not to grow in case the feature is not used):

// Distance(s) between the nozzles to correct them automatically at tool head change
#define E0E1_X_DISTANCE  20.0
#define E0E1_Y_DISTANCE   0.0

//#define E0E2_X_DISTANCE   0.0
//#define E0E2_Y_DISTANCE   0.0

In "Marlin.pde" I added the "add_toolhead" array to the variables section (just like the "add_homeing"):

float add_toolhead[3]={0,0,0}; 

and to the "process_commands()" function the addition of the offset per axis (again like the "add_homeing")

      if(code_seen(axis_codes[X_AXIS])) 
      {
        if(code_value_long() != 0) {
          current_position[X_AXIS]=code_value()+add_homeing[X_AXIS]+add_toolhead[X_AXIS];
        }
      }

      if(code_seen(axis_codes[Y_AXIS])) {
        if(code_value_long() != 0) {
          current_position[Y_AXIS]=code_value()+add_homeing[Y_AXIS]+add_toolhead[Y_AXIS];
        }
      }

      if(code_seen(axis_codes[Z_AXIS])) {
        if(code_value_long() != 0) {
          current_position[Z_AXIS]=code_value()+add_homeing[Z_AXIS]+add_toolhead[Z_AXIS];
        }
      }

then in the gcode parser inside the "T" gcode handler it the corresponding tool head distance is applied to the variable:

  else if(code_seen('T')) 
  {
    tmp_extruder = code_value();
    if(tmp_extruder >= EXTRUDERS) {
      SERIAL_ECHO_START;
      SERIAL_ECHO("T");
      SERIAL_ECHO(tmp_extruder);
      SERIAL_ECHOLN(MSG_INVALID_EXTRUDER);
    }
    else {
      active_extruder = tmp_extruder;

//MULTIPLE TOOLHEAD DISTANCE ADD ON
      st_synchronize();

      //remove old toolhead offset from current position
      current_position[X_AXIS] -= add_toolhead[X_AXIS];
      current_position[Y_AXIS] -= add_toolhead[Y_AXIS];

      //reset current offset
      add_toolhead[X_AXIS] = 0;
      add_toolhead[Y_AXIS] = 0;

      //setup specific toolhead offsets if defined
      if( 1==active_extruder )
      {
        #ifdef E0E1_X_DISTANCE
          add_toolhead[X_AXIS]=E0E1_X_DISTANCE;
        #endif
        #ifdef E0E1_Y_DISTANCE
          add_toolhead[Y_AXIS]=E0E1_Y_DISTANCE;
        #endif
      }
      else
      if( 2==active_extruder )
      {
        #ifdef E0E2_X_DISTANCE
          add_toolhead[X_AXIS]=E0E2_X_DISTANCE;
        #endif
        #ifdef E0E2_Y_DISTANCE
          add_toolhead[Y_AXIS]=E0E2_Y_DISTANCE;
        #endif
      }

      //add new toolhead offset to current position
      current_position[X_AXIS] += add_toolhead[X_AXIS];
      current_position[Y_AXIS] += add_toolhead[Y_AXIS];
      //reset the extruder position
//DO NOT DO THIS!      current_position[E_AXIS] = 0;

      //move to new position...
      plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]);
//MULTIPLE TOOLHEAD DISTANCE ADD ON

      SERIAL_ECHO_START;
      SERIAL_ECHO(MSG_ACTIVE_EXTRUDER);
      SERIAL_PROTOCOLLN((int)active_extruder);
    }
  }

Right now I'm not sure if it's needed to do add the tool head distance inside of G92. I need to verify this.
BTW: There is a bug inside the current Marlin code which is shown below also:

    case 92: // G92
      if(!code_seen(axis_codes[E_AXIS]))
        st_synchronize();
      for(int8_t i=0; i < NUM_AXIS; i++) {
        if(code_seen(axis_codes[i])) { 
//==> BUG, REMOVE THIS LINE <==           current_position[i] = code_value()+add_homeing[i];  
           if(i == E_AXIS) {
             current_position[i] = code_value();  
             plan_set_e_position(current_position[E_AXIS]);
           }
           else {
             current_position[i] = code_value()+add_homeing[i]+add_toolhead[i];  
             plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]);
           }
        }
      }
      break;

I think something like this is an easy and clean solution.

[cgrosbeck]

I agree
The tool (print head) offset should be handled in the firmware!!!!
I am also working on building dual head machine with dedicated support material head.
But let’s say you want four heads.
T0 is white ABS
T1 is support material
T2 is blue ABS
T3 is red ABS
If your part starts with T0 then the off sets can all be based from that. But what if you want to start with T3. Should work right!!!!
So just some food for thought.

[daid]

I have a dual head Ultimaker now. And X/Y offset in firmware would be helpful. But I would much rather like to see a different E value per extruder. right now I need to reset the E value after every tool change, or I need to use relative E values which adds rounding errors. The offset per tool is quite simple to compensate in software.

[ZetaPhoenix]

Just working from CNC machining experience, if you are working with multiple vises you use different work cordnate ofset selection (G54, G55, G56, etc.). In translating this to a 3d printer, I have a couple thoughts:

G53: Machine WCS (Work Coordinate System)
G54: Print bed WCS, defined as an offset from G53 (limit switches)

Each print head has it's own correction offset:

[layer moves]

T0 M6 <- Switch to extruder #1, load offset for T0

[layer moves]

T1 M6 <- Switch to extruder #2, load offset for T1

[layer moves]

This work assuming printing with one extruder at a time. On thing that needs to be decided is when does the physical offset happen? Should the extruder move at the M6 or should the compensation happen during the next move?

[Rencio7]

I've succesfully printed dual extrusion with marlin and netfabb - this has gcode offset though..

I would love to be able to use marlin (dual extrusion) with kisslicer, slic3r etc which has no gcode offset in firmware

Repetier firmware has just implemented dual extruders with offset in firmware etc - will test when I get back on Sunday.

[hurzl]

save head offset via "G10"?
http://reprap.org/wiki/G-code#G10:_Head_Offset

[simonkuehling]

Just wanted to add +1 for firmware-based extruder offset, since this is clearly an internal machine-specific dimension. the slicing software should just manage the toolhead selection without knowledge about their physical offsets.

[boelle]

This one is created about a year ago and there have been a lot of changes, please download the latest copy of marlin and see if the problem is still there. Also you the latest arduino IDE to flash the marlin firmware. If you board files etc only work under old ide upgrade those first so they work under latest IDE.

If you create board files for hardware that are not in the https://github.com/ErikZalm/Marlin/tree/Marlin_v1/ArduinoAddons then please fork marlin and add the files and then create a pull request so that we can get the hardware supported. This will also give an idea what hardware people are using.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.