Simplify3d and Cupcake printers

55 views
Skip to first unread message

Dan Laskowski

unread,
Sep 9, 2016, 1:46:01 PM9/9/16
to Vintage Makerbot
It took me a while, but I finally got Simplify3d to make useful .x3g files for my Cupcakes!  If your experience has been like mine, the files that Simplify3d makes have Z axis issues and the prints come out squashed.  My work around has been to let Simplify3d make the .gcode file and then let Replicatorg process the .gcode into the .x3g file.  It works but is slow, an extra step and for large detailed files, sometimes impossible.

So, I chased down the details and got it working for my Cupcakes.  Hopefully, this information will help someone else with their printers too.

It takes two changes to the system to make it work.
  1. A custom gpx.ini file.  I called mine gpxcupcake.ini and I put it in the Simplify3d program file directory.  Note: each update of Simplify3d makes a new program directory and you will have to put a copy of the .ini file in the new directory to keep this solution going!
  2. A post processing command in the Scripts section of your printer profile to tell GPX.exe to make the .x3g file for you.
I have attached a copy of the gpxcupcake.ini file to this message.  All I did in the file was to add a max_feedrate=150 for the z axis.  Somebody else can explain why it helps and whether there is a more correct change that I should have made, but bottom line: my two Cupcakes like it and work wonderfully with this one change.

The post processing command was the tricky part -- I scoured several posts and finally pieced together what works on a Windows 7 system.  It is: gpx -c gpxcupcake.ini "[output_filepath]"  Check out the screen capture of the scripts window to see what it looks like

I am doing this as documentation for myself, but my hope is that this helps someone else have a better printing experience.



gpxcupcake.ini
FFF Settings 992016 13423 PM.bmp

Robert Trescott

unread,
Sep 9, 2016, 6:16:38 PM9/9/16
to vintage-...@googlegroups.com

Dan,

I have a T-O-M and I have found a similar work around of taking the S3D gcode directly into Replicator and making the .x3g files from there onto  my SD card.

The problem I encountered has to do with controlling the conveyor HBP motor FET. While I don't use the conveyor platform, I do use cooling fans that come on when the print has finished. Apparently, I can only access that functionality in RepG.

Also, S3D is notorious for sending commands to my Extruder Controller that makes it go haywire!

I have tried changing the gpx.ini and executing GPX after the build with no reliable success. I had also tried to contact the author of GPX about making these kinds of changes to no avail. I have just resolved to add the RepG step as the post-processor as one of those necessary evils :)

Thanks for sharing your experience! 

--
You received this message because you are subscribed to the Google Groups "Vintage Makerbot" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vintage-makerb...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mark Walker

unread,
Sep 9, 2016, 8:58:51 PM9/9/16
to Vintage Makerbot
I'm the current maintainer of GPX.  What do you need it to do?

Dan Laskowski

unread,
Sep 9, 2016, 10:08:29 PM9/9/16
to Vintage Makerbot
One more important thing!  You need to change the name of the Simplify3d directory to use "dash" symbols instead of "periods."

Mark Walker

unread,
Sep 10, 2016, 3:13:39 AM9/10/16
to Vintage Makerbot
Huh, that's weird.  I wonder if the new GPX still has that problem: https://github.com/markwal/GPX/releases

