Makerbot Desktop 3.7 sends platform to the bottom twice to start a print

[Mark Walker]

I know this has a couple of threads on it already, but since it has been a couple of months and Makerbot hasn't fixed it yet and the answer was buried in those threads, I thought I'd post it at the start of the thread so maybe the search helps better.

If it's bugging you that MakerBot Desktop sends the build platform to the bottom twice at the start of a print you can fix it by editing the json (text file) to change the start position(s).  (You can also switch to an earlier version of MakerBot Desktop.)

You want to edit the file that matches your machine in default_configs folder in the MakerBot/MakerWare folder.  On a 64-bit system with a 64-bit install that is typically:

C:\Program Files\MakerBot\MakerWare\default_configs

and a 32-bit install would be:

C:\Program Files (x86)\MakerBot\MakerWare\default_configs

For my printer, I edit the replicatordual.json file in that folder.  The gotcha is that the z start position is in there twice.  The first one is called "start_z" and the second one is called "z" inside of a "start_position".  Easiest way to find them both is to search for whole word 150 in there.  I changed the "start_z" to be 30 (because that was what it used to be). And the "z" to be 0.3 because that start position is where it goes after the bead across the front and before it starts on the print.

I only used MakerBot Desktop occasionally so I haven't tried things like dualstrusion using this setup, but seems like it'd work there too.  Also, I usually export gcode and use gpx to translate it to x3g so that I can look at or edit the gcode if I need to.

[tramalot]

That gpx app you wrote is hands down the best thing since water!

I gave up on makerware desktop completely, the only thing I use is 2.4 and that's only for luggage name tags and key rings with 2 color logo's 

It scares me that company's are so dumb, even oreo cookies is going to messaco

[Johnny T]

