Printer stops at 98%

[Justin Leone]

This is the oddest problem I've run into so far, and it has me completely stumped.  About 98% of the way through a 5 hour print, the printer (a Replicator 2 running stock firmware) will simply stop.  It stays heated and gives no error message.  Doing a cold pause will move the build surface down and move the print head to the rest location, and resuming brings everything back to the correct position, but it remains paused.

Printing other objects still works fine, and this isn't the first time I've used this .s3g file.  Re-slicing the object using slightly different settings gives almost identical results, but it pauses at 95% instead of 98%.

Has anyone seen anything like this?

[Jimc]

just guessing but sounds like mesh errors

[Joseph Chiu]

There's a remote chance it is your SD card, although the way you decribe how it enters pause and resumes, it might not be.  I have experienced a problem where the SD card partly worked, but then sent the printer "off to nowhere" (well, more accurately, it sent it off to practically infinity, causing the carriage to crash against the side of the printer).  

--
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.

[Justin Leone]

It can't be mesh errors.  For one, I've already used this exact same .s3g file to make successful prints.  And secondly, re-slicing a new .s3g file from the same object caused it to pause at a slightly different layer (though still one that's infuriatingly close to the top of the object.

[Justin Leone]

That sounds vaguely plausible.  I've had some issues with the SD card (or the reader), in which it will give a "no SD card found" error even when the card is in the machine.  Although it's odd that it's only with this particular object, even when I reslice and give the .s3g file a different name.

[Dan Newman]

On 09/12/2013, 8:58 PM, Justin Leone wrote:
> That sounds vaguely plausible. I've had some issues with the SD card (or
> the reader), in which it will give a "no SD card found" error even when the
> card is in the machine.

I've seen a couple of things cause this

1. Broken or impeded SD "card detect" switch. This is particularly possible
on a Rep 2 or 2X as it's easy for plastic to fall into the SD card slot and
prevent that contact/switch from operating.

