Intermittent extruder loss and stutters. 6HC/toolboard/RRF3.2

dc42

The drivesRelative value is maintained separately for each input channel. So sending M83 from the DWC console channel won't affect the File channel.

dc42

The print I did completed perfectly; but I am running in standalone mode. So my suspicion is that in SBC mode, the M83 command at line 22 of your GCode file is not being executed. My suggestions are:

Line 19 of the GCode file reads:

print_start

That is not a valid command. Perhaps it is confusing DSF? Please remove it, or add a leading semicolon to turn it into a comment.

Try running the Duet in standalone mode, to see if the problem ever occurs when not using SBC.

hamel

@dc42 Will do. It is a pretty long task to switch to standalone, so I will try to get that done next week. I have to get our IT department to set up the network (huge pain...I have to do it for anything connected, and I am not running a panel). I'll give standalone a shot next week and report back.

As far as the gcode goes, that was what Cura output, and it seems that it does that for all of my slices (for any printer). I commented it out and ran a test, and there was no change (extruder did not turn when printing).

Are there any tricks that will let me keep it in SBC mode and test? If so, I can try to run the tests over the weekend.

dc42

If connecting the Duet directly to the network is problematic, can you copy the print file to the SD card before you insert it into the Duet, and then start the print from a laptop connected to the Duet either via USB or directly using an Ethernet cable?

hamel

Brilliant. I will do that tomorrow. Thank you.

hamel

@dc42

Just wanted to let you know that in standalone mode I have a print running just fine. So it does seem to be an issue with SBC mode. Thoughts?

T3P3Tony

@hamel thanks for the report. I have run your print on a SBC connected Duet3 mainboard with a toolboard and it is also running fine. In this case I am using the following firmware versions:
Mainboard
FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC FIRMWARE_VERSION: 3.3beta2+1 ELECTRONICS: Duet 3 MB6HC v0.6 or 1.0 FIRMWARE_DATE: 2021-03-22 13:48:32
Toolboard
Duet TOOL1LC firmware version 3.3beta2+1 (2021-03-20 14:03:00)
DSF
DSF Version: 3.3-b2

@dc42 will need to confirm if its worth you upgrading to those unofficial firmware versions to test., I am using them to test something unrelated to your issue.

Btw in order to make your print run on my machine I had to make the following changes to the start gcode in your print file:

T2
;M190 S80
;M104 S260
;M109 S260
M82 ;absolute extrusion mode
;print_start
T2
;G28
M83 ;relative extrusion mode
G1 F3600 E-2
;LAYER_COUNT:150
;LAYER:0
M107
G1 F600 Z0.7
G0 F7200 X-19.925 Y-8.452 Z0.7
;TYPE:SKIRT
G1 F600 Z0.2
G1 F1440 E2
G1 F1500 X-19.915 Y-9.157 E0.02638
G1 X-19.867 Y-9.789 E0.02372

I can't see how commenting out the temperature settings and homing should have anything todo with your issue though.

Also due to different extruders I changed the retract/unretract distance from 6.5mm to 2mm but once again that should not be related to this issue.

dc42

@hamel said in Intermittent extruder loss and stutters. 6HC/toolboard/RRF3.2:

@dc42

Just wanted to let you know that in standalone mode I have a print running just fine. So it does seem to be an issue with SBC mode. Thoughts?

Thanks. I have asked @chrishamm to look into this.

chrishamm

@hamel Is there any particular reason why you encapsulate T-codes in M82/M83? It would be better to call M82/83 right in the tool change macros. Also note that the absolute/relative drive mode is restored when the tool change macro returns, so you don't need to worry about that anyway.

I did a simulation with that file on v3.3b2 and it all completed nicely. Extruder progress wasn't off either.

Looking at your diagnostics I am quite sure I can tell you why you've been experiencing problems; you are running an unsupported DSF/RRF/DWC combination. You must upgrade your SBC using apt over the unstable feed, upgrading only the firmware and retaining an earlier DSF version is likely to lead to problems.

hamel

@chrishamm Thanks for the insight.

I was under the impression that I did update with SBC to the unstable feed, but maybe I am doing it wrong. Could you post the apt string that will give me 3.3b2 for DSF? I thought I was using the correct file link, but the whole process of loading from the unstable feed is very vague to me. I just upgraded to 3.3b2 firmware, and I redid the DSF following the guide for unstable feed, but it seems that it is still not upgrading DSF. It does seem like it took, but when I check, there is no change.

Regarding the t-codes, this is just factory Cura, and that is how it generated the prime. I use the same gcode on my other duets, and I have never looked into changing that, as it has never been an issue before.

Phaedrux

@hamel https://duet3d.dozuki.com/Wiki/Getting_Started_With_Duet_3#Section_Software_Installation

See here for adding the unstable test branch to update from.

hamel

@phaedrux Thank you.

Should there be any type of response from the Pi? Everytime I send those commands, it seems like nothing is being changed.

How can I verify what DSF I have installed?