DEV2 - TOOL_EXTRUDER gcode fail
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?
Comments
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
which would select extruder 0 which then tries to home ...
Please comment
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.
Workaround for now: Try G1 A0 instead and send G28 A0 at startup when you connect for example. Would that work?
I tested G28 A0. It gives the same result as G28 A
// Tool :: selectTool (activeToolId, true); in MotionLevel1.cpp is OK
I 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.00
Recv:10:38:40.814: Warning:Endstop for axis A did not untrigger for retest!
Recv:10:38:40.845: Info:Autoleveling disabled
Recv:10:38:40.846: X:320.00 Y:300.00 Z:300.000 E:0.0000 A:0.00
Recv: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)
- 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 disabled
Recv:16:47:33.892: X:0.00 Y:0.00 Z:0.000 E:0.0000 A:0.00
Recv:16:47:34.715: Warning:Endstop for axis A did not untrigger for retest!
Recv:16:47:34.746: Info:Autoleveling disabled
Recv: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:1
Recv:16:47:39.178: X_OFFSET:0.000 Y_OFFSET:0.000 Z_OFFSET:0.000 A_OFFSET:0.000
Recv:16:47:40.638: SelectTool:0
Recv:16:47:40.638: Info:Autoleveling disabled
Recv:16:47:40.639: X:0.00 Y:0.00 Z:0.000 E:0.0000 A:8.00
Mesg:16:48:15.727: Connection closed by os.
Mesg:16:48:16.737: Dtr: true Rts: true
Mesg:16:48:16.745: Connection started
Mesg:16:48:16.746: Dtr: false Rts: false
Mesg:16:48:16.770: Dtr: true Rts: true
Recv:16:48:16.781: Error:expected line 1 got 24
Recv:16:48:16.781: Response while unconnected:Resend:1
Recv:16:48:16.781: Resend:1
Recv:16:48:16.794: Response while unconnected:ok
Recv:16:48:16.796: DebugLevel:6
Recv:16:48:16.796: info:Continue from fatal state
Recv: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:4
Recv:16:48:16.799: Cap:PROGRESS:1
Recv:16:48:16.799: Cap:AUTOREPORT_TEMP:1
Recv:16:48:16.799: Cap:HOST_RESCUE:1
Recv:16:48:16.800: Cap:EEPROM:1
Recv:16:48:16.800: Cap:AUTOLEVEL:0
Recv:16:48:16.800: Cap:Z_PROBE:0
Recv:16:48:16.800: Cap:SOFTWARE_POWER:0
Recv:16:48:16.800: Cap:TOGGLE_LIGHTS:1
Recv:16:48:16.800: Cap:PAUSESTOP:1
Recv: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=qUFucP
Configuration.h https://1drv.ms/t/s!Ak8QYQq1MpUzmHCRe8BpDH4fsmWD?e=ZwV125
Currently the printer works perfectly with Repetier firmware V1.03 on an MKS RUMBA8 board
So there is a G28 A when you go back from T1 to T0. So please try
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.
https://github.com/bigtreetech/BIGTREETECH-TFT35-V3.0/tree/master/Hardware
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:
When the screen is in LCD mode, no problem, either with the Repetier screen menu or with Repetier-Server.
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.
Here is an example of testing my printer with Repetier firmware V1.03:
and see if that resolves it for you
I will do more testing, but it seems to be working!
@AbsoluteCatalyst, @Repetier, thank you very much!
Found & fixed another small/elusive crash if you happen to have a Z home in your start tool script
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.