Tool Change Command works differently from 1.0 Dev in 04/2017

Doug40

I have a Y-Block Switching extruder that I have been using without a problem since April 2017. I should add that I've been using it because I had a lot of help from Repetier with the Select/Deselect commands in the firmware. When a Tool Change (T) command is executed, the Select/Deselect commands in the firmware retract the filament from the current stepper and advance the filament in the other stepper so its filament is in the melt zone. Also, it raises and lowers the Z axis slightly to prevent melting the current job while the filament is being changed. When completed, it continues executing G-code.

I used the config.h file from the 4-17 FW to generate V 1.0.1 FW. I also made a few small changes, like re-enabling the SD card, adding baby-stepping and a few other small parameter changes, unrelated to the Select/Deselect strings.

Now, when I execute a T command, the filaments move as expected, but when the extruder begins executing, the hotend is slightly below the surface of the part. In the case where a small feature is being added (like a few letters of text), the extruder will carve into the surface, with the first layer, and eventually finish up with something that appears fairly decent. In the old FW, the print continued where it should have. one layer above the previously printed layer.

The patches I make to the G-code are the same for either FW. I have switched back and forth to verify it is not related to something I am doing (as far as I can tell). At the layer I want to change tools, I comment out the G10 and G11 commands so no firmware retraction will take place and add a T command after the extruder to move to the next layer. In the Dev 1.0 FW, it has worked flawlessly for months, and even today when I reload the FW. I only use T commands to change filaments as certain layers; I have never tried using a true 2 color model with this extruder. I tried to attach a config.h file, but I don't think it worked.

Repetier

I think only the select/deselect commands are necessary to anaylse the problem.
Only reason for different Z that should exists is if z offset of both extruders differs. You should test that in eeprom settings. Apart from this the switch script does not change z, but what it does is switch between the offsets so your z moves might interfere here with the offset adjustment moves.

So another test would be to not move extruder z while switching and see if then z stays constant.

Doug40

I compared the config.h file from both sets of FW using the COMPARE plugin to Notepad++. The 2017 Dev and current FW are different, but there is only one difference that I wonder about, unless there are a lot of new parameters added to EEPROM. The current FW has a line to "raise Z on tool change" (which is set to zero), and is absent from the 2017 file. Otherwise the Sel/DeSel commands are the same, and there is no other major parameter change (IMO). The one thing that may be significant, is that the EEEPROM flag is the same in both FWs, so the EEPROM remains the same , and I think it was written from the current FW. I changed the EEPROM flag so they are different between the two versions; i believe it will be updated whenever the other type is loaded. Also, I changed the E steps/mm by 1 count, so I can tell which is loaded by checking in Host. Sometime today or tonight, I'll load the current FW again and see if it makes any difference with the EEPROM being updated. In the interim, the SEL/DESEL commands are below. They are identical in both versions.#define EXT0_SELECT_COMMANDS "M209 S0 \n G92 E0 \n G1 E38.0 F1000 \n G91 \n G1 Z-1.0 F5000 \n G90 \n G92 E0 \n G1 E3.0 F2000 \n M209 S1 \n G92 E0 \n M400"
#define EXT0_DESELECT_COMMANDS "M209 S0 \n G92 E0 \n G1 E-3.0 F2000 \n G91 \n G1 Z1.0 F5000 \n G90 \n G92 E0 \n G1 E-38.0 F2000 \n M209 S1 \n G92 E0 \n M400"

Repetier

RAISE_Z_ON_TOOLCHANGE is not stored in eeprom. But it would solve your problem if you just used it instead of trying to raise your self making the G91/G90/G1 Z unneeded.
Here you also see where the problem might happen (Extruder::selectById)

if(Printer::isHomedAll()) { Printer::moveToReal(cx, cy, cz, IGNORE_COORDINATE, EXTRUDER_SWITCH_XY_SPEED); } #endif Printer::feedrate = oldfeedrate; Printer::updateCurrentPosition(true); #if USE_ADVANCE HAL::resetExtruderDirection(); #endif // USE_ADVANCE
#if NUM_EXTRUDER > 1 && MIXING_EXTRUDER == 0 if(executeSelect) {// Run only when changing Commands::waitUntilEndOfAllMoves(); GCode::executeFString(next->selectCommands); } #endif #endifYou see it moves to starting position and THEN it executes your command.
Thinking about it, it should better end like this#if NUM_EXTRUDER > 1 && MIXING_EXTRUDER == 0 if(executeSelect) {// Run only when changing Commands::waitUntilEndOfAllMoves(); GCode::executeFString(next->selectCommands); }#endif#if DUAL_X_AXIS == 0 || LAZY_DUAL_X_AXIS == 0#if RAISE_Z_ON_TOOLCHANGE > 0 && !LAZY_DUAL_X_AXIS if (Printer::isZHomed()) { Printer::moveToReal(IGNORE_COORDINATE, IGNORE_COORDINATE, cz, IGNORE_COORDINATE, Printer::homingFeedrate[Z_AXIS]); Printer::lastCmdPos[Z_AXIS] = lastZ; }#endif
if(Printer::isHomedAll()) { Printer::moveToReal(cx, cy, cz, IGNORE_COORDINATE, EXTRUDER_SWITCH_XY_SPEED); }#endif Printer::feedrate = oldfeedrate; Printer::updateCurrentPosition(true);#endif

}so positioning to start position is the last and not the deselect command.

Doug40

I will remove the Z commands from the Sel/Desel strings, and I'll try it.
I never did any serious coding, and being retired for almost 20 years hasn't helped; so most of of the code went over my head. But, when I saw the Raise Z on Tool Change parameter, I wondered if that routine could cause any problem with the Sel/Desel.

Doug40

As you suggested, removing the Z commands from the Sel/Desel strings did indeed fix the problem.
Many thanks!