First move speed wrong after tool change

[Alex9779]

I started my first dual print with the RCBugFix of two days ago. I realized that the second extruder had problems when doing a tool change. I have a tool change script which purges the previous and primes the new extruder. I was able to reproduce without printing.

I used two scripts to purge the extruders:

G90
T0
G1 X100 Y200 F3000
G1 X100 Y235 F3000
M83
T0
G1 E25 F400
G1 E-14 F4000
T0

and

G90
T0
G1 X100 Y200 F3000
G1 X100 Y235 F3000
M83
T1
G1 E25 F400
G1 E-14 F4000
T0

The issue is that when I run the second script it is ignoring the speed setting after the T1 command. I have F400 in there but the speed used is much higher... If I run the following script the speed is ok:

G90
T0
G1 X100 Y200 F3000
G1 X100 Y235 F3000
M83
T1
G1 F400
G1 E25 F400
G1 E-14 F4000
T0

[Blue-Marlin]

From the RepRap wiki (http://reprap.org/wiki/G-code#G0_.26_G1:_Move):

1. G1 F1500
2. G1 X50 Y25.3 E22.4
In the above example, we set the feedrate to 1500mm/minute on line 1, then move to 50mm on the X axis and 25.3mm on the Y axis while extruding 22.4mm of filament between the two points.

1. G1 F1500
2. G1 X50 Y25.3 E22.4 F3000
However, in the above example, we set a feedrate of 1500 mm/minute on line 1, then do the move described above accelerating to a feedrate of 3000 mm/minute as it does so. The extrusion will accelerate along with the X and Y movement, so everything stays synchronized.

The RepRap spec treats the feedrate as simply another variable (like X, Y, Z, and E) to be linearly interpolated. This gives complete control over the acceleration and deceleration of the printer head in such a way that ensures that everything moves smoothly together, and the right volume of material is extruded at all points.3

Looking at that, your second version seems to express better what, i suppose, you want to have. In the first version G1 E25 F400 de-accelerates from F3000 (in worst case random) to F400. In the second it has a constant speed of F400. (Obviously with ramps up and down, according the surrounding moves.)

For the next line G1 E-14 F4000 this is not that obvious. Because of the changed direction the move starts always with 0 speed. Start the move with F400, end the move with F4000 and respect the acceleration ramps.

Sorry, did not check if this indeed applies to Marlin.

[Alex9779]

Ok so you try to tell me this is intended behaviour I am seeing? So why is the result I get different if I switch from T0 to T1 instead of being the same if I stay on T0?

[Blue-Marlin]

No. All i wanted to explain is, that the different scripts can explain the different behaviour you told us about. Setting the feedrate explicitly to a value you want can't be an error. While trusting in a obscure (maybe random?) value an automatism gives you, can be problematic.

With other words: Tell the machine what you want it to do - don't be surprised, if it does not do what you want, if you give incomplete orders.

If or where there is an inconsistency in Marlins behaviour still has to be investigated.

[Alex9779]

Ah ok got it :). Thanks for clarifying... Thought you meant that acceleration could be the cause or some interpolation between what was before and then my extrusion command follows.

I got a temp workaround but still I think both scripts (the first with no tool switch and the second with switch to T1) have to behave the same way, what they don't do...

[Blue-Marlin]

Do they behave the same when you add G1 F400 to the first and the second script? What happens if you swap the order of M83 and T? ? Is it only the first time you swap extruders or always?

[Alex9779]

They behave the same when I add the G1 F400 only to the second script. I tried with the first one too but it has no effect, the first does what it does with or without G1 F400. I was thinking about the M83. Can't test at the moment a print is running. But actually M83 is set at the very start of the print and then never again in the whole print. And I saw the issue when printing on each tool change. The scripts above are just adapted positions of the script I do each tool change, on a tool change the script is the same except the M83, that is missing... And during the print T0 got purged as I wanted it to and T1 not.

[Blue-Marlin]

Do you have a 'normal' dual extruder setup, or a DUAL_X_CARRIAGE setup.

[Alex9779]

"Normal", both hotends on one head...

[Blue-Marlin]

Analysing gcode_T (Marlin_main.cpp L6296++) i'd say the resulting feedrate after that is not really random but due to the lots of cases somewhat unpredictable. Letting the cases for DUAL_X_CARRIAGE aside:

• If there is only one extruder nothing interesting happens. The feedrate is like before
• If the current extruder is not changed and no F-parameter is given (from 0 to 0 or from 1 to 1), no move in xy-direction (extruder_offset) is required. The feedrate is unchanged.
• If the current extruder is not changed and a F-parameter is given. No move is required, but the feedrate for the next move is that given.
• If the current extruder is changed and no F-parameter is given, the internal positions are corrected, but no move is executed. The feedrate is the same as before. In your case the correction of the xy-position is done together with your next e-move. That may affect the speed of the e-move because xy is also moving. If the next command is not the e-move but the explicit G1 F400 the pending xy-move is done here and the following e-move is done alone.
• If the current extruder is changed and a F-parameter is given, the internal positions are corrected, the move is performed at the given speed. Thereafter the feedrate is the given speed.

What to do?

• The previous feedrate should be stored.
• If no F-prameter is given, a needed xy-move should be done at max_feedrate and than the stored feedrate should be applied again.
• A needed move should always be done and never left be pending.
  1. If a F-parameter is given, that feedrate should be applied to the xy-move and thereafter?
  2. If a F-parameter is given, that feedrate should be applied to the xy-move and thereafter the stored feedrate should be applied again?.

[thinkyhead]

Thanks for the very helpful analysis of gcode_T. I figured it was something like that. Remember too that G1 commands are queued, while the command following a G1 may be executed immediately. I believe gcode_T calls st_synchronize but I will doublecheck shortly. This should be "relatively easy" to patch up, but I might still take the time to flowchart all the mods to feedrate to make sure nothing else steps on it.

[thinkyhead]

The GCODE specification (I believe) states that the F parameter applies to the move in which it is given, and then all following moves. At least, that seems to be the "going assumption" in the code. I don't think it would be correct to save the last feedrate that was set and then re-apply it after a move that contains F. The F parameter in GCODE is (again, as I understand it) meant to be a single global value. (This doesn't preclude having special feed rates for things like homing and manual moves. It only means that when a G1 command contains F it really should apply globally to both the current and the next consecutive moves lacking F.)

So... When a G1 contains F, I think it is meant to set a global right away (target feedrate for following moves) before it queues the move in the planner.

Just need to make sure that only G1 commands ever alter that feedrate — ensure other immediate commands can't set it.

[Blue-Marlin]

@Alex9779 Please test #3620 .

[github-actions[bot]]

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.