Simplify3D and Makerbot 5th gen

[joesoap583]

I now have a Makerbot 5th gen. Possibly a stupid question, but what is the accepted procedure for using a 5th gen with S3D in terms of connectivity?

The 5th gen isn't one of the options when choosing a printing profile. Whilst it has USB, connection to a 5th gen is enabled thru a network connection - which AFAIK isn't supported by S3D.

[andre]

You will have a problem controlling the nozzle retraction, amongst other unexplored hardware, which isn't supported in S3D. Being closed source, there may be new gcode commands which is not supported elsewhere. This aside from the unknown bot detection if you can get it to connect via USB.

[teamcarlisle2]

I wish you the best of luck, but I dont think Simplify was ever supposed to support the Replicator 5th gen. Its not listed on their "supported printers" list. And makerbot is trying to go all proprietary, so I think you're going to end up stuck with makerware on that printer. Let us know if you do get it to work though. I've been thinking I might save up and get a 5th gen after they've been out for a year and get the bugs worked out, maybe.

[laird]

I now have a Makerbot 5th gen. Possibly a stupid question, but what is the accepted procedure for using a 5th gen with S3D in terms of connectivity?

The 5th gen isn't one of the options when choosing a printing profile. Whilst it has USB, connection to a 5th gen is enabled thru a network connection - which AFAIK isn't supported by S3D.

The Replicator 5th gen supports printing X3G files from SD cards, so you should be able to go that route. Though you might need to tweak the profile if they've changed the build platform or other geometry. But you're one of the first buyers of the new printers, so it's possible nobody knows the answers yet.

[Jetguy]

MakerBot 5th gen does NOT support X3G nor does it support gcode. The new print files for the 5th gen write the gcode into an all new format and then save it as a .json. This format is completely new and while some users have suggested there is a 1:1 correlation to each gcode move, it's not something you can copy and past together or change a file extension and print.

At best, either someone needs to write a converter similar to the way GPX worked, but specific to the 5th gen style and file extensions or another route and I'm not even sure if it's in the new Desktop software that replaced Makerware is to open gcode created by S3D and then pray the Desktop software can convert it to a printable file.

Simply put, I'm not impressed in the slightest by MakerBot on the 5th gens. It's a ripe disaster and they made these changes to keep folks out. You couldn't pay me to work on one.

[JoeJ]

I feel like half the people I talked to about this said the 5th gens DO support printing from x3g files, and the other half said no. I thought all the json stuff was just metadata for the images and all the stuff that gets displayed on the LCD panel.

If you think about it, a lot of the files that MakerBot sells from their online store are still x3g files! So I would be pretty amazed if they completely dropped compatibility for those all together. Not a good sign.

[tobyCwood]

I feel like half the people I talked to about this said the 5th gens DO support printing from x3g files, and the other half said no. I thought all the json stuff was just metadata for the images and all the stuff that gets displayed on the LCD panel.

If you think about it, a lot of the files that MakerBot sells from their online store are still x3g files! So I would be pretty amazed if they completely dropped compatibility for those all together. Not a good sign.

One of the authors of Sailfish took the json file apart and wrote about what he found on a google group. There's NO correlation between gcode or x3G and the new Gen 5 file format. MBI went COMPLETELY closed source. If you have a Gen 5 machine you can ONLY use MBI Desktop. PERIOD.

[dnewman]

I feel like half the people I talked to about this said the 5th gens DO support printing from x3g files, and the other half said no. I thought all the json stuff was just metadata for the images and all the stuff that gets displayed on the LCD panel.

If you think about it, a lot of the files that MakerBot sells from their online store are still x3g files! So I would be pretty amazed if they completely dropped compatibility for those all together. Not a good sign.

Well, that was the big snafu MBI had initially: the new MBI Desktop advertised the store to the 5th Gen Users who went there and then found that there were no models they could buy and print on their shiny new 5th Gen bots. MBI rectified that after a day or two, but initially there were folks who bought files, they were .x3g, and they couldn't print them. Now, it shouldn't be hard for MBI to cook up an x3g to JSON translator for the 5th Gens. Question is, will they ever? If you pull apart the firmware distribution (requires modifying a Linux kernel to do), then you will see that the sample prints that come with the printer are not in nice, compact .x3g or even gcode. They are in the new JSON format which the 5th Gen bots consume. And it looks like MBI Desktop generates and sends that to the bots as indicated by doing some TCP packet snooping. Maybe they can also consume .x3g? No clue as it's sufficiently closed source now that it's not immediately obvious how to toss files at the bot. Yeah, given more idle time we could have snooped the network more and seen what all was going on and then tried to throw x3g at the bot, but we only had about an hour with it and I didn't want to be implicated when the thing started failing. (Which it did two days later: jammed extruder, oh my! I believe the owner returned it for a refund.)

Here's a sample

