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

[dc42]

Thanks, I'll try that file on my Tool Changer, which uses tool boards.

[hamel]

Thank you @dc42 . Just as a note, I do not have to reboot to get a good print going (when it does happen). I just cancel and restart over and over, and after a few tries it will start working correctly. When it does not extrude, I can still pause and extrude fine, but it will only extrude with gcode when I do multiple "restart print"s.

[dc42]

@hamel, thanks. The firmware I will be using for this test is at https://www.dropbox.com/sh/6203euyyobllic5/AABTHIbn7F_maK9p-oy7vq3Ea?dl=0. It's later than 3.3beta2 but I am not aware of any changes that are likely to affect this behaviour.

I note that your M122 B121 reports say that the VIN voltage to the tool board is about 30V. Is that correct?

[dc42]

I am running your print for the first time, and it is printing OK. However, I am running in standalone mode because the machine doesn't have an attached SBC.

It occurred to me that one possible explanation is that fort reasons unknown, the GCode input channel for the print form file has somehow switched to absolute extrusion. This would account for why you are still able to extrude form DWC, and also for why restarting the print sometimes clears the problem (because your GCode file includes the M83 command).

Therefore, please can you provoke the problem, then pause the print, then use the Object Model explorer plugin in DWC to examine the 'inputs' key. Element number 2 in this list should look something like this:


[Sorry, upload failed, I need to switch browser - I will post the image shortly.]

[Sorry again, I can't login at all from FireFox at present.]

What I expect is that inputs[2] shows name="File" and drivesRelative="true".

[hamel]

@dc42 Thank you. I think you might be on to something.

When it is extruding fine, and when it is not extruding, the input2 name is file, but the drivesRelative is always false (when extruding correctly or when not extruding). Sending m83 or m82 does not change the print or the issue. If I send a m82, I should see that object model change to a drivesRelative=true, and with an m83 I should see it change to a drivesRelative=false. Is that correct? That is not the behaviour I am seeing. I see no change in the object model values.

[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:

1. 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.

2. 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?