Simplify3D Sliced this file and it will not print...

[Bryon Miller]

I was wondering if someone could look at this gcode produced by simplify3d and see why the converted x3g file just stops?

I will start the print, the extruder homes in to the heating position, the lights stay red while it heats, but the display screen goes back to normal as though the printer isn't doing anything, I can pick "Print from SD Card" and all the other options while the bot appears to still be preparing for the print.  Then it starts, goes for about 5 seconds and just stops.  I have to jog the plate down because I can't even cancel since the option is no longer on the display screen, the printer doesn't even know it's trying to print, so I can't cancel it.

Dan Newman said this in another thread:

"Since acceleration is on by default, a lone M126 is superfluous and can
be omitted entirely.  And if it were to be translated to some unknown s3g/x3g
command, then yes the bot would stop dead since that is the behavior MBI
decided for unknown s3g commands. "

Is it possible that there is a code in the conversion that MBI doesn't recognize so what I am seeing is the bot stopping dead since that's the way MBI designed it?

Here are the gcode and x3g files:

[Scottbee]

Sound like the same problem that I had when I stumbled upon the GPX "issue" with long file names.

[Dan Newman]

On 07/02/2014, 8:24 AM, Bryon Miller wrote:
> I was wondering if someone could look at this gcode produced by simplify3d
> and see why the converted x3g file just stops?

The x3g looks fine (at least for Sailfish). After the print is 3% done,
a M126 command is sent to turn on the print cooling fan. I ran your .x3g
file on my Rep 2 with Sailfish 7.6 and it runs fine: I let it go until 5%
and then stopped it manually. Was it dying later than that?

> Dan Newman said this in another thread:
>
> "Since acceleration is on by default, a lone M126 is superfluous and can
> be omitted entirely. And if it were to be translated to some unknown
> s3g/x3g
> command, then yes the bot would stop dead since that is the behavior MBI
> decided for unknown s3g commands. "

And I retracted that: I was remembering the older usage from the Jetty Firmware
in which M126/127 was used to control acceleration. When we changed the name
to Sailfish, we also changed to using M321/322 for acceleration control and
M126/M127 returned to being valve open/closed. (Jetty Firmware was on Gen 3 & Gen 4
electronics where it was okay to usurp M126/127.)

> Is it possible that there is a code in the conversion that MBI doesn't
> recognize so what I am seeing is the bot stopping dead since that's the way
> MBI designed it?

Well, the x3g looked fine for me assuming you are printing with Sailfish.

Dan

[Bryon Miller]

That must be the problem, I just recently upgraded the firmware from 7.2 to 7.5.  I'm not using Salifish firmware yet, I just need to get repg again and I'll update the firmware.

Thank you so much

[Fozzie]

I have a ticket open with S3D right now because I am experiencing EXACTLY the same behavior. No resolution yet.

[Bryon Miller]

If it worked on Dan's machine and it does exactly what mine is doing, it's probably the firmware.  He's using Salifish 7.6 firmware, I'm on Makerware 7.5 firmware. 

I was given this link the other day to update to salifish 7.6

http://www.makerbot.com/sailfish/install/

[Scottbee]

Just out of curiosity, have your tried running the print from S3D via USB?  From the Machine Control Panel command window I was able to see exactly when and where things went south.

[Dan Newman]

On 07/02/2014, 9:12 AM, Bryon Miller wrote:
> That must be the problem, I just recently upgraded the firmware from 7.2 to
> 7.5. I'm not using Salifish firmware yet, I just need to get repg again
> and I'll update the firmware.

When does the print die? Around 3% when the fan tries to turn on or sooner?
I ask since the x3g is also sending messages to the LCD to display. And I
know that MBI had some bugs there as we found and fixed them in Sailfish and
alerted MBI to them as well. I don't know offhand when (or if) MBI incorporated
those changes in their code. I see a couple of those bugs still there in their
latest sources, so it's clear they didn't adopt all the fixes. However, the
unfixed bug I noticed shouldn't have been triggered by your .x3g.

Dan

This buffer overrun bug still exists in MBI's firmware in a couple of code
locations associated with displaying messages on the LCD display.

char message[BUF_SIZE];
...

void MessageScreen::addMessage(CircularBuffer& buf) {
char c = buf.pop();
while (c != '\0' && cursor < BUF_SIZE && buf.getLength() > 0) {
message[cursor++] = c;
c = buf.pop();
}
// ensure that message is always null-terminated
if (cursor == BUF_SIZE-1) {
message[BUF_SIZE-1] = '\0';
} else {
message[cursor] = '\0';
}
}

In the above, the while loop can run with cursor == BUF_SIZE - 1. When that
happens, cursor gets incremented by 1 and becomes cursor == BUF_SIZE. Then,
the if () test after the while loop fails since cursor no longer equals BUF_SIZE - 1.
As such, the NUL terminator is placed in message[BUF_SIZE] thus creating
a buffer overrun and corrupting the stack. That can cause the print to just
up and die.