2. A combination of a borderline SD card and MBI's borderline (poorly designed)
SD card electronics. MBI has done some work on this in their latest rev H
MightyBoard (found in recent 2X and 2's). Basically, there's signalling
problems and the firmware cannot correctly communicate with the card. If the
problem is sufficiently borderline, then the problem can come and go.

> Although it's odd that it's only with this
> particular object, even when I reslice and give the .s3g file a different
> name.

How are you putting the s3g file onto the card? MBI hasn't always been that
good about writing robust code which does error checking and handling. RepG
has always had problems in which writing directly to the SD card, it would
ignore write errors. Net, net, you might think that it successfully overwrote
a file on the card when it either didn't (left the old file), or it appended
your new file to the end of the old file, or other similar problems. We've
seen a couple of reports of people using MakerWare reporting similar issues
and concluding, like folks have with RepG, that it's safest to write the SD
card file to the hard drive (which has fewer errors) and then copy that file
to the SD card trusting the operating system to correctly handle SD card
write errors.

Sooo, if you're writing the file directly to SD card you may want to try
changing that behavior.

Finally, know that MBI's firmware does absolutely no error checking of
data read from the SD card. So, it could be that for whatever reason you're
getting a data read error. Sailfish can perform error checking of all
data reads and write to the SD card. That functionality is off by default
but can be enabled from the LCD display (Utilities > General Settings).
If there is a read error, Sailfish will attempt to re-read the data. It
will try up to 5 times to read the data. If it fails all 5 times for a
given data block, then it cancels the print and informs you of the error.

Dan

[Justin Leone]

Thanks for all the info.  I generally (including this time), write to the hard drive, then transfer it from there (usually over the network via the laptop which lives by the printer) to the SD card.  I might try deleting everything else from the card and reslicing the file again, and try upgrading to sailfish (which I've always meant to do anyway, but keep putting off).  Even if I still have a problem, it sounds like Sailfish might at least give me an error that confirms it's an SD card issue, and not the work of vengeful ghosts intent on wasting my time and filament, which was my previous theory.

[Dan Newman]

So you're sending the file over the network to the SD card somehow? Or sending
it to an intermediate computer and then writing it from that computer to the SD
card? I ask because another possibility is that the last block or two (512 byte
blocks) are not being committed to the SD card and so the print just ends because
the final print data isn't there on the card. This could happen if it's a WiFi
SD card and for some reason some final commit is not occurring on the file write.
Or it could happen if the SD card is being removed from the intermediate computer
before all the data is flushed to the card and sync'd.

Dan

[Justin Leone]

It's using the SD card reader on the laptop, but reading from a drive on another computer.  I haven't had this issue on any of the other hundreds of .s3g files I've used, so it's weird that I'd get almost (but not exactly) the same problem twice on 2 different slices of the same object which has printed successfully in the past (albeit having been recopied to the sdcard since then).

I've looked at the gcode in a viewer and it seems to check out, and made sure the .s3g on the card is the exact same size as the one on the hard drive.

[Justin Leone]

Also, it's a fairly large .s3g (over 15 megs), if that matters.

[Dan Newman]

On 10/12/2013, 10:54 AM, Justin Leone wrote:
> Also, it's a fairly large .s3g (over 15 megs), if that matters.

Only if it exceeded 2GB might there be an issue.

Dan

[Gerhard Ho]

>Printer stops at 98%

 

I have also the same problem and have been recognized for the second time.

I got the MakerBot Replicator2 new and printed only 5 items until now and 2 stopped at 98%. He stopped first in the profile and the second time he went back.

But I don't think it is the SD card. Since it is the original enclosed map. And I couldn't change any settings (For example pause, change filament,...) only "cancel build".

[big_red_frog]

Checking the file size is exactly the same is not really a good indicator.

I have previously had semi repeatable symptoms that were the same, where the printing just stopped, though not related to a specific file as in your case ( though it may be a case of specific file size range, memory location etc...)

I would advise checking the files between the SD card and the hard drive version for bit exact. I used VbinDiff as it was just the first trustworthy I found when I needed it.

In my case, there would be a few seemingly random differences between the two files and the assumption is this was generating command strings that were not error trapped or resolvable, so left in deadlock. I traced it to the old SD card reader running on a hub, and now run a new SD card thumbdrive sized reader direct in the USB port. Although my issue was specific to the reader / hub, same symptoms could apply to various other failure modes. I have never had such a failure since, running the same SD cards, and I am now 1000+ hours on my rep2.

Have you seen this with more than one SD card?

When checking for binary exactness, please remove and reinsert the SD card between write and verify cycles.

Of course 98% failure on a 5 hour print becomes a very high cost to binary chop, if its the only indicator :-/

Meanwhile, anyone have a go to source for 2 Gig SD cards? They are not so off the shelf now, and I think it is time to stock up...

[big_red_frog]

Sanity check.

Why are you quoting .s3g, is this a typo, .x3g has been the supported file format for some time.

I would expect .s3g to be deprecated.

Are you running a current tool chain end to end?

[Daniel Quaroni]

On Thursday, January 16, 2014 12:25:17 PM UTC-5, big_red_frog wrote:

Meanwhile, anyone have a go to source for 2 Gig SD cards? They are not so off the shelf now, and I think it is time to stock up...

Amazon has them.

[Drew in Sunny Florida]

Yes.  I had my 2X crash every time at 98% when it was new.  It was the SD card.  Just throw it away and get a 1 or 2 gig new one from wal-mart for like $4.  I did not suspect my SD card either and chased gremlins for weeks.  MBsupport did eventually send me a replacement card after I got a few spares and explained the fix to them.  Note:  for reasons unknown to me, 2 gig is the largest SD card it will allow.  Hope it helps

 

On Monday, December 9, 2013 11:27:27 PM UTC-5, Justin Leone wrote:

[Daniel Quaroni]

2 gig is the max size for FAT16, which is the file system supported by the rep2 line.

[Jetguy]

Note: for reasons unknown to me, 2 gig is the largest SD card it will allow

 

That is because of the version of firmware you are running. The firmware has to read the file system on the card. Because MakerBot chose to save pennies and use the smallest and nearly end of life atmega1280 instead of the pin compatible 2560, the firmware takes up all the possible memory space inside the processor. The open source code that actually reads the SD card is limited to 2GB cards.

 

On the other hand, Sailfish firmware deleted a bunch of useless features found in stock firmware making enough space to put a proper SDHC SD card reader code into the firmware and that firmware can read larger than 2GB cards.

 

And while on the subject of SD card corruption, the same stock firmware code has a flaw that every time it accesses the SD card, the firmware writes to the SD card and this can be the cause of the very corruption you are experiencing.

 

So what I'm implying or maybe even flat ouright saying, here is a fine example of jacked up stock firmware causing yet another problem. people don't liek it when I tell a new user to dump stock firmware and move to Sailfish but right here in front of us is a compelling reason.

 

On Thursday, January 16, 2014 1:05:02 PM UTC-5, Drew in Sunny Florida wrote:

[big_red_frog]

Its scary how much you have to dig through amazon ( amazon.ca in my case ) to find reputable supply, local ( in country ) stock, and acceptable postage.

There were some stocked by amazon.ca in 2 packs at about 15 dollars with free delivery once I ordered 2 x 2 that will likely arrive some time this year.

Got really burnt once buying bose headphones on amazon, didn't realize it had become ebay! But that's another story...

[Dan Newman]

> Meanwhile, anyone have a go to source for 2 Gig SD cards? They are not so
> off the shelf now, and I think it is time to stock up...

Or run a firmware which

1. Supports SDHC & FAT-32
2. Supports SD error checking and correction
3. Fixes the longstanding bug in the SD card library by which the SD card file
header is being written each time the file is closed. A signal integrity
issue can cause the file header to be trashed, thus corrupting the file.
And what is it trying to write to the header? The file length. Writing
that wrong later prematurely truncates the file.

Dan

[Dan Newman]

On 16/01/2014, 10:05 AM, Drew in Sunny Florida wrote:
> Yes. I had my 2X crash every time at 98% when it was new. It was the SD
> card. Just throw it away and get a 1 or 2 gig new one from wal-mart for
> like $4. I did not suspect my SD card either and chased gremlins for
> weeks. MBsupport did eventually send me a replacement card after I got a
> few spares and explained the fix to them. Note: for reasons unknown to
> me, 2 gig is the largest SD card it will allow. Hope it helps

MBI's firmware only supports FAT-16 and SDSC, both which are limited
to 2GB. Sailfish supports FAT-32, SDHC, SD error correction and
detection, and is up to date with fixes to the underlying SD card library.
(MBI pulled a version of it back in 2009 or 2010 but didn't then follow
updates and bug fixes.)

Complete list of differences between Sailfish vs. MBI's stock firmware is at

http://jettyfirmware.yolasite.com/features.php

Install and setup hosted at Makerbot's site,

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

Dan

[big_red_frog]

This was too funny not to share.

I ordered my 2 x 2 pack x 2 gig SD cards from Amazon on free delivery. They turned up today, which was real quick.

But look at the size of the box that one of those 2 packs turned up in! And whats in the other box? You guessed it, the other 2 pack!

Well, at least they arrived on the same truck...

[Big-E]

Every print on my Rep2 ends at 98%, never 100%. It's a bug in the firmware. The object always prints completely, but the machine reports the job at 98% when it's actually 100%

[big_red_frog]

i have never seen this on my rep 2. It appears to progress to 100% on every job that I have watched complete. Which is a few.

[Dan Newman]

On 17/01/2014, 8:04 PM, Big-E wrote:
> Every print on my Rep2 ends at 98%, never 100%. It's a bug in the firmware.

First, keep in mind that the percentages to display come from the gcode,

M73 Pnn (display progress)

The "nn" is the percentage to display. MBI's firmware won't display 100%
since they didn't reserve space for it in the LCD display. So their
code which takes the M73 Pnn and sets the percentage in the firmware
intentionally ignores any value which equals or exceeds 100. Not really
a bug -- the code is doing what they intended. It's just not very friendly
is all.

Sailfish will actually display both 0% and 100%. So, if anyone is annoyed
by the behavior sufficiently, then I suppose they can upgrade to Sailfish.
However, the 100% would only be displayed briefly since at the end of the
print, Sailfish puts up the build completed screen

Print time: hh:mm
Filament used: xxxx
Print Another?
*Return to Main Menu

Which is nice as it lets you print again if you were printing from SD card.

Now, a good way to tell if the print really finished is if the XY carriage
is homed back to the rear, right and if the platform was lowered. Note,
however, that that is actually part of your final gcode. If it doesn't
happen, it may mean that your gcode lacked those commands. Or it may
mean that the print failed....

Dan

[big_red_frog]

I should reword.

I have never seen an anomalous percentage count.

I have watched many progress through 99% but hadn't noticed it didn't show 100 at completion, but then that would and should only be at the very final movement.

By then I am probably too busy pulling the plate and working out new ways to cut myself with a paint scraper.

[Eighty]

>By then I am probably too busy pulling the
>plate and working out new ways to cut myself
>with a paint scraper.

LOL! I hear that. You should try glass. 5 minutes in the freezer, and pieces literally fall off with a gentle nudge of the hand.

[antho...@gmail.com]

Have glass ready to go, just waiting for a critical fail of my stock plate...

Sent from my BlackBerry 10 smartphone on the Rogers network.
  Original Message  
From: Eighty
Sent: Saturday, January 18, 2014 9:02 AM
To: make...@googlegroups.com
Reply To: make...@googlegroups.com
Subject: Re: [MakerBot] Re: Printer stops at 98%

--
You received this message because you are subscribed to a topic in the Google Groups "MakerBot Operators" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/makerbot/pYj86vuCDQk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to makerbot+u...@googlegroups.com.

[Joseph Chiu]

And speaking of SD Card failures...

This happened today 15 hours into a print on a card that has been reliable to date. This job is a huge job - the .x3g is more than 100MB long...

@$#=@&#=+...

On Dec 9, 2013 8:42 PM, "Joseph Chiu" <joe...@joechiu.com> wrote:

There's a remote chance it is your SD card, although the way you decribe how it enters pause and resumes, it might not be.  I have experienced a problem where the SD card partly worked, but then sent the printer "off to nowhere" (well, more accurately, it sent it off to practically infinity, causing the carriage to crash against the side of the printer).  

On Mon, Dec 9, 2013 at 8:27 PM, Justin Leone <itera...@gmail.com> wrote:

This is the oddest problem I've run into so far, and it has me completely stumped.  About 98% of the way through a 5 hour print, the printer (a Replicator 2 running stock firmware) will simply stop.  It stays heated and gives no error message.  Doing a cold pause will move the build surface down and move the print head to the rest location, and resuming brings everything back to the correct position, but it remains paused.

Printing other objects still works fine, and this isn't the first time I've used this .s3g file.  Re-slicing the object using slightly different settings gives almost identical results, but it pauses at 95% instead of 98%.

Has anyone seen anything like this?

--

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.

[Dan Newman]

On 18/01/2014, 2:56 PM, Joseph Chiu wrote:
> And speaking of SD Card failures...
>
> This happened today 15 hours into a print on a card that has been reliable
> to date. This job is a huge job - the .x3g is more than 100MB long...

I guess that's what you get for not running Sailfish ;) [Sailfish doesn't
have that cutesy error message.]

Dan

[Dan Newman]

On 18/01/2014, 3:03 PM, Dan Newman wrote:
> On 18/01/2014, 2:56 PM, Joseph Chiu wrote:
>> And speaking of SD Card failures...
>>
>> This happened today 15 hours into a print on a card that has been reliable
>> to date. This job is a huge job - the .x3g is more than 100MB long...
>
> I guess that's what you get for not running Sailfish ;)

Or at least not keeping up-to-date: Sailfish used to have that message which
came from MBI. But when we put a lot of effort into cleaning up the SD
card support, we removed it.

Dan

[Joseph Chiu]

Guilty as charged! I have been meaning to go up to a more current version. But had not yet done so...

--
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+unsubscribe@googlegroups.com.

[Dan Newman]

On 18/01/2014, 3:07 PM, Joseph Chiu wrote:
> Guilty as charged! I have been meaning to go up to a more current version.
> But had not yet done so...

I would regenerate the s3g/x3g file and rewrite it to the SD card (after
first deleting the old one off of the card).

1. The file may be corrupt from the libsd bug whereby the darn file header
was always rewritten, even when the file was just opened for reading.

2. You don't need to remove the old file from the SD card if you have the
s3g first written to your local hdd and then use the OS to copy it to the
SD card. After all, the OS likely pays attention to little details like
file create, file write, and file close errors unlike some of MBI's code. (This
is why you can end up with your file not being written to the SD card or
written but wrong, etc. when you let RepG code write directly to the SD
card. MakerWare may be much better about this -- I don't know myself since
I've been Pavlovian-trained to go the slicer -> HDD -> SD card route since
the Cupcake days.)

