Makerbot Firmware V7.5 Needed... NOT SAILFISH

[Scott Lichtsinn]

I have a printer here that keeps saying there is a firmware update when running Makerware, its currently running version 7.4, but when i tell it to update i always get an Unknown Error in Conveyor Service.  I installed the capacitor C20 like i did on my other printers and they all updated to 7.5 just fine, but this one refuses to.  So i was hoping to find a HEX file of the 7.5 version so i can just dump it in with my AVR Programmer instead and get past this update nag.

Makerware says its downloading the update but i cant find a file on the computer, so not sure if it stores the firmware file somewhere and i can grab it??

[tramalot]

http://www.makerbot.com/blog/2013/09/30/makerbot-makerware-2-3-release/   

maybe, if not i can pull it from shotbot

[Scott Booker]

You're probably not getting a lot of responses because many (most?) of us do not understand why you would want to install the 7.5 MBI firmware when it is riddled with well-documented bugs.  Sailfish 7.7 is a far superior product and I personally can't think of any good reason to run the MBI firmware.

[Jetguy]

You could figure out the URL where they are hosted on MakerBot's site by looking at the Sailfish update instructions.

 http://www.sailfishfirmware.com/doc/install-removing.html#x37-960006.6

Replicator-G ALSO has a folder in your user account called replicatorg and inside there is the firmware folder with the hex file you are looking for.

[adam paul]

Scott,

Are you trying to warranty your CTC?  I only ask as I have made contact with them, and in my communications, they told me that installing sailfish will void your warranty?

[tramalot]

7.5 is a sailfish,,, lol

[Scott Lichtsinn]

Because Sailfish SUCKS DONKEY BALLS...

I tried Sailfish on my other Makerbot Rep 1, tried shaking it to pieces, couldn't use Makerbot Desktop anymore had to use that ancient and ARCHAIC looking Replicator G (what is that crap program, looks like it was made in the early 80's on a tandy computer).

I design stuff, i save as STL, i open in Makerbot Desktop, i export to SD, i toss card in printer, i start print, i walk away.  I don't need 100 new features and having to use software that looks like an arcade game from the early 80's, i just want to stay stock.

If i seem HOSTILE, then yes, its because since i posted this i have received 37 emails stating i need to update to Sailfish and Replicator G... Rep G is a downgrade in UI by far, sorry, it just is.  LOL... I don't need to endlessly tweak stuff, just hit export and go print.

[Scott Lichtsinn]

I tried that, but the 7.5 that Replicator G tried to install just crashes the printer, i get a dead board with two solid lines on the LCD.  Then i have to fire up my AVR programmer and reload the boot image and the 7.4 firmware that i have backed up from the last printer i was able to recover from Sailfish hell.

The 7.5 that Rep G tries to put in is way different than the 7.5 thats running in my other two printers that Makerbot Desktop was able to upgrade.

I just had an idea though... Technically i could read the data out of one of my other printers with the AVR programmer and then dump that into this printer, problem solved.... Off to try that now.  Oh and Rep G seems to have messed up my laptop now, great, another adventure to fix later... UGHHHHHH

[Scott Lichtsinn]

Not sure how we got on the subject of the CTC here... The one i am working on for a friend right now is a Makerbot Rep 1.

My CTC has been purring like a kitten for many months now.  Printing as i type actually.

[Dan Newman]

On 28/03/2015 8:49 PM, Scott Lichtsinn wrote:
> I tried that, but the 7.5 that Replicator G tried to install just crashes
> the printer, i get a dead board with two solid lines on the LCD. Then i
> have to fire up my AVR programmer and reload the boot image and the 7.4
> firmware that i have backed up from the last printer i was able to recover
> from Sailfish hell.
>
> The 7.5 that Rep G tries to put in is way different than the 7.5 thats
> running in my other two printers that Makerbot Desktop was able to upgrade.

If they come from the same download URL, then they are the same .hex files.
MBI only released one 7.5 .hex file for the Rep 1 and one for the Rep 2 & 2X.
What you describe -- the solid lines on the LCD -- is what would happen
if you installed a Rep 1 .hex file on a Rep 2/2X or vice versa.

And, for the record, you do not need to use RepG with Sailfish other than to
install Sailfish. But you do need to read and follow directions.

Dan

[Dan Newman]

> I design stuff, i save as STL, i open in Makerbot Desktop, i export to SD,
> i toss card in printer, i start print, i walk away.

