DEV2 - TOOL_EXTRUDER gcode fail

frguy

On my MKS RUMBA32 board with 2 extruders, I use a tool change Gcode:

startScript T0 => homing A "G28 A"

startScript T1 => moving A "G1 A30"

TOOL_EXTRUDER(ToolExtruder1, 0, 0, 0, HeaterExtruder1, E1Motor, 1.75, 221.0, 20, 30, 1000, 40, "G28 A", "", &Fan1PWM)

TOOL_EXTRUDER(ToolExtruder2, 12, 0, 0, HeaterExtruder2, E2Motor, 1.75, 221.0, 20, 30, 1000, 40, "G1 A30", "", &Fan1PWM)

These commands work correctly with the console.

On the other hand, when I select T1, the A axis moves 30mm, but when I next select T0, the homing stops along the way and the printer freezes.

The console indicates:

Recv:17:37:18.846: SelectTool:1

Recv:17:37:18.846: Warning:Cold extrusion prevented

Recv:17:37:21.083: X_OFFSET:0.000 Y_OFFSET:0.000 Z_OFFSET:0.000 A_OFFSET:0.000

Recv:17:37:22.419: SelectTool:0

Recv:17:37:22.420: Info:Autoleveling disabled

Recv:17:37:22.420: X:290.00 Y:158.00 Z:0.000 E:0.0000 A:30.00

How can I solve this problem?

Repetier

Have you tried G28 A0 instead of G28 A? Not 100% sure what interpreter does here. But why A? Is this some rotary system for selection with endstop for A?

G28 is the most complex command. There is a chance that it does not work inside an other command (T0) for that reason also I think should be possible if it does not cause a recursion. Thinking of it MotionLevel1::homeAxes has near the end

if (Tool::getActiveTool() != nullptr && ok) { // select only if all is homed or we get unwanted moves!

Tool::selectTool(activeToolId, true);

}
which would select extruder 0 which then tries to home ...
Please comment

// Tool::selectTool(activeToolId, true);

and retry if it then does not crash. The call is made to readjust extruder offsets after homing. In this case it could be omitted especially if I assume offsets are 0,0,0. But better would be a smart solution maybe check if xyz was homed and only then select the tool again.

But that would need further analysis.

Workaround for now: Try G1 A0 instead and send G28 A0 at startup when you connect for example. Would that work?

frguy

I tested G28 A0. It gives the same result as G28 A// Tool :: selectTool (activeToolId, true); in MotionLevel1.cpp is OKI tried G1 A0 instead and send G28 A0 at startup. Same result.
- If I send G28 A0, G1 A30 and G28 A0 manually, that works all time. - If I select T1, "A" normally move. And if I select T0, "A" moves and stops along the way (frozen). - If I do a general "G28" homing:#define X_HOME_PRIORITY 0#define Y_HOME_PRIORITY 1#define Z_HOME_PRIORITY 2#define A_HOME_PRIORITY 3 - "A" takes its reference, go back (#define ENDSTOP_A_BACK_MOVE 1) then resumes its reference, then go back and so on without stopping...
If I use #define ENDSTOP_A_BACK_MOVE 0 (I don't have the use of back move) - If I send G28 A0, G1 A30 and G28 A0 manually, that works all time. - If I do a general "G28" homing, "A" takes its reference and freeze.The console indicates:Recv:10:38:40.813: X:320.00 Y:300.00 Z:300.000 E:0.0000 A:0.00Recv:10:38:40.814: Warning:Endstop for axis A did not untrigger for retest!Recv:10:38:40.845: Info:Autoleveling disabledRecv:10:38:40.846: X:320.00 Y:300.00 Z:300.000 E:0.0000 A:0.00Recv:10:38:40.846: SelectTool:0
If I deactivate the endstop "A" Max://IO_INPUT_INVERTED_PULLUP(IOEndstopAMax, ORIG_Y_MIN_PIN)ENDSTOP_NONE(endstopAMax)

#define NO_MOTOR_ENDSTOPS

