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: #35

More backstory: https://github.com/Doodle3D/doodle3d-firmware/issues/16

[peteruithoven]

A ToDo list for this issue:

Socket communication

• [x] checks (using start or end value)
• [x] collect one gcode chunk before sending it to printer driver

GCode buffer

• [x] Refactor checks into more maintainable code

Makerbot

• [x] Use same GCode buffer
• [x] Convert into GPX later (before sending it to printer) Converting GCode to GPX later should also increase the speed in which the WiFi-Box can receive GCode.

[woutgg]

As visible in the checklist, this ticket has been implemented. A new issue regarding stopping the makerbot popped up however. As soon as that is fixed, this ticket can be closed.

[woutgg]

The print3d server now allows for checking gcode chunk order. Client-side code however does not send it as it seems less important now, with other improvements (mainly gcode transactions).

[peteruithoven]

Using a stop print command p3d -k currently crashes print3d. Using a stop print command with gcode does work p3d -K 'M137'.

[woutgg]

The crash has been fixed in https://github.com/Doodle3D/print3d/commit/6530cca55370874a5e387933b3bed0a5c927c12e.

[peteruithoven]

I can reproduce the stop issue using the command line interface

p3d -f /Users/Peter/Projects/Peter\ Uithoven/Doodle3D/dev/makerbot/cube/cube.gcode
p3d -K $'M73 P100\nG92 A0 B0\nM18 A B\nG1 Z155 F900\nG162 X Y F2000\nM18 X Y Z\nM72 P1\nM137'

It stops executing the cube.gcode, but it doesn't execute any of the specified end code and it sticks in the stopping state.

[woutgg]

Selectively removing commands which control build state etc. lead to the following end code which works (for r2x):

M73 P100
G92 A0 B0 ;reset extruder position to prevent retraction
M18 A B(Turn off A and B Steppers)
G1 Z155 F900
G162 X Y F2000
M18 X Y Z(Turn off steppers after a build)
{if heatedBed}M140 S{preheatBedTemp} T0
M104 S{preheatTemp} T0
M73 P100 (end  build progress )
;M72 P1  ( Play Ta-Da song )
;M137 (build end notification)

So at first it seems that M72 P1 and M137 are the culprit. However, testing this again lead to a failure anyway.

Strangely enough, letting a print finish with 'regular' end code now works fine (at least a few times...) whereas it seemed to have the same issue before.

Perhaps the solution could be to just use Sailfish as printer firmware? One thing all this does seem to prove is that the issue lies with the printer/gcode and not with the modifications to the makerbot driver. So can we close this issue?

A final word: commenting out all four mb control commands worked fine at least 5 times. Acceptable as a temporary solution?

[peteruithoven]

@woutgg It's been quite a while, but do you remember why you mention "four mb commands"? Since you ony commented out two comments in the end gcode you added. Did you include the M73 commands?

[woutgg]

I do not remember, but as I understand the issue has now been resolved.