Check print/stop parts order

[peteruithoven]

When someone presses the stop button while still sending print parts it can happen that the stop request arrives at the box before another print part, even though on the client side the order was 1. sending print part and 2. stop. So it seems like requests to the api take longer than others. The fact that print parts requests are bigger might be a reason. When this happens the printer will perform the stop code and continue with just that last the print part.

To prevent this issue we currently bluntly hide the stop button while sending print parts, see: https://github.com/Doodle3D/doodle3d-client/issues/35

We should have a check on the api side that check whether the print part belongs after that end part. We could start by adding first and last booleans or even check the exact order.
We wanted to check the order because sending prints on the iPad went wrong in the past, but this didn't happen during any of the last tests.

[peteruithoven]

I've created forks of the firmware and client for this. If you specify a seqNum in the printer/print call it will now check if it's in the right sequence. But this doesn't seem to solve our problem. I can actually see in /tmp/wifibox.log that the printer/stop is called after print/print, but somehow code is added to the gcode buffer that is executed after the endcode of the stop. I suspect that the socket (lua c binding) connection is the problem now, that this is still busy in the background after the stop is called. @woutgg what do you think?

[woutgg]

That could very well be possible. A solution could be to send the sequence numbers along with the data over the socket. Then the server itself (the GcodeBuffer in fact) could perform the checks.

[peteruithoven]

And what if we use a file for gcode buffer? Is it just me or would that also reduce the time it takes to send a print? So we write the gcode to a file on the lua side and just send a filename over to the driver and the GcodeBuffer works directly from this same file.

I understand this would be quite a drastic change, but are u sure this lua c binding system was made for these amounts of data?

[woutgg]

The binding system has no problem at all with the data. Sending data by file is already implemented (the command-line frontend has an option to use it), so it would be a relatively easy change. If this speeds things up enough to solve this issue, by all means try it. It could be though, that it will still be too slow because of the gcode processing, I'm not sure about that.

[peteruithoven]

How do you time how long it takes to send something over the binding system? Could I check how long the printer:appendGcode(argGcode) in lua takes? I'm curious how much it difference it would make to disable MarlinDriver::extractGCodeInfo and GCodeBuffer::cleanupGCode.

[peteruithoven]

This is released with version 0.10.10.