- If I send G28 A0, G1 A30 and G28 A0 manually, that works all time. - If I do a general "G28" homing. All is OK - After G28, if I select T1, "A" normally moves and the X offset is well (12mm). But if I select T0 "A" move and stops along the way (frozen). X offset don't back.When the printer is frozen, after a few moments, it will reset:
Recv:16:47:33.892: Info:Autoleveling disabledRecv:16:47:33.892: X:0.00 Y:0.00 Z:0.000 E:0.0000 A:0.00Recv:16:47:34.715: Warning:Endstop for axis A did not untrigger for retest!Recv:16:47:34.746: Info:Autoleveling disabledRecv:16:47:34.747: X:0.00 Y:0.00 Z:0.000 E:0.0000 A:0.00 (2)Recv:16:47:37.536: SelectTool:1Recv:16:47:39.178: X_OFFSET:0.000 Y_OFFSET:0.000 Z_OFFSET:0.000 A_OFFSET:0.000Recv:16:47:40.638: SelectTool:0Recv:16:47:40.638: Info:Autoleveling disabledRecv:16:47:40.639: X:0.00 Y:0.00 Z:0.000 E:0.0000 A:8.00Mesg:16:48:15.727: Connection closed by os.Mesg:16:48:16.737: Dtr: true Rts: trueMesg:16:48:16.745: Connection startedMesg:16:48:16.746: Dtr: false Rts: falseMesg:16:48:16.770: Dtr: true Rts: trueRecv:16:48:16.781: Error:expected line 1 got 24Recv:16:48:16.781: Response while unconnected:Resend:1Recv:16:48:16.781: Resend:1Recv:16:48:16.794: Response while unconnected:okRecv:16:48:16.796: DebugLevel:6Recv:16:48:16.796: info:Continue from fatal stateRecv:16:48:16.799: FIRMWARE_NAME:Repetier_2.0.0dev COMPILED:Oct 2 2020 FIRMWARE_URL:https://github.com/repetier/Repetier-Firmware/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:Cartesian EXTRUDER_COUNT:NUM_EXTRUDER REPETIER_PROTOCOL:4Recv:16:48:16.799: Cap:PROGRESS:1Recv:16:48:16.799: Cap:AUTOREPORT_TEMP:1Recv:16:48:16.799: Cap:HOST_RESCUE:1Recv:16:48:16.800: Cap:EEPROM:1Recv:16:48:16.800: Cap:AUTOLEVEL:0Recv:16:48:16.800: Cap:Z_PROBE:0Recv:16:48:16.800: Cap:SOFTWARE_POWER:0Recv:16:48:16.800: Cap:TOGGLE_LIGHTS:1Recv:16:48:16.800: Cap:PAUSESTOP:1Recv:16:48:16.800: Cap:PREHEAT:1
I have tried a number of settings without success.If that can help you, here is the current setup (it is not really clean after all these tests.):Configuration_io.h https://1drv.ms/t/s!Ak8QYQq1MpUzmHFn-wosXZP_Y9OF?e=qUFucPConfiguration.h https://1drv.ms/t/s!Ak8QYQq1MpUzmHCRe8BpDH4fsmWD?e=ZwV125<br/>Currently the printer works perfectly with Repetier firmware V1.03 on an MKS RUMBA8 board

Repetier

In your example you still have

TOOL_EXTRUDER(ToolExtruder1, 0, 0, 0, HeaterExtruder1, E1MotorBase, 1.75, 220.0, 20, 30, 1000, 40, "", "", &Fan1PWM)

TOOL_EXTRUDER(ToolExtruder2, 12, 0, 0, HeaterExtruder2, E2MotorBase, 1.75, 220.0, 20, 30, 1000, 40, "G1 A8", "G28 A", &Fan1PWM)

So there is a G28 A when you go back from T1 to T0. So please try

TOOL_EXTRUDER(ToolExtruder1, 0, 0, 0, HeaterExtruder1, E1MotorBase, 1.75, 220.0, 20, 30, 1000, 40, "G1 A0", "", &Fan1PWM)

TOOL_EXTRUDER(ToolExtruder2, 12, 0, 0, HeaterExtruder2, E2MotorBase, 1.75, 220.0, 20, 30, 1000, 40, "G1 A8", "", &Fan1PWM)

Instead. And if you want to test with G28 modify MotionLevel1::homeAxes as I described above which should exclude the part I make responsible for the hang.

frguy

Sorry, I did not see that you indicate to deactivate the line.

That's now better, but there is a strange thing: It only works if the TFT screen is disconnected.

If the line "Tool :: selectTool (activeToolId, true);" is active: "G28 A0" works, but "T0" freeze and reset. With TFT screen connected or not.

If the line "// Tool :: selectTool (activeToolId, true);" is inactive: "T0" works, but only if the TFT screen is disconnected.

I simulated a print from the SD card of the TFT screen, and from Repetier-Server with the TFT screen connected at the board. Strangely, in both cases the printing took place normally.

No problem when selecting T0 and T1. The "A" axis takes its origins and returns without problems.

So, currently the selection of T0 (G28 A0) is working with TFT screen, only during printing.

Manual selection continues to freeze and reset the printer if the screen is connected.

I am using the Bigtreetech TFT35 V3 screen with last firmware:
https://github.com/bigtreetech/BIGTREETECH-TFT35-V3.0/tree/master/Hardware<br/></div><div>I use this screen with the Rumba8 and V1 without problems

Any idea on the origin of this problem?

Repetier

Since you mention the TFT the question arises how did you switch extruders? It is a difference if you send T0 to it or if you do it on the TFT. Also same function is called the lcd version is already a few level deep in menu system when the homing screen gets added. Maybe that is just too deep and causes the hang. If you increase in gui.h line 4