GPX will look in $HOME/.gpx.ini now.  I imagine we could make it look in ~/.gpx.ini as well (in case $HOME isn't defined).

Robert Trescott

unread,
Sep 10, 2016, 3:18:14 PM9/10/16
to vintage-...@googlegroups.com

Thanks Mark for being there supporting GPX! It's been a few years since I've worked on the procedures I use for printing parts. As was one of the first users of S3D with the original TOM electronics, I had to adapt, experiment and settle with a solution, so I could spend more time making real parts than test cubes!

When I get some time to rework my process, I'll check out the latest Github version and print up some more test cubes :)

Thanks again for supporting/maintaining GPX.

Dan Laskowski

unread,
Sep 11, 2016, 2:31:51 PM9/11/16
to Vintage Makerbot
Mark -- the new GPX may fix the directory problem, but I am working with the version that ships with Simplify3d and I'm pretty sure that version doesn't look in the right place for the .ini file.

Mark Walker

unread,
Sep 11, 2016, 4:06:11 PM9/11/16
to Vintage Makerbot
It does not, but you may use a more recent version with Simplify3d

Dan Laskowski

unread,
Sep 12, 2016, 10:12:56 AM9/12/16
to Vintage Makerbot
I will email Simplify3d and let them know.  That would fix one of the issues with Simplify3d and Cupcake printers.

Now, IF we can make sense of why the z-axis maxfeedrate=150 works / is necessary for Cupcakes AND IF it was part of the default GPX configuration for Cupcakes, then Simplify3d would make correct .g3x files automatically out of the box.

I'm still not totally sure why maxfeedrate makes such a difference, but I am happily printing away with my three step fix to Simplify3d, so I am not complaining.

Note: I have always wondered what the difference was between Simplify3d and Replicatorg regarding GPX.  Could there be a difference in how the two programs call GPX?  Some extra parameters passed in the run command that let Replicatorg work when Simplify3d couldn't?

Daniel Newman

unread,
Sep 12, 2016, 12:00:46 PM9/12/16
to vintage-...@googlegroups.com
On 12/09/2016 7:12 AM, Dan Laskowski wrote:
> I will email Simplify3d and let them know. That would fix one of the issues with Simplify3d and Cupcake printers.
>
> Now, IF we can make sense of why the z-axis maxfeedrate=150 works / is necessary for Cupcakes AND IF it was part of the default GPX configuration for Cupcakes, then Simplify3d would make correct .g3x files automatically out of the box.
>
> I'm still not totally sure why maxfeedrate makes such a difference, but I am happily printing away with my three step fix to Simplify3d, so I am not complaining.
>
> Note: I have always wondered what the difference was between Simplify3d and Replicatorg regarding GPX.
> Could there be a difference in how the two programs call GPX?

RepG doesn't use GPX. When GPX was originally written, Henry based it upon RepG's own gcode to X3G
translator. He did so while consulting with Jetty and me (as the only active people with experience with
RepG internals) and as a result we collectively turned up a couple of longstanding bugs in RepG.

Also, keep in mind the issue with Cupcakes and the first non-homing move generated by RepG or GPX for an
SD card print: when those programs do not know the starting position, they generate a non-accelerated
move (i.e., a move with infinite acceleration). That often causes, on a Cupcake, severe slipping if
the maxfeedrate is too high (e.g., larger than around 300 mm/minute). The starting position will be
unknown if, for example, a RECALL HOME OFFSETS was just done. This issue doesn't arise when printing
over USB since RepG can then just ask the printer what its position is after the printer does the
RECALL HOME OFFSETS. Not possible to do that when writing all the commands to a SD card file.

So, because of the above, you either have to

1. Set the maxfeedrate low enough for your mechanics, or
2. Do not use RECALL HOME OFFSETS when writing to an X3G file and instead assert the home position
coordinates with a G92 command. That is, talk to your printer with RepG, determine the home offset
positions xh, yh, zh, and then replace in your start gcode the RECALL HOME OFFSETS command with

G92 Xxh Yyh Zzh A0 B0

Dan

Dan Laskowski

unread,
Sep 13, 2016, 9:36:40 AM9/13/16
to Vintage Makerbot

Thanks for the extra info -- especially that Replicatorg does not use GPX.  That explains a lot.

Regarding the failure on Cupcakes, as I recall, the problem I was fighting was not an initial positioning thing but a Z axis movement issue.  I always hand position my Cupcakes at 0,0,0 and press start, so your infinite jump scenario is not a factor in my setups.  My problem was with the Simplify3d .x3g file, the Z axis was going up at a fraction of what it should have for each layer and was smashing all the layers together.  Based on my setup, the Z axis should turn about 1/8 revolution per layer and what I kept seeing was something about 1/80 of a revolution per layer.  That all went back to normal with the maxfeedrate command.

And as part of full disclosure: I have a custom up/down system with very little resistance in the up/down movement, so my experience could be [probably is] different than others.  Search the forum for "Cupcake up / down for QU-BD" for pictures of what it looks like.  
Reply all
Reply to author
Forward
0 new messages