Funny how you posted on 17 March,

Ok so I installed the Makerbot Desktop 3.6, opened an STL, exported it to
SD Card and tried a print, the printer does the nozzle clearing line across
the front of the print bed, priming or whatever you want to call it, when it
reaches the end of printing that line the carriage acts like its stuck or
stalled and makes a horrendous grinding noise for a few seconds (I can take
a video if it helps) then it continues and prints the
item just fine.

You further explained how you had to fall back to MakerWare to get things working.

Problem is, MBI never looks back: I doubt they do any testing these days of
Desktop on anything other than their Gen 5 printers. If you like MakerWare,
then you're best off sticking to 2.4, the last version known to work acceptably
with the Rep 1, 2, and 2X.

And no, I'm not advocating for RepG. Me, I use Simplify3D, slic3r, and Cura.
(Which all work with Sailfish, as well as KISSlicer, MakerWare, Desktop,
and RepG.)

Dan

[Scott Lichtsinn]

Actually the two line problem can happen on any printer when there is a firmware problem, i know this first hand after recovering about a half dozen printers now that got corrupted during update installs by the owners.

Anyway, i just got out my AVR programmer, read the firmware from my Rep 1, then wrote that to this other Rep 1 and it booted right up and shows 7.5 and is printing some tests now, looking like everything works and the owner shouldn't see the update notice anymore which will make him happy.... FIXED

As for not using Rep G with Sailfish... Ok, but as everyone keeps saying on the forum to use Rep G and from first hand experience of trying to use Makerbot Desktop with Sailfish's latest version and watching my printer try to self destruct on the first print, i will stick with stock 7.5 firmware and MBD, works great, reliable after figuring out some Windows 8.1 issues that was randomly causing their latest version to crash, now its been smooth sailing again.

My Main Rep 1 that i own has just over 1700 hours on the clock, and its never seen Sailfish and its never had any major issues.  The Wanhao i have here was a battle for the first few 100 hours, but now its working fine, again no Sailfish.  When i tried running the Sailfish firmware on the CTC that i also have the poor thing tried to jump off the table and commit suicide, so i rolled it back to MB firmware and its much happier now.

[Scott Lichtsinn]

Yep, but i fixed that, so whats your point??

Running Makerbot Desktop latest version and firmware 7.5 now.  I found the problem, fixed it, and away we went.

The latest version of MBD on Windows 8.1 x64 was having issues writing the exported print to the SD Card, which was causing the corrupt moves when starting a print, figured out the problem, a little work, and its working sweet as sugar again.  Makerbot couldnt figure it out, nobody on the group could offer any suggestions other then roll back to old software or go to Sailfish and RepuGly, so i just stayed put and fixed it myself.

[Dan Newman]

On 28/03/2015 10:10 PM, Scott Lichtsinn wrote:
> Actually the two line problem can happen on any printer when there is a
> firmware problem, i know this first hand after recovering about a half
> dozen printers now that got corrupted during update installs by the owners.

It can happen for quite a few reasons actually. I've probably done over
a thousand firmware downloads to these printers and that's NOT an
exageration.

> As for not using Rep G with Sailfish... Ok, but as everyone keeps saying on
> the forum to use Rep G

... to install firmware.

I haven't seen anyone publicly recommend the use of RepG as a slicer
in this forum for a long time.

> My Main Rep 1 that i own has just over 1700 hours on the clock, and its
> never seen Sailfish and its never had any major issues. The Wanhao i have
> here was a battle for the first few 100 hours, but now its working fine,
> again no Sailfish. When i tried running the Sailfish firmware on the CTC
> that i also have the poor thing tried to jump off the table and commit
> suicide, so i rolled it back to MB firmware and its much happier now.

You do realize, of course, that any MBI firmware of version 7.x contains
Sailfish as its core. Sounds to me as though you've not followed the
directions for upgrading to Sailfish and you're seeing the consequences
of that. However, I will be the first to agree that people should use
what works best for them.

Dan

[Derry]

Dan,

Your patience level amazed me. More so than your coding capability.

Cheers

[Ryan Carlyle]

Scott, Sailfish is literally the same thing as Makerbot's 7.5, except with a LOT of bug fixes and a few additional features. They use the same motion control code. Makerbot adopted the core of Sailfish into their firmware ages ago, but doesn't keep up with bug fixes. Your options are quite literally "Makerbot's crummy version of Sailfish" and "Dan's well-maintained version of Sailfish." This is why everyone recommends using the genuine version.

