Output buffers running out

dc42

Thanks. I have messy config with both RRF2 and RRF3 options too! I leave both enabled and I ignore the warning messages on startup.

You don't need the M540 command, it looks like a hangover for when you were using an older Duet.

Did you test whether the linefeeds occur with RRF2 as well as RRF3?

PS - have you tried running the print in simulation mode, to see if you still get the linefeeds?

DeltaCon

In my case (Duet 0.6) going from 2.03 to 2.04 the problem was also much lees frequent. It went from a few times per hour to a few times a day. Also I noticed that sometimes DWC succeeds in a reconnect, but that does not last for long. DC have you programmed some sort of buffer purge or something? A powercycle is needed to get any work done in DWC. However the printjob keeps going without issues. I am using KISSlicer mostly too, but doubt that it is causing this issue.

At first I thought the conversion from TL lighting to LED lighting in my office was responsible for the less frequent issue because the TL used to flicker a lot and I was thinking about electrical noise. But in retrospect I think it was DC's effort in the 2.04 version

Adrian52

@dc42 The line feeds and buffers running out behaved very similarly in rrf2 and rrf3. No line feeds during simulation with 2 or 3.

dc42

Thanks. I'm running your print on my delta now. No linefeeds in YAT so far, but it's still on the first layer.

dc42

OK, I am getting linefeeds now!

Adrian52

@dc42 they really get going for me in the top 3mm

dc42

It's not to do with retractions. I commented out all the G10 and G11 commands in the file, and it still produces the linefeeds.

dc42

Looks like it's the M106 commands in the file that provoke the linefeeds.

dc42

I have found the reasons for the line feeds, and a plausible (but not conclusive) explanation for the loss of output buffers. However, I was unable to reproduce the issue with loss of output buffers. Would you be willing to test a firmware build that deliberately leaves the linefeeds but (hopefully) fixes the output buffer issue? If so, would you prefer a RRF2 or RRF3 build?

Adrian52

@dc42 that would be fine. I am set up for both 2 and 3, so whatever is convenient.

dc42

@Adrian52, when you have had the output buffers being used up, have you ever run M122 and checked the "Error status" field in the Platform section? I have a feeling that bit 3 (i.e. value 8 ) may be set. Of course there would have to be enough output buffers left for that section to be present in the M122 report.

sdavi

@dc42 btw there is a missing buf->whenQueued = millis(); in OutputBuffer::Allocate. Probably more a issue only affecting the LPC port due to the smaller UART ringbuffer, but was causing some buffers to incorrectly timeout.

Adrian52

@dc42 I have just checked some recent yat M122 reports I had saved when the buffers were full, and they have error status 14, which I guess is 01110. Will update if I find a different error.

dc42

@Adrian52 said in Output buffers running out:

@dc42 I have just checked some recent yat M122 reports I had saved when the buffers were full, and they have error status 14, which I guess is 01110. Will update if I find a different error.

Thanks, that figures. There are at least 3 bugs contributing to this issue: the . I'm fixing the third one now.

mechg

@dc42 In case it is still useful to you, you can also cause Duet to run out of buffers by slicing a large object with PrusaSlicer , having enabled the Printer Settings->General->Firmware->Supports Remaining Times option.

This option puts M73 commands into the gcode which only Prusa printers support. Duet will throw errors and the output buffers will eventually be used up. This can take a while, of course.

This was happening to me when I mistakenly selected that option, and the web interface would disconnect part way through a print, and I could not reconnect until I cycled the power on my Artemis printer. I had seen the "M73 command not supported" errors, but I ignored them until I figured out they were causing the buffers to be consumed.