On 23 Aug 2013 , at 5:40 AM, Scott Goldthwaite wrote:
> I'm unclear about what self.file.flushInput() is fixing.
It's fixing makerware/conveyor. If you do not understand what it is doing,
remove it and see what the code does. Namely, it's possible that garbage
has previously been sent down the serial line to the bot. When MW tries
sending data, enough bytes get pushed through to cause the bot to send
back an error response and then a response to the valid command from MW.
MW, however, sees the error response to the garbage in the pipeline and
simply resends the same command over again. Then MW sees a nice response
to the first command it sent, and then sends some other command. To that
other command, it sees the nice response to the resend of the first
command. This confuses MW. RepG, btw, never had this issue: it knew
about this case. So, obvious workaround is to have MW flush it's
input buffer before resending a command a second time.
BTW, this would not be a problem if years back MBI correctly implemented
the s3g "clear buffers" command. However, they implemented that as a
"reset the uprocessor" command and thus it has unwanted side effects.
> From your
> explanation it sounds like it's making USB communication more reliable by
> dealing with errors.
Correct. And MW wasn't correctly dealing with errors.
> How does that let you tell the bot which file from
> the SD card to print?
> It seems like there are two different things going
> on here and I'm missing one of them.
Point being that if you're going to lift some code from MW/Conveyor, then
you may also need a fix to that code which, when I wrote that, MBI had not
yet shipped. And, Sailfish 7.5 had restored sending s3g errors -- something
the MBI firmware used to do in the past (and thus RepG handled). But in
some push-me-pull-you error fixing by MBI about two years ago, someone
commented out in the firmware where it would return s3g error responses.
(Instead, it would return nothing.) Problem with not returning error
responses is that both RepG and MW would, after not getting a response
N times to a command would then just skip that command and send the
next one in the queue. So, things like heaters might not get turned
off or digipots not get set correctly, etc., etc. And we discovered
this in Sailfish when we had a documented, reproduceable case which
a user found and reported. Jetty and I diagnosed it and fixed it in
Sailfish and then reported it to MBI and worked with their engineers
on addressing it in their firmware and MakerWare.