The results you see will occur if you fail to follow the (very well-documented) Sailfish install instructions.

[Scott Booker]

+1000

[Bruce .]

+10000

Dan a very professional and tolerant reply.

[Lassi Kinnunen]

everyone probably just keeps telling to use replicatorg to just do the firmware update and settings adjusting. after you're done with that you can use whatever.. and the reason you would use sailfish instead of mbi fw is that mbi doesn't really give a shit about bugs.

-lassi

[Scott Lichtsinn]

I havent really had any firmware bugs to speak of with the MBI firmware, so can anyone point one out??

My Rep 1 has over 1700 hours of printing on it now with nothing but MBI firmware, its my workhorse, day in and day out it prints and doesn't have a problem or care in the world, so i fail to see how mucking with the firmware any more is going to make a world of difference after 1700 hours of nearly flawless printing, i say nearly because it did have a failed X-Stop cable, but i made a new and better one for it myself a few hundred hours ago.  The only other mods done to the electronics was to change it over to a switching 5v regulator instead of the SMD that was blowing up on these when the stop switch cables got shorted and blew them up.  But mine never blew, did it as preventative maintenance. Lets see was there anything else... Oh yeah the 24v connection to the HBP was going wonky because of the crap connector they used, i repaired that within the first few hundred hours of use, so nearly 1500 hours later still not a hickup from the HBP.

Most of the lifetime of printing on this printer was with firmware revision 7.4 from MBI, it was only a month or so now that its been on 7.5, i don't recall the exact date i updated it, but i plugged it in via USB once just to try a print from USB to figure out a problem that a friend was having with their Rep 1, and the Makerware notified me of an update available so i did it.

My CTC has MBI 7.5 as well, only about 600 hours on that now i think, i would have to check but its been printing non-stop for three days so i havent had a chance to mess with it.  The Wanhao is also running MBI 7.5, only a few hundred hours now and it has a failed X-Stop cable that works when it wants to, new cable is made up and it just has to get installed when i get time, but having two other printers running i just haven't had the ambition to tear it apart yet, probably next week since i have a big print project that could benefit from multiple printers each making a piece of it.

And now i have another Rep 1 thats just about to go out the door now that i repaired it, also with 7.5, its been printing on 7.4 for just about 700 hours, the only reason for the update was the owner was getting sick of the update notice every time they opened Makerware and wanted the printer updated but it wouldn't take the firmware update, which is what started this discussion because all i could find was a 7.4 hex file of the firmware and i didn't want to install Python and RepG to muck with this printer.  RepG and/or Python screwed up my laptop severely last week, have to roll that back with a recovery image and get it working right again, or maybe reinstall windows and start fresh, havent decided, i just click through all the error messages after boot for now until i have time to fix it.

So i have about 2600 hours of printing on MBI firmware... Where is the bugs so i know what to look for?

[Dan Newman]

On 30/03/2015 1:22 AM, Scott Lichtsinn wrote:
> I havent really had any firmware bugs to speak of with the MBI firmware, so
> can anyone point one out??
>

These bugs are generally reported in one of several user groups at which point they
are investigated, duplicated/verified, and then if feasible fixed. Some signficant
ones include,

1. MBI firmware has a deep bug which they then didn't identify in a root cause
analysis. Instead they coded a work around for one of the symptoms of the bug.
That work around causes this,

https://groups.google.com/d/msg/makerbot/TwjG3qsq3DY/lsrz3w01oFsJ

Namely, a heater can fail but the firmware will ignore the failure and start
the print anyway with an extruder not to temp. Fixed in Sailfish. MBI has known
of the bug since March 2013 and never fixed it.

2. Since inception, the MBI firmware for MightyBoards has had a bug which, when
printing over USB, can cause Z hold to be lost for a bit during the initial
starting gcode of a print. This was reported last year by someone with a heavier
than normal build platform. Slipping of the Z axis after homing was visible
to the naked eye in his case. The bug does not occur when printing from SD
card OR if you print from USB, cancel that print, and then start a new print
over USB. This bug is fixed in Sailfish 7.7. MBI isn't planning to release
new MightyBoard firmwares and so they won't be fixing this in their branch.
Somewhat ironic since the Cupcake / Thing-o-Matic firmware line from MBI (3.1)
ended with a Z hold bug as well. (But that one was introduced in 3.0 unlike
the one in the MightyBoard firmwares which has been there since inception.)