#define GUI_MAX_LEVEL 5

to 6 or 7 does it then also work from lcd? Next screen would already be level 5 and one more might cause the block.

Here the new version that I think should work for all:

if (Tool::getActiveTool() != nullptr && ok && (axes & 7) != 0) { // select only if all is homed or we get unwanted moves! Also only do it if position has changed allowing homing of non position axis in extruder selection.

Tool::selectTool(activeToolId, true);

}

frguy

As long as the TFT screen is active:

All the T0 commands sent by the Repetier-Server console or its head selection interface cause the problem, as well as screen controls in TFT mode. With the TFT, sometimes the problem only occurs after 1 or 2 successful switch.

When the screen is in LCD mode, no problem, either with the Repetier screen menu or with Repetier-Server.

I tested the changes in MotionLevel1.ccp and gui.h, but the problem persists.

I tested them together and separately.

With #define GUI_MAX_LEVEL 7, the motor seems stop faster than with 5 and 6.

frguy

I tested out of curiosity by changing the A axis to Y.

TOOL_EXTRUDER (ToolExtruder1, 0, 0, 0, HeaterExtruder1, E1MotorBase, 1.75, 220.0, 20, 30, 1000, 40, "G28 Y0", "", & Fan1PWM)

TOOL_EXTRUDER (ToolExtruder2, 12, 0, 0, HeaterExtruder2, E2MotorBase, 1.75, 220.0, 20, 30, 1000, 40, "G1 Y8", "", & Fan1PWM)

At startups, the axis moves a little to take its reference and the printer resets, then restarts. The cycle repeats itself indefinitely, whether the limit switch is activated or not.

The TFT screen indicates each time that it could not establish a connection with the board.

("A" axis ENDSTOP_A_BACK_MOVE = 0 and "Y" axis ENDSTOP_Y_BACK_MOVE = 3)

Finally, I tested with an MKS TFT35 screen.

The problem does not appear. So it would seem that this is an information processing problem linked to Bigtreetech's firmware?

How does fix this specific compatibility issue when everything else is working?

(All works on V1)

(The MKS screen does not allow nozzle spacing adjustment, its firmware is not open source, and it is very limited on the number of personal macros).

Repetier

So when you say TFT you meant the MKS screen and not a 128x64 pixel screen that I meant?
I did not know it was already working with repetier-firmware especially V2.

With G28 Y0 it tries maybe to execute it on startup causing a fail and reset so you get a loop. One question is how to monitor communication of the TFT with firmware so we could analyse what is going on. Debugging that can be quite hard.

Also now I ask myself when the print from repetier-server and also extruder switches work, what does the TFT send differently that it does not work. I would assume both are just sending T0 and T1. Or did I miss something else. A bit confused at the moment when exactly it fails and when it was no problem.

frguy

Yes, when I talk about TFT screen, I am talking about touch screen.

I have been using MKS and Beegtreetch touch screens with Repetier firmware for a long time without problems.

Once, however, I requested a change from beegtreetech, as the connection was no longer established after an update:

https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware/issues/552</div><div><br/>Here is an example of testing my printer with Repetier firmware V1.03: https://youtu.be/uKCD6Rok2HU<br/><br/></div><div>With Repetier V2, the problem appears when the "G28 A" command is sent by the "T0" command. "G28 A" alone is not a problem.

The problem may not be with the "G28" command specifically. It can be generated by processing the Gcode associated with the tool change. The homing has the particularity of having a long processing time.

Since your proposed change: // Tool :: selectTool (activeToolId, true), this has improved, but the "T0" command still does not work when Bigtreetech's TFT touchscreen is active. However, "T0" works normally with the touch screen during printing.

AbsoluteCatalyst

Hey! I was able to reproduce this and track it down with my stlink. Can you try the very small fix I pulled to the main repo here: https://github.com/repetier/Repetier-Firmware/pull/986/commits/2dce0d9fa60357f18b4f7dc01f886a2d07cc7349<br/>and see if that resolves it for you

frguy

Great!
I will do more testing, but it seems to be working!
@AbsoluteCatalyst, @Repetier, thank you very much!

AbsoluteCatalyst

No prob, be sure to check out the repo later in the week for more fixes!
Found & fixed another small/elusive crash if you happen to have a Z home in your start tool script :)

frguy

I did some tests. The problem is solved with your 2 fixes: if (Tool :: getActiveTool ()! = nullptr && ok && (axes & 7)! = 0) {// only select if everything is referenced or if we get unwanted movements! Also do this only if the position has changed, which allows the axis reference point without position in the extruder selection. Tool :: selectTool (activeToolId, true); } and if (ch == 0 ch == '\ n' ch == '\ r' ! isOpen ()) //! GCodeSource :: activeSource-> isOpen () / * (! commentDetected && ch == ':') * /) // full line read
Thanks again. I will now be able to test other functionality. :)