thanks for the info.  I tried it out and it still goes all the way to the bottom and then back after the nozzle purge step, which is a problem since it oozes a bit during that and messes up first layer adhesion in the front left corner. :( it does now wait at 30 instead of 150 to heat up.  I do like 3.7 though since it gives a nice gui for the "advanced" settings.  

[Joseph Chiu (Toybuilder)]

At least it generated the files!  The few times I've tried more recent versions of MakerBot Desktop, it would seemingly generate the .x3g file in whatever temporary directory it's working in -- but the final .x3g file never gets written to the target directory.  I've been too busy to spend more than a few minutes trying to debug it...

[Mark Walker]

I think you may have missed the other 150 in that json file.  There are two. One that looks like this:

"start_z": 150

And the other looks like this:

"start_position": {

   "x" : -112,

   "y": -73,

   "z": 150

},

This latter is the one that I changed to 0.3 because as you note, it's the one that shows up just before the print begins.  In the gcode, it looks like this:

;...

; Miracle-Grue yada yada yada

;...

; Width 0.4 

G1 X105.400 Y-74.000 Z0.270 F9000.000 (Extruder Prime Dry Move)

G1 X-112 Y-73 Z0.270 F1800.000 E25.000 (Extruder Prime Start)

G92 A0 B0 (Reset after prime)

;***** It's this next line here that comes from that "start_position" ****

G1 Z0.300000 F1000

G1 X-112.0 Y-73.0 Z0.3 F1000 E0.0

G92 E0

G1 X-112.000 Y-73.000 Z0.300 F1500 A-1.30000; Retract 

G1 X-112.000 Y-73.000 Z0.200 F1380; Travel Move 

M73 P0; Update Progress 

[Pats B-oogle]

Everyone,

Though Mark's information is correct in that if you edit the default config file it will stop the move down to the bottom right before heat up but most are looking for the move down after the purge. The answer is simpler than you think but first I would like to correct Marks instructions.

To change the move all the way down to the bottom before heating all you have to do is change the one spot:

"start_position": {

   "x" : -112,

   "y": -73,

   "z": 150

},

... to something like ...

"start_position": {

   "x" : -112,

   "y": -73,

   "z": 30

},

Now more importantly to change the move down *after* the purge you simply edit a custom Print Settings Custom Presets (aka profile) using the "Edit in Text Editor" button and change the following

  

  "startPosition" : {

      "x" : -112,

      "y" : -73,

      "z" : 150

   },

   ... to ...

   "startPosition" : {

      "x" : -112,

      "y" : -73,

      "z" : 1

   }, 

Issue resolved and tested with Makerbot Desktop 3.7.0.108

Cheers!
Pat 

[Mark Walker]

Oh yeah, I didn't use the custom presets.  If you do, you'll definitely want to change it in the preset as well.  And this is a good way to do it.

I should have been more clear in my original post, but if you do change *both* places, you should be able to use the default config without a custom preset and avoid both moves to the bottom.  At least, in my case it only moves to 150 after the print is complete.

Again, it gets pressed into the custom presets so you also have to change those (if you use them) by edit as text as Pat says.

I'm glad you're able to use custom presets though.  For me, they seem to crash the MakerBot software when I try to slice.

[Mark Walker]

My crashing might be my just desserts for buying a FlashForge?

[Dan Newman]

> Issue resolved and tested with Maker Desktop 3.7.0.108

Keep in mind that there's also a "hidden" set of start positions. As a result,
you can still have difficulty if you have a non-standard build area in the XY
plane. Z ends up being okay, it's XY start positions which get impacted. So,
the above works as long as you have not expanded or shrunk your X or Y axis
dimensions. If, however, you've done that as well, then you have to edit Python code
in one of the .egg files. (makerbot_driver-0.1.1-py2.7.egg which contains
Python code for each "standard" machine type. In that python code there's
yet another start position associated with the purge anchor. The X & Y coordinates
end up being used from it. I just went through this again with 3.7 a couple
of weeks ago.)

But if you have a standard build volume, then you're okay with just doing the
above.

Dan

[Pats B-oogle]

I only run FlashForge ... I have three of them.

P.S. Mark, thanks for your post. It was a big help and I wanted to do the same by posting my findings as well. Hope someone else benefits as much as I did.

Cheers!

Pat

[Tim Mallard]

Mark, Thank you for working on this! I bought a Raspberry Pi last summer in hopes of reducing the miles I walk between my CNC and my Makerbot 2X and my computer. I can't for the life of my get the Octopi 0.12 or 0.13 to connect to my wireless router by editing the network-Config.txt file. Does anyone have any suggestions to try? Maybe I removed the wrong # sign. 

   Tim  

On Sunday, August 23, 2015 at 9:02:18 PM UTC-4, Mark Walker wrote:

[Dan Newman]

On 12/10/2015 7:57 AM, Tim Mallard wrote:
> Mark, Thank you for working on this! I bought a Raspberry Pi last summer in
> hopes of reducing the miles I walk between my CNC and my Makerbot 2X and my
> computer. I can't for the life of my get the Octopi 0.12 or 0.13 to connect
> to my wireless router by editing the network-Config.txt file. Does anyone
> have any suggestions to try? Maybe I removed the wrong # sign.

IIRC, you first need to figure out which form of security your access point is using,
WEP, WPA, WPA2, etc. On some computers, you can get that info while you're connected
to tha access point, others not. You used to be able to tell on OS X but in Mt Lion
(+/- 1 release), they removed that. (You could right click on the WiFi icon and see.)
I believe you can still see on Windows if you know where to look.

Dan

[Mark Walker]

In my case, I had to work pretty hard at it because my tp-link nano USB wifi's driver doesn't come with rapbian and worse, it seems to need a different one depending on the kernel version. Or at least the communities' solution does. So I had to wire it with Ethernet and download/install some stuff before I could untether.

Are you getting blinking lights on your wifi stick?

[Tim Mallard]

So here is the weird thing. I was able to get Octopi 0.11 (used the built in wifi utility) to connect and talk to my web browser with no problems. It was only when I went to the newer 0.12-0.13 that I could not get things working. Below is what I removed the "#" comment on the text file. Maybe I didn't do that right or the spaces and returns I added messed it up. I'll looking your other suggestions and see what I can come up with. Thanks!

  

 WPA/WPA2 secured

 iface wlan0 inet manual

 wpa-ssid "xxxxxxxxxxxxxxx"

 wpa-psk "ppppppppppppppppp"

# WEP secured

#iface wlan0 inet manual

#    wireless-essid "put SSID here"

#    wireless-key "put password here"

# Open/unsecured

#iface wlan0 inet manual

#    wireless-essid "put SSID here"

#    wireless-mode managed