My guess is that a lot of print failures ascribed to poor leveling can be
attributed to this bug. How many times have we seen this with a new user?

new user: the sample SD card prints work fine, but when I try my own
print it fails and won't stick to the build platform. I've tried leveling
many times and the SD card prints work but not mine? What's up?

community: are you printing over USB or SD card?

new user: USB

community: try SD card

new user: Well, things are going better now. Guess I'll stick to SD card.

And thus the group-think that USB printing is undesirable continues.

3. But, talking about USB, there's a serious flaw in how MBI's firmware handles
USB errors. It doesn't! Back in the Cupcake/Thing-o-Matic days, MBI commented
out the code to generate an error response to a bad command received over USB.
I do not know why they did that and no one at MBI remembered why either. When
they moved to github, they did not port the change history from their prior
source control system. Thus the change commentary was lost.

MBI's RepG, MakerWare, and Desktop send an X3G command over USB. If there's
an error, their firmware sends NO response whatsoever. Not a positive acknowledgement
nor a negative acknowledgement. The desktop software times out waiting for
a response, and then just resends the command again. It will do up to five
resends. If after five resends, there's still no response, then it just moves
on to the next command. It may be that the command it just skipped over
was important (i.e., restore the VREF settings for the digital potentiometers
controlling current to the stepper motors; turn the heaters off; etc.).
Interestingly enough, if it's a printing command all that might happen is a
little defect (unless it's an entire long line): that because the XYZ positions
are always absolute positions and the extruder positions relative. As such,
a lost G1 command has minimal effect. So, the lion's share of commands won't
be harmed much by this. However, this happened more often then you might
realize: RepG if you print over USB actually reports these timeout errors
and folks who have done much USB printing from RepG are used to seeing those
timeout errors from time to time and, since they don't understand what they
mean, don't think much of them. MakerWare and Desktop do not report those
errors....

Now, a case came up and was reported publicly in which near the end of a print
the extruder would go to 290C instead of 0C (off). Turned out to be a case
that could be reproduced while printing over USB from RepG. Jetty did a lot
of spelunking and found the issue to be a deterministic case with USB comms
failure. And, having the firmware report errors when receiving commands over
USB would catch the problem. So, in late Spring of 2013 Sailfish fixed that.
Discussions with MBI left us thinking they would fix it as well in their
firmware, but they never did. We had also found a bug in MakerWare triggered
by the firmware returning error responses. MBI did go ahead and fix that
in MakerWare. (Conveyor to be specific.)

While investigating this bug, we identified two other bugs in the USB
comms code in MBI's firmware and Sailfish by extension. One was fairly
obvious the other subtle and related to how the compiler represented
a specific data type, making access to a state variable unsafe from non-interrupt
level code. (Bytes off of USB are received and processed in interrupt-level
code; but the command loop which then processes assembled X3G commands is
at non-interrupt level.) This/these bugs are fixed as well in Sailfish.

I suspect that with these changes and 2 above, printing over USB is
far more reliable these days. Honestly, however, with some of the electrical
faults of the MightyBoard rev E, I wouldn't leave my laptop electrically
connected to a MightyBoard any longer than I have to. Those boards do
have some failure modes whereby 24V can spill onto ground and those
boards do not isolate the USB ground from the board's ground plane.

4. There's a bug in the SD card library which MBI uses. Sailfish uses that
library as well. The bug was causing an SD card file header to always be
written to before closing an SD card file. ALWAYS. As in even if the file
is just being read. Specifically, the bug was causing the file length
field to be written as well as the file creation time field. Now, if you're
having signalling problems with the
SD card and you're not checking SD writes, then a bad length may be written.
That can cause the file to be truncated or lengthened and have garbage.
The MightyBoard rev E and G both have SD card signal integrity issues.
And MBI's firmware doesn't check the succes/failure of SD writes. (You
can provide a 16bit checksum for the command + data and the SD card
will first validate that the received command + data match that checksum.)

Now folks had often remarked how the dates on SD card files would go
from being correct (when viewed on their desktop) to being 1 Jan 1970
after printing the file. Jetty and I knew of that but it wasn't high
priority on our to-do list. Had we thought about it, we would have
asked, "Why is the printer rewriting part of the file header"? (Actually,
I wasn't too familiar with the intracies of FAT-16 so I was willing
to believe that maybe that was really a last-access time field and so
the bot was rewriting it but since it didn't know the date/time it wrote
the zero-time which is 1-Jan-1970 00:00:00 UTC.)

Then one person -- one of the esteemed moderators of the 3DPToday podcast
and moderator of this here forum -- had
a very reliable case in which an SD card file would print once fine
and all subsequent times incorrectly. He reported it. That enabled us
to do some sleuthing at which point we then discovered the bug in the SD
card library whereby it would ALWAYS rewrite the length field before closing
the file. SD card I/O errors caused by the electrical design problems
with the rev E & G MightyBoards was leading to bad bytes being written
for the file length. We fixed the problem and reported it to MBI as well
as the developer of the SD card library. The developer concurred with
our analysis and fix. MBI just duly noted the bug but never fixed it
in their sources.

5. There's bugs with MBI's processing of G92 gcode commands. As a result,
MBI's firmware doesn't work well with Cura, Slic3r, KISSlicer, and
other RepRap slicers which like to issue a G92 command at the start of
each layer. (Slic3r's mode to tell it to generate Makerbot gcode
is primarily telling it to not generate G92 commands.)

6. Gcode to display messages (e.g., progress messages) on the LCD UI
has bugs and doing this can result in the printer hanging. This is why
early versions of Simplify3D didn't work well with MBI firmware; whereas,
it worked just fine with Sailfish. Sailfish had those bugs fixed. MBI
has never seen fit to fix them. Simplify3D stopped generating those
progress messages (e.g., Homing, Heating, etc.).

7. For Rep 2 and 2X, you can get false heater errors if you use extruder
temps above 240C. This was found in a batch of about five bugs related
to MBI's MightyBoard rev G and H firmware. MBI fixed four of those
bugs when they were reported by Jetty and I. However, they decided
to not fix this one; they didn't think anyone should be printing at
temps above 240C.

8. Probably a dozen or more heater control related bug fixes for issues
most people won't see, but do come up. For example, if during heating
while the extruder heaters are "waiting" and the HBP is heating up,
if a new temp is commanded for one of the "waiting" heaters, then
temperature control can get wonky and not work correctly for that heater.
People printing over USB and decided to change a set point temp from
a UI control panel encountered that one.

Sailfish has many, many other fixes but they fall into the "minor"
category compared to some of the above (e.g., the line count display bug in MBI's build
stats during a running print; better SD card error handling; actually reporting
which heater has failed and not leaving the user to determine which of three
heaters or temp sensors is failing; verifying that the digipots switched to
the commanded setting; RGB LED I2C fixed; not clobbering the x-min, y-min, z-max
endstop ports; etc, etc.)

There's easily a hundred minor fixes
many of which relate to bugs reported publicly which the Sailfish team
actually takes the time to investigate regardless of which firmware the
bug was reported in. MBI, on the otherhand, stopped paying attention to
their own forums shortly after they released the Rep 1. (They were far
more involved in the Cupcake and Thing-o-Matic days.) So, it should come
as no surprise that MBI hasn't been doing much to fix bugs: they haven't
been listening. Jetty and I would talk with them regularly and call them
up when significant bugs were found. But shortly after the Rep 1 came
out, MBI had also developed too much bureaucracy and the developers had
to work on what marketing told them to work on. They apparently
weren't allowed to work on bugs without approval from on high. So, only
a small number of reported bugs were fixed. BTW, their 7.5 release was
just a couple of bug fixes to the dubious "keep heaters on after the print
is finished" option they added. I'm told they added that because Bre
wanted it. It's a feature of dubious value. And their implementation
had a number of bugs; I'm not sure if they fixed them all in their 7.5
release. MBI's unannounced 7.6 release was a minor change intended to
deal with a behavior change in the Rep 2X brought about by manufacturing
changes. The issue is easily addressed by changing the PID tuning which
doesn't require a firmware change to effect.

Dan

[TobyCWood]

@Dan

I am awed by your patience.

As well as your coding skills.

Respect.
I can say first hand, that my Flashforge Creator out of the box exhibited the run-away heater bug in the MBI version of the FW. Had I not been aware of it the bot would have destroyed the heater. I installed Sailfish (and I followed the instructions when I did so!) and the bug was gone.

I suggest to Scott to just use what you want, but regardless of what you post here & your opinions of SF VS MBI FW I'd say the consensus here is that you are incorrect. I guess I can understand how someone can think that way when they miss very important steps when installing FW. It is easy to kneejerk. I am guilty of it too.

Regardless of your opinion of SF, MBI has demonstrated over and over that it is not capable of producing even a semblance of reliable FW, SW or HW without the help of the open source talent... some of which frequent this GG.

[AL M]

I was also guilty of improper first instillation of SailFish Ver 7.6 . I am sure Dan remembers this. I cussed it up and down ,then went back and read and installed it properly .Well Thanks to this firmware i have over 8500 hours on this MB2X and being able to change temps and speed on the fly and dependability  has allowed me to print some very tough prints ,ABS and PLA found on Thinigiverse .I do not need to post pictures here . All i can add is Thank You Dan and Jetty for your outstanding work.

 Al

On Wednesday, March 25, 2015 at 11:56:31 PM UTC-4, Scott Lichtsinn wrote:

[Dan Newman]

> All i can add
> is Thank You Dan and Jetty for your outstanding work.

You're quite welcome Al.

Dan

[Lassi Kinnunen]

oh yeah had forgotten about that it gave the on the fly speed change ability. been 1.5 years since I've actually used sailfish

my rep1.. well, I only got it to work properly after I installed sailfish on it and my bro is still churning out prints with it.

someone just should do a port to sanguinololu now  :(   (mine has the bigger rom atmel , but dunno if there is some problem with pin arrangements and I'm not familiar enough with atmels to know.. i recall that sf has thermistor support now though??). repetier isn't bad but sf was nicer.

-lassi

[Dan Newman]

> someone just should do a port to sanguinololu now :( (mine has the

> bigger , but dunno if there is some problem with pin arrangements and I'm

> not familiar enough with atmels to know.. i recall that sf has thermistor
> support now though??).

If you've been watching the checkins, then yes you may have seen thermistor
support. Even "azteeg x3" appearing here and there.

Dan

[Joseph Larson]

I think i experienced something similar.

http://joes3dworkbench.blogspot.com/2014/10/fixing-my-detail.html

I can't probe it but I think makerware/desktop intentionally sabotages their x3g code to mess with Sailfish.

[Steve Johnstone]

I would go as far as to say that Sailfish is the best upgrade you could make to your stock R2 /R2X.

As alway huge thanks to Dan and jetty for making it available and their continued support.

[Ryan Carlyle]

I doubt Makerbot is deliberately messing up Sailfish -- they've always officially been fine with people using it. Much more likely, they made a change for some other reason and no one tested it on older machines.

[Scott Lichtsinn]

I havent had any of these bug issues, guess i either have really good printers by chance or i just don't muck around and mess stuff up enough to find these bugs.

My Rep 1 has literally been printing since pulled out of the box without any of these issues that your claiming to be MBI firmware bugs... Not saying they don't exist since plenty have posted about issues, i just haven't had these issues myself.

I took my CTC to the bench and tried doing Sailfish on it about a month ago, followed all the install instructions i could find word for word, in the end i had an unreliable printer that would do weird things, it would crash in the middle of prints, try to shake itself apart, a few times i turned it on and it booted to a blank LCD, no lines at all like a failed install just totally blank, sometimes during a print it would throw up a bunch of garbage on the display, no its no the stepper motor cable interference problem i am familiar with that.

Finally after beating my head against the wall i just figured well it worked fine on MBI firmware and now i put in the latest Sailfish and its a pile of crap.  So i put the MBI firmware back in and did a 14 hour print no problem.  Thats all the evidence i need.

[Jetguy]

No, it just proves you are stubborn and ignorant on the subject at hand.

[John Borlaug]

I Dloaded the new one, cuz I figured werst that could happen is I would get my 'emblems' back onto the SD card,(Red/White M) and maybe some missing datas that I figured I screwed up.One of the settings I saw different is the PID went from 7 to 9, and the others, too- gotta learn that stuff!Shooting in the dark, I ran a file with the left extruder working, and got (picture) alarm, and went into the editable file, saw the default #'s 'goofy' in my understanding, and got the same alarm, only quicker in the 'eport' mode. I changed the default to tool 1, and got a slice all done! Now this being done on the Mac (Mini)-my main driver to SD card.I also tried a dual print 'out of the box, and sure enough, she headed to the left side crash zone.. I did get the 'emblems' back in order, and will now get some good sleep, as the tool one finishes another sample part.

[Jetguy]

#1 picture you posted shows trying to use a Replicator 2X profile with a Mightyboard  AKA Replicator Dual based printer- So right there is ONE REASON why it doesn't work.

Please tell me you didn't Replicator 2X firmware on a Replicator Dual based mainboard and then ask why it doesn't work???

[John Borlaug]

I did forget to mention yes- I did NOT mount anything yet- I ran 2 X ( for the sizing hassles between dual and 2X) and checking out the 2X Json files, all the same- I was surprised of the 'reset' code.I got that failure shown with both dual and 2X

[Ryan Carlyle]

John, you can't keep screwing around with settings and firmware, stuff gets angry when you play fast and loose with it...

The R2x and Rep1 Dual are very different in terms of settings and firmware versions. Gotta keep them separate and respect the differences. 

[John Borlaug]

Thanks Ryan! yeah, I ust found the 3.4on the Thingverse, I think that will sort things out!

[Ryan Carlyle]

3.4 what now?

[John Borlaug]

This one here. Haven't loaded it yet, doing permission repair and deleting all the sub folders all day

http://www.thingiverse.com/thing:682833

[John Borlaug]

well that one is a useless waste of my tyme!Now all I need is a 2.4 on my windows 7 to match the Mini Mac to the Lenovo- too much confusion for all of us! Sorry gang!

[John Borlaug]

OK I think I haven't upset the bot too much: here's a log file of my(first time opening window7 office)and I have all kinds of properties pics of the bot- ID'ed as Rep2, and working OK I started a print, paused when It went to 'the danger zone, unpaused and it continued, and I cancelled when I saw it was going to 'off' the -35000 u's for the location. the cooling cycle finished, and lenovo and bot are all shut down now.

[Gian Pablo]

So here's a weird one that I heard, from someone who was very close to the issue:

• Apparently, there are some X3G files that may write to the EEPROM, and change a setting
• The way this manifested is that a Replicator (Dual, 2 or 2X) would be printing fine. Then someone would print this particular file, and then the print quality would become poor, with visible bumps in the print, this seemed mostly due to decceleration not being right (clunking when changing direction)
• Resetting the EEPROM to factory values (or installing Sailfish, which does the same thing) would fix it

I encountered this. My Rep2X started printing poorly, I installed Sailfish, suddenly quality was great again, tried reinstalling MBI firmware and quality remained good. (Then I went back to Sailfish, because I find it much more efficient)

The issue has not yet been fully debugged. Apparently there is a legacy X3G command that can trigger the firmware to write to EEPROM, and that particular EEPROM location is now used for something else. 

This is mostly speculative, but is what I've heard: it is probably not an X3G command that explicitly writes to EEPROM, rather it is a command or sequence that causes the firmware to actually write the value. Maybe it was leftover debugging code: maybe they needed to count the number of times a given event occured, and figured that they'd stash the value in EEPROM so it would survive a reset, and it was never documented, or not removed when not needed. Much later that EEPROM value was actually used by MBI and Sailfish for something else, probably a parameter related to acceleration. 

I'm sure Dan can shed more light on this. It would probably be straightforward to scan the code for segments that write to EEPROM.

[Dan Newman]

On 06/04/2015 10:37 AM, Gian Pablo wrote:
> So here's a weird one that I heard, from someone who was very close to the
> issue:
>

> - Apparently, there are some X3G files that may write to the EEPROM, and
> change a setting

There are X3G commands to write any data to any location in EEPROM.

There's also an X3G command to write current extruder position to EEPROM.
This command doesn't include where in EEPROM to write or what to write.
It just tells the firmware to take the current postion on a given axis
and write that to the home offset for that axis. As such, as long as
the command is correctly coded in the firmware, nothing bad happens....

This X3G command is used in the calibration scripts for calibrating the home
offsets. Those scripts are safe to use in Sailfish. MBI, however, decided in
their 7.0 releast to change (1) where they store in EEPROM all home offsets,
and (2) how they represent the data in memory. Again, this is fine assuming
they correctly coded their firmware. However, they didn't: when they made
this change they introduced a number of bugs in both their firmware and in RepG.
(They checked the changes in literally an hour or two before making the final
RepG 40 release and 7.0 firmware release. There was little to no testing
of the changes.) This is one of those bugs. They switched to units of micrometers
but then botched the calculation whereby the take the current axial position
in units of steps and then convert to micrometers for storage as a home
offset in EEPROM,

position = (int32_t)(stepperAxisStepsToMM(position, i) * 1000.0) / 1000;

Converting from steps to mm and then multiplying by 1000.0 micrometer/millimeter
is fine and correct. But then they divide by 1000? And that's a bug in
MBI's firmware. So, when you use those scripts to calibrate your home
offsets, EEPROM receives the home offset in units of millimeters but then
everywhere else in code it's interpreted as micrometers. So you end up
with home offsets off by a factor of 1000. And, MBI never tested the change
otherwise they would have immediately seen the problem. The bug is still
there to this day. It was introduced in very late Oct 2012 and never fixed.

> - The way this manifested is that a Replicator (Dual, 2 or 2X) would be

> printing fine. Then someone would print this particular file, and then the
> print quality would become poor, with visible bumps in the print, this
> seemed mostly due to decceleration not being right (clunking when changing
> direction)

I suppose someone may have made an X3G file which includes in it some
commands to write who knows what to EEPROM at who knows what location. That
could cause problems. However, I myself have never heard of such a bad X3G
file in circulation.

> The issue has not yet been fully debugged. Apparently there is a legacy X3G
> command that can trigger the firmware to write to EEPROM, and that
> particular EEPROM location is now used for something else.
>
> This is mostly speculative, but is what I've heard: it is probably not an
> X3G command that explicitly writes to EEPROM, rather it is a command or
> sequence that causes the firmware to actually write the value.

There's only two X3G commands which cause a write to EEPROM: the "store home position"
mentioned above and the explicit "write these bytes to this EEPROM location". It's
always possible that MBI has additional bugs in the "store home position" command.
More likely it's some strange case of someone with X3G commands to write something
to EEPROM and it's scribbling at a bad location.... Why someone might have X3G
to do that, I have no idea. But that's the more likely case.

Dan

[tramalot]

this Is why I always say print a traffic cone and enter error's manualy, I never knew this but had bad things happen with scrips so I just made my life simple, death to the hackers.... simple code means simple hacks... baszerds

[Dan Newman]

On 06/04/2015 4:51 PM, tramalot wrote:
> this Is why I always say print a traffic cone and enter error's manualy, I
> never knew this but had bad things happen with scrips so I just made my
> life simple, death to the hackers.... simple code means simple hacks...
> baszerds

FWIW, the script I was referring to is the script for "home offsets". I wasn't
referring to the toolhead offset calibration script. That's a different script
and it does not touch EEPROM. The home offset calibration script is something
everyone ran (with some regularity) on Cupcakes and Thing-o-Matics. Occassionally
people run it on Replicators. Especially when they build their own printer and
wish to use the script to determine or confirm the X and Y distances from the X
and Y endstops to the build plate's center. That can be done with the home offset
calibration script.

Dan

[tramalot]

i know and in no way fault you.... but these evil dogs are there and make life hard... I think mbi has done it on purpose.... if you get a clean install of sf, it rocks 6700 hrs and no problems on 7.6... 1800 on 7.7 but to tell the truth 7.6 on my other bot is fine with me

[John Borlaug]

so for a pure beginner @ this advanced stuff, is all this language located in the logs?

[John Borlaug]

Do ya think anything will become of this answer?

[Dan Newman]

On 06/04/2015 6:18 PM, 'John Borlaug' via Makerbot Users wrote:
> Do ya think anything will become of this answer?

Probably not: the question didn't make sense. There never has been a 2.4 firmware
for Replicators. As such, they cannot help you load a 2.4 firmware. Perhaps you
were looking for MakerWare 2.4? That is available; I've posted links in the past
to this group on how to download it. You likely have to completely uninstall MakerBot
Desktop before you can install MakerWare 2.4.

Dan

[John Borlaug]

Yeah thanks- I've already gotten that completed-on both systems now-ust seein' if I can push their button to 'smart'- unobtainium, I'm sure!

[tramalot]

huh?... read the maps part..... 

[John Borlaug]

I'm sorry Tram- I don't know how to get there in a windows machine- heck I just opened the office to get thelog copied to a rtf! _ i'm a Mac driver!- I usually used the Lenovo for transmitting from USB to SD card!

[John Borlaug]

yeah- there I go- using the 'wrong language again!

[tramalot]

eeprom maps, google is your freind

[tramalot]

makerware 2.4..... + sailfish maps.... read

[tramalot]

http://www.thingiverse.com/thing:32084/#files

[John Borlaug]

Thanks Tramalot!