[Scottbee]

Dan... is that the same buffer issue reported on the S3D forum?

Just wanted to make everyone aware of a recent bug that was found in the current version of GPX that ships with Simplify3D. This is only a bug with the GPX plugin, but it has the potential to cause builds on MakerBot or Sailfish printers to halt if the conditions are right. 

The bug is related to buffer overflows for long filenames or extremely long comments in the .gcode file. If you are printing over USB, you might notice an extremely long command sent to the printer with no response. For an example of this communication, see below:

READ: d50181d2
SENT: d50688000302dc0099
READ: d50181d2
SENT: d50688010302c300a0
READ: d50181d2
SENT: d50289085f
READ: d50181d2
SENT: d52c99000000004c4544207374726970206c69676874206d6f756e74696e6720627261636b65742e67636f646500fc <----- this is the problematic command


If this happens to you, there are 2 simple things you can do. First, make sure you are using a filename that is less than 30 characters long. If that still doesn't work, you can try removing the header section from the top of your .gcode file and then convert the modified file to .x3g using GPX. For example, here is the command you could run after removing the semicolon header lines from the top of your .gcode file.

"C:\Program Files\Simplify3D-2.0.1\gpx.exe" -p -m r2 "C:\path\to\test.gcode"

The GPX authors are already working on a fix, so we will be sure to implement it ASAP!

[Dan Newman]

On 07/02/2014, 9:27 AM, Scottbee wrote:
> Dan... is that the same buffer issue reported on the S3D forum?

Different bug: that bug was in GPX. GPX was creating s3g packets
which exceed the s3g payload size. The bugs I was referring to
today can be triggered by valid s3g. (Indeed, I believe it was
Emmett who originally stumbled into the bug which Jetty and I then
analyzed and found a number of issues in the firmware which we
then fixed in Sailfish and sent a heads up to MBI about.)

Dan

[Bryon Miller]

I'll run it again after my current print is finished.  I can't see the percentage on the LCD because it goes back to the default menus while the bot is heating up.  I'll look closely to see if this is when it reaches 50 c and turns on the fan as to when the lcd fails.  After the LCD fails the print is still going, it heats up as expected, starts the print and lays down aprox 25 mm of plastic on the first line then just stops dead in its tracks.

[Dan Newman]

On 07/02/2014, 10:06 AM, Bryon Miller wrote:
> I'll run it again after my current print is finished. I can't see the
> percentage on the LCD because it goes back to the default menus while the
> bot is heating up. I'll look closely to see if this is when it reaches 50
> c and turns on the fan as to when the lcd fails.

I was referring to the print cooling fan which it turns on after starting
the print and getting some (all?) of the first layer finished. (I wasn't
watching too closely and since I had ABS in my printer but the HBP wasn't
heated, nothing was sticking anyway.) I was not referring to the heatsink
fan.

Dan

[Fozzie]

S3D asked me to take the gcode they generate and run it through Makerware to create the X3G and see if the problem goes away. I will try that tonight.

I agree with those who believe that this is a Makerware firmware only issue because those with Sailfish seem to be able to print the same X3G files just fine.

One very curious thing I noticed last night. I sliced an object with S3D and started to print. Everything was going fine but it wasn't sticking so I canceled the print (from the LCD display), applied some hairspray, and tried again. Same file and everything--it stopped cold just as Bryon described. Even resetting the bot didn't fix it. I had to end up refreshing the file on the SD card from my HDD and then it printed again. But here's the twist on that--before I did that I ran a diff utility on the two files and it said they were identical! WTH? I have heard about the bug in Makerware that has it do a write to the SD card and thought that might have something to do with it but diff said the files were the same. Curious!

[Joseph Chiu]

With marginal signal quality that is suspected with SD-card printing on these machines, it's possible for *some* blocks of data to transfer without errors and others not.  I have a SD card that I had a great time with for most of last year, but a few weeks ago had a SD card glitch failure...  I've since upgraded to Sailfish 7.6 and moved to a newer 4GB SDHC card - so far everything is good...

--
You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.
To unsubscribe from this group and stop receiving emails from it, send an email to makerbot+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Dan Newman]

On 07/02/2014, 11:42 AM, Joseph Chiu wrote:
> With marginal signal quality that is suspected with SD-card printing on
> these machines, it's possible for *some* blocks of data to transfer without
> errors and others not. I have a SD card that I had a great time with for
> most of last year, but a few weeks ago had a SD card glitch failure...
> I've since upgraded to Sailfish 7.6 and moved to a newer 4GB SDHC card -
> so far everything is good...

And, worse comes to worse, you can enable SD card error detection and
suppport. However, my experience is that it only helps a little: if
the electronics or card are acting up, it's going to toss up enough
bad reads that even with error detection and re-reads, the firmware
will give up. (The firmware only retries 5 times for a given data
block.)

