zebrajack
commented
10 years ago I have encounter the same problem. https://github.com/ErikZalm/Marlin/issues/834#issuecomment-37581149 , My problem: "We did encounter the weird extra ghost signals which is really annoying. But sometimes is clueless. my team has tried all the method you listed to avoid it. Recently, we doubt the SD card will sometimes fails to push the gcode data to buffer which may cause instability. USB has data verified mechanism, we just want to copy it to SD card.I did tweak the code a little bit. but since I am not good at coding, I want to share my thought here and look for help."
I've implemented an algorithm for uploading gcode to SD, which takes the printer's gcode buffer size into account.
The algorithm keeps track of how many characters of gcode have been sent, and how many have been acknowledged (by tracking "ok" messages).
My original version would wait until there was enough room in the gcode buffer to receive an entire line of gcode, and then send it - usually leaving some free space in the buffer.
The problem was that occasionally (but often enough to disrupt every upload), the printer would stop sending "ok" messages. After looking into it, I found that there was unprocessed gcode sitting in the printer's input buffer.
I attempted a hack, by adding a timeout to my send routine - on timeout, I would send a single carriage return, to "tickle" the printer into processing the gcode it had sitting. This would work, sporadically, but not well enough to rely on.
I then re-wrote the communications code to break lines of gcode into two packets, and always send enough gcode to completely fill the input buffer. This algorithm appears to work around the firmware bug.
I'm worried that there's the possibility that the last bit of gcode sent could end up being jammed - still, polling the printer for status would eventually fill the input buffer and break the jam loose.
I think that what I'm seeing here may be a design issue with the USB stack - the API implies that it will wait until 256 characters are received before notifying the caller. Oddly, when sending single lines of gcode (using printrun), this does not appear to be the case.
I'm not sure that there's a good reason to spend a lot of time working on this, as I have a reasonable workaround. Still, I'd like to understand the underlying problem.