Output buffers running out

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.