Dan

[Jamesarm97]

I'll try and duplicate it again on my machine tonight also. I had the same issue. I could also run the gcode if pasted in repg over usb but the x3g would not work so that is another issue I have to work out. I'll focus on the M126 since I noticed that also.

[Fozzie]

I was suspicious of the SD card at first, but extensive testing has convinced me it is NOT that. I have never had a failure on either card using Makerware, only with S3D's X3G files. It's too consistent. I strongly suspect there is an error being introduced into the X3G files during encoding that trips up the MBI firmware but not Sailfish. Also it always stops at the same place--for all of us experiencing it--which should make it easier for them to figure out and fix.

[Fozzie]

I attempted to have Makerware convert the S3D gcode into X3G code. It failed with the following error:

Fri Feb 07 17:33:53 2014

error in job info: {

   "conclusion" : "FAILED",

   "driver_name" : "s3g",

   "failure" : {

      "exception" : {

         "args" : "()",

         "errno" : "None",

         "filename" : "None",

         "message" : "UnrecognizedCommand: 90\nCommand: G90 ; use 

absolute coordinates\nLineNumber: 139",

         "name" : "UnrecognizedCommandError",

         "strerror" : "None",

         "winerror" : "None"

      }

   },

   "id" : 1,

   "machine_name" : null,

   "name" : "S3D_M",

   "port_name" : null,

   "profile_name" : "Replicator2",

   "progress" : {

      "name" : "verify",

      "progress" : 0

   },

   "state" : "STOPPED",

   "type" : "PRINT_TO_FILE_JOB"

} 

Not sure what this proves as we don't know what the GPX compiler does when it sees that code, but it is interesting. This code appears prior to the point where the print execution stops. I am attaching the original gcode.

I don't really know how to read gcode, but I believe the code execution stops somewhere in this block. I see the purge happen, and then it moves to where the build should start. It then draws a 10-20mm line and stops.

G4 P3500 ; purge nozzle

G1 X-140 Y-70 Z0.15 F1200 ; slow wipe

M103 ; stop extruder

G1 X-135 Y-65 Z0.5 F1200 ; lift

M73 P1 ;@body (notify GPX body has started)

; **** end of start.gcode ****

G1 E-1 F1200

; layer 1, Z = 0.25713

M135 T0

; tool H0.286 W0.4

G0 X-1.21 Y28.285 F9000

G0 Z0.257 F1200

G1 E1 F360

G1 X0.036 Y29.262 E0.0752 F2400

[Dan Newman]

On 07/02/2014, 9:12 AM, Bryon Miller wrote:

> That must be the problem, I just recently upgraded the firmware from 7.2 to
> 7.5. I'm not using Salifish firmware yet, I just need to get repg again
> and I'll update the firmware.

The underlying issue could be one of several things.

1. The gcode produced by s3d puts the annoyingly critical "M73 P0"
command after other commands of consequence. RepG and GPX do not
generate the s3g "build start notification" (BSN) command until
they see that "M73 P0". That could be problematic: the BSN
command causes the bot to set up some "start of printing" state.
It may be that MBI's firmware does something unwanted if the
BSN shows up after other significant commands. Presently,
it's not an issue with Sailfish.

Note that in MakerWare-style gcode, the M136 command triggers
generation of the s3g BSN command. That is a nice change: overloading
M73 P0 to do it was a hack MBI did when they introduced the s3g BSN
command.

Note also that MakerWare puts the M136 at the very start of the gcode
which ensures that the s3g BSN occurs before any other significant
s3g commands. RepG does likewise with the M73 P0 which results in the
s3g BSN. S3D should follow suit.

2. S3D is making use of m-codes to display informational text on the
LCD display. MBI's firmware has some known bugs in this area which
Sailfish does not (because we fixed them). It's possible that somehow
GPX is triggering those bugs when converting the gcode to s3g but
MakerWare is not. Seems unlikely, but it's been a long time since
I looked at those bugs in MBI's firmware: I don't recall what all
might trigger them.

3. MBI's code for processing "tool" commands, which includes M126 & M127
commands, is somewhat weak. The s3g tool commands include a byte
providing the length of the commands "sub payload". MBI's firmware
ignores that length and just assumes that it knows what the length
should be. If it is wrong, then the print will probably just stop
as the firmware then gets confused and cannot parse the rest of the
SD card file. Sailfish actually goes by the length -- it doesn't
assume that it knows everything. Sooo, it's conceivable that GPX
might generate a valid s3g "tool" command but MBI's firmware fumbles
it since it ignores the length field. However, the tool commands
I looked at -- namely the M126 commands -- all looked fine and
acceptable to even MBI's firmware.

Anyhow, I don't know what it might be that GPX is generating which
MBI's firmware dislikes.

Dan