% more print.jsontoolpath
[{
"command" :
{
"function" : "move",
"metadata" :
{
"relative" :
{
"a" : false,
"x" : false,
"y" : false,
"z" : false
}
},
"parameters" :
{
"a" : 0.0,
"feedrate" : 150.0,
"x" : -127.0,
"y" : -101.0,
"z" : 0.0
},
"tags" : [ "Travel move" ]
}
},{
"command" :
{
"function" : "move",
"metadata" :
{
"relative" :
{
"a" : false,
"x" : false,
"y" : false,
"z" : false
}
},
"parameters" :
{
"a" : 0.0,
"feedrate" : 60.0,
"x" : -127.0,
"y" : -101.0,
"z" : 0.0
},
"tags" : [ "Travel move" ]
}
},{
"command" :
{
"function" : "move",
"metadata" :
{
"relative" :
{
"a" : false,
"x" : false,
"y" : false,
"z" : false
}
},
"parameters" :
{
"a" : -2.0,
"feedrate" : 50.0,
"x" : -127.0,
"y" : -101.0,
"z" : 0.0
},
"tags" : [ "Travel move" ]
}
},{
"command" :
{
"function" : "move",
"metadata" :
{
"relative" :
{
"a" : false,
"x" : false,
"y" : false,
"z" : false
}
},
"parameters" :
{
"a" : -2.0,
"feedrate" : 23.0,
"x" : -127.0,
"y" : -101.0,
"z" : 0.30
},
"tags" : [ "Travel move" ]
}
},{
"command" :
{
"function" : "move",
"metadata" :
{
"relative" :
{
"a" : false,
"x" : false,
"y" : false,
"z" : false
}
},
"parameters" :
{
"a" : -2.0,
"feedrate" : 150.0,
"x" : -29.82479258930083,
"y" : -7.415532028317421,
"z" : 0.30
},
"tags" : [ "Travel move" ]
}
},{
"command" :
{
"function" : "move",
"metadata" :
{
"relative" :
{
"a" : false,
"x" : false,
"y" : false,
"z" : false
}
},
"parameters" :
{
"a" : 0.1000000000000001,
"feedrate" : 50.0,
"x" : -29.82479258930083,
"y" : -7.415532028317421,
"z" : 0.30
},
"tags" : [ "Travel move" ]
}
},{
"command" :
{
"function" : "move",
"metadata" :
{
"relative" :
{
"a" : false,
"x" : false,
"y" : false,
"z" : false
}
},
"parameters" :
{
"a" : 2.384912201447384,
"feedrate" : 10.0,
"x" : -22.32853213512895,
"y" : -7.415532028317421,
"z" : 0.30
},
"tags" : [ "Support" ]
}
},{
"command" :
{
"function" : "move",
"metadata" :
{
"relative" :
{
"a" : false,
"x" : false,
"y" : false,
"z" : false
}
},
"parameters" :
{
"a" : 3.473508411430116,
"feedrate" : 10.0,
"x" : -22.32853213512895,
"y" : -3.844103456888850,
"z" : 0.30
},
"tags" : [ "Support" ]
}
},{
"command" :
{
"function" : "move",
"metadata" :
{
"relative" :
{
"a" : false,
"x" : false,
"y" : false,
"z" : false
}
},
"parameters" :
{
"a" : 6.524011296035453,
"feedrate" : 10.0,
"x" : -32.33651586628450,
"y" : -3.844103456888850,
"z" : 0.30
},
"tags" : [ "Support" ]
}
},{
"command" :
{
"function" : "move",
"metadata" :
{
"relative" :
{
"a" : false,
"x" : false,
"y" : false,
"z" : false
}
},
"parameters" :
{
"a" : 4.524011296035453,
"feedrate" : 50.0,
"x" : -32.33651586628450,
"y" : -3.844103456888850,
"z" : 0.30
},
"tags" : [ "Travel move" ]
}
},{
"command" :
{
"function" : "move",
"metadata" :
{
"relative" :
{
"a" : false,
"x" : false,
"y" : false,
"z" : false
}
},
"parameters" :
{
"a" : 4.524011296035453,
"feedrate" : 150.0,
"x" : -33.92072832786596,
"y" : -0.2726748854602779,
"z" : 0.30
},
"tags" : [ "Travel move" ]
}
},{
"command" :
{
"function" : "move",
"metadata" :
{
"relative" :
{
"a" : false,
"x" : false,
"y" : false,
"z" : false
}
},
"parameters" :
{
"a" : 6.624011296035453,
"feedrate" : 50.0,
"x" : -33.92072832786596,
"y" : -0.2726748854602779,
"z" : 0.30
},
"tags" : [ "Travel move" ]
}
},

[jsc]

Wow, that really is bloated. And not any more informative than the equivalent gcode.

It seems like someone got a bad case of Standard File Format Syndrome. You see this a lot with XML; what used to be a simple easy to read linear text file gets converted to XML, because structure! validation! and then things are awful. Now it looks like people are doing it with JSON.