Can´t print with extruder 2.
-
OK so it looks like it isn't to do with tool changes. As I understand it from your first post, the tool heats OK, it starts to print and then it freezes and the web display shows the print progress as 100%, as if the print has finished. This only happens with T1 and never with T0, is that correct?
-
OK so it looks like it isn't to do with tool changes. As I understand it from your first post, the tool heats OK, it starts to print and then it freezes and the web display shows the print progress as 100%, as if the print has finished. This only happens with T1 and never with T0, is that correct?
Yes that's correct, never happens with T0, have had many successed prints when only using T0. I'm now trying with exactly the same g code, just changed T0 to T1 and the problem occurred
-
Is it possible there is a T0 command somewhere later in the Gcode?
Also does it freeze at eactly the same point each time?
-
Is it possible there is a T0 command somewhere later in the Gcode?
Also does it freeze at eactly the same point each time?
searched the whole code no T0, freezes at the same point every time, freezes on a normal G1 movement.
-
It could indicate a short in the extruder 1 or heater 2 wiring. Does heater 2 show a stable temperature?
When the print freezes, do the axes show as no longer homed in DWC? This would indicate that the Duet is resetting. If so, run M122 to see the last reset time and reason.
-
And yet if you run the same G-code with the initial T1 replaced with T0 it works fine?
Can you replicate this working with T0, not working with T1 on a different gcode file?
-
Is there anything other than a reset that could cause the print progress to go to 100%? If not, then I guess it has to be wiring issue on T1 that is triggering the reset, so a short or some such?
-
It could indicate a short in the extruder 1 or heater 2 wiring. Does heater 2 show a stable temperature?
When the print freezes, do the axes show as no longer homed in DWC? This would indicate that the Duet is resetting. If so, run M122 to see the last reset time and reason.
Heater 2 is showing a stable temperature.
When freezing the whole webinterface freezes, can´t do anything (and all axis show homed)Just tried an other g code with the same problem, working with T0 but not with T1, this time it freezes by the first layer doing the first G1.
The privious file froze at layer 4 -
(with the board powered down)
try swapping T0 and T1 and see if the fault moves or stays the same.
-
Is there anything other than a reset that could cause the print progress to go to 100%? If not, then I guess it has to be wiring issue on T1 that is triggering the reset, so a short or some such?
If there is a short this must be on the board, since I have tried switching the heaters/thermistors on the board.
Both heaters works as T0 but not T1 -
Tried to run one of the g codes that crashed earlier once more, this time manually line by line in the web interface and surprisingly it didn´t crash.
How can it be that everything freezes when I run the code in auto and not when I run it manually row by row? -
The buffer for the gcode may have a glitch,
-
Now it actually happened with T0 as well (for the first time), crashed with five layers remaining at a five-hour spiral vase print.
I'm going nuts, what can cause these crashes?
As I´ve said before, it happens every time with T1 but almost never with T0 (this was the first).
I can´t see anything wrong in the config or g codes (but I´m no expert needs to be said).
And I don´t think that it´s a wiring issue since the problem follows that extruder that is connected as T1 on the board.
Anyone else that experience mid-print faults, that might have a solution to my problem?
Could it be something wrong with my board? -
Now it actually happened with T0 as well (for the first time), crashed with five layers remaining at a five-hour spiral vase print.
I'm going nuts, what can cause these crashes?
As I´ve said before, it happens every time with T1 but almost never with T0 (this was the first).
I can´t see anything wrong in the config or g codes (but I´m no expert needs to be said).
And I don´t think that it´s a wiring issue since the problem follows that extruder that is connected as T1 on the board.
Anyone else that experience mid-print faults, that might have a solution to my problem?
Could it be something wrong with my board?Please explain what you mean by "crashes". Does the board reset? Run M122 to find out. If the "Last reset time" corresponds to when the print stopped unexpectedly, instead of before you started the print, tell us what it shows for "Last reset reason" and "Last software reset code".
-
Now it actually happened with T0 as well (for the first time), crashed with five layers remaining at a five-hour spiral vase print.
I'm going nuts, what can cause these crashes?
As I´ve said before, it happens every time with T1 but almost never with T0 (this was the first).
I can´t see anything wrong in the config or g codes (but I´m no expert needs to be said).
And I don´t think that it´s a wiring issue since the problem follows that extruder that is connected as T1 on the board.
Anyone else that experience mid-print faults, that might have a solution to my problem?
Could it be something wrong with my board?Please explain what you mean by "crashes". Does the board reset? Run M122 to find out. If the "Last reset time" corresponds to when the print stopped unexpectedly, instead of before you started the print, tell us what it shows for "Last reset reason" and "Last software reset code".
With crashes I mean that everything freezes, web interface showes 100% progress and then everything freezes.
I have noted that if I wait a couple of seconds then I´m able to disconnect and then reconnect and when I run M122 these are the resets codes:
Last reset 00:00:11 ago, cause: software
Last software reset code: 0x5004, available RAM 24636 bytes (slot 0) -
The software reset code info at https://duet3d.com/wiki/Error_codes_and_software_reset_codes indicates that a software reset occurred because the firmware was trying to write debug info or other essential info to the USB port, but writing was b!Locked because the port wasn't connected or the program at the other end had stopped reading data from it.. This should only occur if you enable debug output using the M111 S1 command.
Assuming you do not have the USB port connected, I suggest you connect it to a PC, load Pronterface or another USB host program, and connect to the printer. Then do something that normally provokes the problem and see what messages appear on the PC.
-
The software reset code info at https://duet3d.com/wiki/Error_codes_and_software_reset_codes indicates that a software reset occurred because the firmware was trying to write debug info or other essential info to the USB port, but writing was b!Locked because the port wasn't connected or the program at the other end had stopped reading data from it.. This should only occur if you enable debug output using the M111 S1 command.
Assuming you do not have the USB port connected, I suggest you connect it to a PC, load Pronterface or another USB host program, and connect to the printer. Then do something that normally provokes the problem and see what messages appear on the PC.
Pronterface messages this:
[ERROR] Can't read from printer (disconnected?) (SerialException): call to ClearCommError failed
Exception in thread Thread-20:
Traceback (most recent call last):
File "threading.pyc", line 808, in __bootstrap_inner
File "threading.pyc", line 761, in run
File "printrun\printcore.pyc", line 357, in _sender
File "printrun\printcore.pyc", line 623, in _send
File "encodings\utf_8.pyc", line 16, in decode
UnicodeDecodeError: 'utf8' codec can't decode byte 0xe4 in position 38: invalid continuation byte -
Unfortunately, that doesn't help because Pronterface has reported an exception in its own code without displaying the rest of the data. Do you have Arduino (any version) installed on your computer? If so, please try the same test again, but with Arduino Serial Monitor connected to the COM port that the Duet provides instead of Pronterface.
Also please check that the software reset code reported by M122 is the same as before.
-
Unfortunately, that doesn't help because Pronterface has reported an exception in its own code without displaying the rest of the data. Do you have Arduino (any version) installed on your computer? If so, please try the same test again, but with Arduino Serial Monitor connected to the COM port that the Duet provides instead of Pronterface.
Also please check that the software reset code reported by M122 is the same as before.
The seriell monitor shows this at start up and then nothing more:
RepRapFirmware for Duet WiFi Version 1.17c dated 2017-01-14
Executing config.g…RepRap name: My Duet
M570 S parameter is no longer required or supported
Done!
RepRapFirmware for Duet WiFi is up and running.
WiFi server starting up
WiFi server connected to access point
WiFi host name duetwiSame software reset code is reported as before when running M122
Also tried removing all M570 since the monitor said it´s no longer supported, didn´t help -
This one has me puzzled. You reported software reset code 0x5004. This means that the Move module was executing at the time and it was stuck in a spin loop for too long while waiting for the USB output buffer to clear. For that to happen, Move or DDA debug output would have to be enabled, but the USB would either have to be disconnected or the program at the other end not receiving. The error from Pronterface suggests that it did receive something (that it didn't understand). The serial monitor output shows that the connection was working when the Duet started up. But there are a couple of odd things: it has started up as an access point (i.e. not connected to your router), and it hasn't printed the whole of the access point name - it should be "duetwifi" not "duetwi". It's as if the USB connection stopped working at that point.
