When a new print is started the screen should go from the "Build finished" screen to the minitor / printing mode. But it seems as if GPX is not generating the right x3g code.
Using GPS's s3g-decompiler.py I tried to decompile the Makerbot X3G and GPX X3G output. I used our x3g-output-behaviour branch for this.
GPX's decompiled X3G:
0: [153] Start build, steps 0: cube.gcode
1: [134] Change extruder 0
2: [150] Set build percent 0%, ignore 0
3: [132] Home maximum on 3, feedrate 479, timeout 20 s
4: [131] Home minimum on 4, feedrate 167, timeout 20 s
5: [140] Set extended position as (0,0,-2000,0,0)
6: [155] Move to (0,0,0,0,0) dda_rate: 5999 (relative: 18) distance: 5.000000 feedrateX64: 960
7: [131] Home minimum on 4, feedrate 1500, timeout 20 s
8: [144] Recall home position for axes 31
9: [140] Set extended position as (13463,6377,0,0,0)
...
154: [137] Enable/disable steppers 18
155: [155] Move to (2223,2224,62000,0,0) dda_rate: 6000 (relative: 18) distance: 154.500000 feedrateX64: 960
156: [132] Home maximum on 3, feedrate 479, timeout 20 s
157: [137] Enable/disable steppers 7
158: [136] Extruder(0) [3] set target temperature = 0
159: [150] Set build percent 100%, ignore 0
160: [149] Display message, options 0x2 at 0,0 timeout 5
'We <3 Making Things!'
161: [151] Queue song 1
162: [154] End build, flags 0x0
Makerbot's decompiled X3G:
0: [157] Stream version 1.0 (0 0 45077 0 0 0 0)
1: [153] Start build, steps 0: cube
2: [150] Set build percent 0%, ignore 0
3: [132] Home maximum on 3, feedrate 338, timeout 20 s
4: [131] Home minimum on 4, feedrate 166, timeout 20 s
5: [140] Set extended position as (0,0,-2000,0,0)
6: [155] Move to (0,0,0,0,0) dda_rate: 6000 (relative: 0) distance: 5.000000 feedrateX64: 960
7: [131] Home minimum on 4, feedrate 1500, timeout 20 s
8: [144] Recall home position for axes 31
9: [140] Set extended position as (13463,6377,0,0,0)
...
156: [137] Enable/disable steppers 18
157: [155] Move to (2222,2224,62000,37,0) dda_rate: 6000 (relative: 0) distance: 154.500000 feedrateX64: 960
158: [132] Home maximum on 3, feedrate 338, timeout 20 s
159: [137] Enable/disable steppers 7
160: [136] Extruder(0) [3] set target temperature = 0
161: [150] Set build percent 100%, ignore 0
162: [149] Display message, options 0x2 at 0,0 timeout 5
'We <3 Making Things!)
'
163: [151] Queue song 1
164: [154] End build, flags 0x0
Main differences:
Makerware starts with a Stream version [157] Stream version 1.0 (0 0 45077 0 0 0 0)
Makerware seems to add a ")" and newline after the Display message string.
I also tried changing the GCODE flavor to "Reprap" and "Makerbot/ReplicatorG", but looking at the decompiled output they don't differ.
There don't seem to be any explicit clear / finish / reset gcode commands. Beside M70 or M71 (which makes users press a button) there are no commands that display something on the screen.
M70
Using M70 can fix the issue that "Build finished!" sticks, but it doesn't seem to work properly, when it's added (with a proper 20 characters) it's own message isn't shown and the next commands are delayed.
Sometimes sending a second M70 displayed the message of the second M70.
M70 tests:
Using M70 P5 () causes the display to stick at Build finished! again.
Using M70 P1 (We <3 Making Things!) clears the display but delays the next print. (the P parameter should specify the time the message should be displayed)
Using M70 P1 (W) clears the display but delays the next print.
Using M70 (We <3 Making Things!) clears the display but delays the next print.
Putting M70 (We <3 Making Things!) clears the display but delays the next print.
According to the gpx code the maxLength for the message is 20 characters and We <3 Making Things! is exactly 20 characters, so that shouldn't be a problem
When you don't send 20 the buffer doesn't clear.
Sending 20 characters M70 P3 (xxxxxxxxxxxxxxxxxxxx):
When a new print is started the screen should go from the "Build finished" screen to the minitor / printing mode. But it seems as if GPX is not generating the right x3g code.
Wouter started tweaking our GPX fork to align it's output to the output of Makerware. https://github.com/Doodle3D/GPX/commit/7be25d74e183013188642dd2568c68a35b85e1ff
Using GPS's s3g-decompiler.py I tried to decompile the Makerbot X3G and GPX X3G output. I used our
x3g-output-behaviourbranch for this. GPX's decompiled X3G:Makerbot's decompiled X3G:
Main differences:
[157] Stream version 1.0 (0 0 45077 0 0 0 0)I also tried changing the GCODE flavor to "Reprap" and "Makerbot/ReplicatorG", but looking at the decompiled output they don't differ.
There don't seem to be any explicit clear / finish / reset gcode commands. Beside M70 or M71 (which makes users press a button) there are no commands that display something on the screen.
M70 Using M70 can fix the issue that "Build finished!" sticks, but it doesn't seem to work properly, when it's added (with a proper 20 characters) it's own message isn't shown and the next commands are delayed. Sometimes sending a second M70 displayed the message of the second M70. M70 tests: Using M70 P5 () causes the display to stick at Build finished! again. Using M70 P1 (We <3 Making Things!) clears the display but delays the next print. (the P parameter should specify the time the message should be displayed) Using M70 P1 (W) clears the display but delays the next print. Using M70 (We <3 Making Things!) clears the display but delays the next print. Putting M70 (We <3 Making Things!) clears the display but delays the next print.
According to the gpx code the maxLength for the message is 20 characters and We <3 Making Things! is exactly 20 characters, so that shouldn't be a problem
When you don't send 20 the buffer doesn't clear. Sending 20 characters
M70 P3 (xxxxxxxxxxxxxxxxxxxx):Sending fewer
M70 P3 (xxxx):For now we removed the M70 since the delay is a bigger issue than the "Build finished!" sticking.