Dan

[Joseph Chiu]

... and fixed!  I now have large-capacity SD card support, and SD error detection...  As usual, the reset timing dance took a few tries, but the process was otherwise painless.  I just am so reluctant to touch "production" setups...  But it's all good!  :)

[Dan Newman]

On 20/01/2014, 8:58 PM, Joseph Chiu wrote:
> ... and fixed! I now have large-capacity SD card support, and SD error
> detection... As usual, the reset timing dance took a few tries, but the
> process was otherwise painless. I just am so reluctant to touch
> "production" setups... But it's all good! :)

... And I believe that I have told you how to get auto-reset on a Rep 1 ...

Dan

[Joseph Chiu]

Yes, thanks.  I still need to break out the iron to put C20 in (0.1uf).

Dan

[Dan Newman]

On 20/01/2014, 10:08 PM, Joseph Chiu wrote:
> Yes, thanks. I still need to break out the iron to put C20 in (0.1uf).

Followed by more up-to-date 8u2 firmware. I can resend if you need it.

Dan

[Bryon Miller]

I have had something similar to this happen to me.  It was on a 2.5 hour print and it stopped at around 38%.  In my case it was the X Cable.  I had just replaced it, but there was a short somewhere in the replacement wire.  When I connected the extension wire (USE THIS if you get replacement wires, the extension wire is a high flex cable) the print head would go crazy and zip in zig zags all over the place.  I had another set of x cables on hand (I keep one extra of EVERYTHING on hand because of what I read on these forums).  I connected them, routed the wire so it doesn't go above the motor and route back down over that hard angle behind the pin.  I went ghetto style and used the clips in the case to fold the slack over itself several times, then I used Packaging tape, that's right this is NOT BLING.  The Tape holds the wire to the floor of the printer by the right panel, it is also taped to the side of that panel, and the extension wire is connected going straight up to the motor.  This way, if there is a failure again, it's on the extension wire since the harness wire is not moving at all it won't get damaged.

The exact same problem you are describing was caused by a failing x cable on my machine, that could be the problem.  The cable itself costs $15.  Makerbot charges you $11 to send an item that weighs less than 1 oz via Priority mail when they could use first class mail for $1.69.  I wonder how many of those decisions have inflated the costs of these machines.....  They don't even use flat rate priority, they pay MORE and use uline envelopes and zoned priority mail.  Idiots.....

[Bryon Miller]

One more thing you could try.  Are you using the original SD card that came with your bot?  I bought a Sandisc sd card for $5.  It's much faster and more reliable than the one that came with my $2,000 computer.  The one that came with my printer seems like a counterfeit from eBay, but who would bother on a lousy 2 gb card that is worth less than the housing it is sent in?  It probably really comes down to the class they used.  I'm sure my new card is class 10 and the original one is the lowest class possible.

[Bryon Miller]

Update your firmware so you can read 16 gb cards.

[Bryon Miller]

Buy directly from Amazon, make sure you are not buying from a 3rd party seller and you should be just fine.  Use Prime to get free shipping, buy you're an amazon customer so you probably already know.  Anyhow, I'd just go to a small mom and pop type computer shop if they even exist anymore in your town.  That's where I found a 2 gb sdcard for less than a mcdonalds value meal.

[Bryon Miller]

LOL, you DID order from Amazon Prime, no 3rd party seller would do that!  I get alot of stuff from them like that.

[Andrew Aurigema]

My original MakerBot 1 gig card failed ( from day one )  and the replacement card they sent failed also.  $4 Sandisc 2 gig cards worked perfect and have not missed a beat in hundreds of hours now.  Really, who puts their name on a junk grade SD card and ships it with a $3000 printer.  Not good branding to say the least. 

--
You received this message because you are subscribed to a topic in the Google Groups "MakerBot Operators" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/makerbot/pYj86vuCDQk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to makerbot+u...@googlegroups.com.