GPX 1.3 with Cura support

[Wingcommander (whpthomas)]

OK, after a bit of trial and error, I seem to have got Cura post processing working - however it may require a bit of tinkering and testing.

I have attached a profile with all the settings you need to get a Replicator 2 working. You import this profile from within Cura.

There is also a python script attached, which is the plug-in. On my mac, this is installed in 

~/.cura/plugins

Not sure where it goes on windows. You may need to do a 

chmod 775 gpx.py

to give it permission to be executed. Not entirely sure, python is not my thing.

You will also need to download GPX version 1.3 from http://www.thingiverse.com/thing:81425

The latest version of GPX includes buffer overflow detection, for non-compliant gcode (like Cura's embedded config). I have also altered the Reprap gcode flavor to support Cura, which uses M106/7 for the cooling fan, which is actually the cooling block fan on the Replicator 2 - so now in Reprap mode, GPX interprets M106/7 as M126/7 - which is also a lot safer - this is actually how KISSlicer originally killed my extruder a long time ago.

[Wingcommander (whpthomas)]

I just printed a calibration cube with these settings, and it came out perfectly (20.1mm x 20.2mm x 10.3mm), so these default settings seem pretty well tuned for out printers.

[Wingcommander (whpthomas)]

So this plugin should work on both window and mac osx. Here is a breakdown of the code for anyone else interested in writing a non-standard Cura plugin.

Info on writhing the Cura plugin header came from here http://wiki.ultimaker.com/How_to_write_a_Cura_plugin

#Name: GPX

#Info: GCode to x3g conversion post processor

#Help: GPX

#Depend: GCode

#Type: postprocess

#Param: gpxPath(str:/Applications/GPX) GPX path

#Param: machineType(str:r2) Machine type

import platform

import os

from Cura.util import profile

from subprocess import call

I got the idea for the following function from the Cura source here https://github.com/daid/Cura/blob/SteamEngine/Cura/util/sliceEngine.py

def getGpxAppName():

if platform.system() == 'Windows':

if os.path.exists(gpxPath + '/gpx.exe'):

return gpxPath + '/gpx.exe'

return gpxPath + 'gpx.exe'

if os.path.isfile(gpxPath + '/gpx'):

return gpxPath + '/gpx'

return gpxPath + 'gpx'

I got the idea for using the 'lastFile' profile preference from the 'runPostProcessingPlugins()' function defined at the bottom of this file https://github.com/daid/Cura/blob/SteamEngine/Cura/util/profile.py

x3gFile = profile.getPreference('lastFile')

x3gFile = x3gFile[0:x3gFile.rfind('.')] + '.x3g'

Info on making a system call (to GPX) from a python script, cam from here http://stackoverflow.com/questions/89228/calling-an-external-command-in-python

commandList = [getGpxAppName(), '-p', '-r']

if machineType is not None and machineType != '':

commandList += ['-m', machineType]

commandList += [filename, x3gFile]

call(commandList)

The only other bit of info I needed to understand was that code blocks are delimited by their tab indentation. Other than that, python seems pretty similar to PHP.

[AGG]

I'm also new to Python because I wanted to understand in all details s3g-decompiler.py script. The upper script looks good but the function getGpxAppName() does not handle well the else cases when the files/path does not exist. This will cause rising an exception in the call() function and the whole process will stop as result. It should be done by verifying that the file/path exists in both cases and if not just avoid to execute call() and probably to print some user friendly error text.

[Wingcommander (whpthomas)]

It should be done by verifying that the file/path exists in both cases and if not just avoid to execute call() and probably to print some user friendly error text.

Yes it should, but from what I can tell, you need a handle to the window to open up a dialog box - or at least that is how other code in Cura does it - so I just left it at that - it does a minimal check between windows and unix platforms and leaves it up to the end user. Maybe if I could print an error message to std error, it would show up in the slicer log - but I am not even sure how to do that.

Ideally it would open up a file requester if it could not open the file, but then I am not sure there is a way to easily save the updated parameter, back into the profile.

[Bill Culverhouse]

What version of Cura do you have this working under?

I'm trying to set it up on Cura 13.10 on a windows machine and can't seem to get it to remember
any settings, the plugin always starts with the same default settings. Then it doesn't appear to
run GPX.exe that I can tell.

I've tried editing the gpx.ini and it is setup correctly.
I can't see any errors so I don't know how/where it is failing to run.

Another question, is the filament diameter in the INI file required?
I have it set for the filament in the slicer, seems odd to have to set it
in two places (in the slicer and in the GPX.ini)

Thanks for the tool.

b

[Wingcommander (whpthomas)]

I just upgraded to 13.10 on my mac, and the plug-in is still spitting out x3g files for me, so my guess is that it is a windows problem. Make sure you enter an absolute path to the gpx.exe file, like C:\program files\GPX

[Bill Culverhouse]

That was the reason it wasn't running. I was assuming that it would start from the cura directory
so I created an Applications/GPX as in the example config. Specing the absolute location does
run GPX. Though it does display an error "(line 12496) Buffer overflow: input exceeds 1024 character
limit, remaining characters in line will be ignored"

So now it runs but doesn't produce code that works on the bot. And it may be a couple of issues.

The code from the Cura plugin doesn't start the bot at all. When the x3g file is picked the bot just sits there.

Possibly the x3g is not outputted for a Cupcake, even though I've set "cpp" in the plugin and in the INI file. Not sure
how to check that.

If I create an x3g manually from the command line and passing it the INI file, the file does start the bot but the

z-axis screams. I assume that "cpp" doesn't use the same steps/mm that I have set in RepG for the z-axis or
possibly limit the z-axis speed as I have it set in repG.

Would it not be easier to let me specify the steps for each axis instead of all these predefined configurations?

(eg c3, c4, cp4, cpp...) Or is there another bit of subtlety to the x3g format that makes it different for gen3/gen4/mightyboard?

[Wingcommander (whpthomas)]

On Saturday, October 26, 2013 1:27:00 AM UTC+10, Bill Culverhouse wrote:

That was the reason it wasn't running. I was assuming that it would start from the cura directory 
so I created an Applications/GPX as in the example config. Specing the absolute location does 
run GPX. Though it does display an error "(line 12496) Buffer overflow: input exceeds 1024 character 
limit, remaining characters in line will be ignored"

Cura spits out its config in the gcode file and exceeds the '1024' line length limit - this error - assuming it comes up only once can be ignored.

On my mac, there is no gcode - you have to save that manually, but it leaves a x3g file in the same directory as the original stl file - however YMMV.

 

The code from the Cura plugin doesn't start the bot at all. When the x3g file is picked the bot just sits there.

Possibly the x3g is not outputted for a Cupcake, even though I've set "cpp" in the plugin and in the INI file. Not sure
how to check that.

There is a x3g decompiler in the distro https://github.com/whpthomas/GPX which you can use to diagnose the output to see what is going on in there.

 

If I create an x3g manually from the command line and passing it the INI file, the file does start the bot but the

z-axis screams. I assume that "cpp" doesn't use the same steps/mm that I have set in RepG for the z-axis or
possibly limit the z-axis speed as I have it set in repG.

It may be that the you need to check you start.gcode in Cura, set gcode flavor to makerbot (not reprap) in the gpx.ini - under [printer] add

gcode_flavor=makerbot

You must define the machine at the top of the ini file, because the values are read sequentially, so define the machine first to initialise the defaults, then alter its values as needed.

Would it not be easier to let me specify the steps for each axis instead of all these predefined configurations?

Yes in the distro https://github.com/whpthomas/GPX there is an example TOM machine definition, which you can use as a starting point.

 

(eg c3, c4, cp4, cpp...) Or is there another bit of subtlety to the x3g format that makes it different for gen3/gen4/mightyboard?

I just recreated all the machine definitions defined in ReplicatorG

c3  = Cupcake Gen3 XYZ, Mk5/6 + Gen4 Extruder

c4  = Cupcake Gen4 XYZ, Mk5/6 + Gen4 Extruder

cp4 = Cupcake Pololu XYZ, Mk5/6 + Gen4 Extruder

cpp = Cupcake Pololu XYZ, Mk5/6 + Pololu Extruder

t6  = TOM Mk6 - single extruder

t7  = TOM Mk7 - single extruder

t7d = TOM Mk7 - dual extruder

r1  = Replicator 1 - single extruder

r1d = Replicator 1 - dual extruder

r2  = Replicator 2 (default config)

r2h = Replicator 2 with HBP

r2x = Replicator 2X

 

In the source code, c3 is defined as follows.

static Machine cupcake_G3 = {

//  Axis - max_feedrate, home_feedrate, steps_per_mm, endstop;

    {9600, 500, 11.767463, ENDSTOP_IS_MIN}, // x axis (ENDSTOP_IS_MIN = 0, ENDSTOP_IS_MAX = 1)

    {9600, 500, 11.767463, ENDSTOP_IS_MIN}, // y axis

    {450, 450, 320, ENDSTOP_IS_MIN},        // z axis

//  Extruder - max_feedrate, steps_per_mm, motor_steps, has_heated_build_platform;

    {7200, 50.235478806907409, 400, 1}, // a extruder

    {7200, 50.235478806907409, 400, 0}, // b extruder

    1.75, // nominal filament diameter

    0.85, // nominal packing density

    0.4, // nozzle diameter

    1,  // extruder count

    20, // timeout

};

You should be able to plug these numbers into the previous file to define a custom machine def if you think you need to.

Another question, is the filament diameter in the INI file required? I have it set for the filament in the slicer, seems odd to have to set it in two places (in the slicer and in the GPX.ini)

The filament diameter used in gpx.ini is only if you want to gpx to re-write filament diameters. It is the nominal diameter. For example, you would slice at 1.75, set the nominal diameter in GPX as 1.75mm then define all your filament diameters in your gpx.ini

[macro]

filament: white 1.71mm 230c #FFFFFF

filament: silver 1.73mm 230c #C0C0C0

filament: grey 1.73mm 230c #808080

filament: black 1.74mm 235c #808080

filament: purple 1.70mm 230c #FF00FF

filament: pink 1.77mm 230c #FF69B4

filament: blue 1.72mm 230c #0000FF

filament: green 1.68mm 230c #00FF00

filament: yellow 1.72mm 230c #FFFF00

filament: orange 1.79mm 230c #FFA500

filament: red 1.74mm 230c #FF0000

filament: neutral 1.66mm 230c #FFFFFF

filament: gold 1.79m 225c #DAA520

filament: nylon 1.75mm 250c #FFFFFF

Then at then end of your start.gcode file you can define a series of pause@zpos heights, and GPX will insert the M322 codes at appropriate locations within the gcode file, and scale the filament according to the sizes you have defined.

(@start purple)

(@pause 0.9 white)

(@pause 1.75 pink)

(@pause 2.6 white)

(@body)

[Lars Christensen]

Hi everybody

Just jumped on the Cura/Sailfish train today, so im kind of a newbie in all this Cura stuff.

I was wondering if there is a GPX profile made for Replicator 1 - Dual.

I have a Rep1 dual with Sailfish 7.5 and have been using ReplicatorG 0040r22 until today due some x3g compiling error.

Guess i will be needing one to use Cura with Replicator?

Hope you guys do understand my Danish School English:-)

Lars

[Guilherme Vaz]

I want to do the same as you Lars.

I have a replicator, but i use the makerware for .x3g generation. I want to jump for cura. 

Anyone knows some plugin to build in cura?

regards,

Guilherme

[Fun Bart]

Hi, I use a Replicator dual with GPX on a Mac. I just tested the latest beta of cura, http://software.ultimaker.com/Cura_closed_beta/ seems to work well.

Attached: my latest zipped cura profile, zipped plugins folder of cura and the zipped GPX folder, set for the Rep 1 dual.

I printed dual with it, but look at the startGcode fields, as I set the first extruder to begin with manually (I don't get the two startGcode fields of Cura yet). 

When printing with only one extruder, that is resulting in a print with the other (wrong) unheated toolhead, so copy this program and removed the Toolchanges I added at the end of the Start Gcode.

Cura is only generating the x3g code the first time you save the Gcode. After that you have to trigger it manually. I do that by typing a 'space' and deleting it at once in the field " machine type" of the GPX plugin. (BTW, that field has to be empty normally).

Bart

[Lincoln K]

I don't understand how to use this. I am more of an artist than a tech person so I am very confused. I couldn't find instructions anywhere.

I was able to get the plugin into cura, but don't understand where the x3g code is on my computer, or how to implement the -d for ditto print.

Thanks for making this software!  If there is a link to some instructions I'd really appreciate it.

Do I have to use a separate program even though there is a plugin in cura?

[matt gipson]

im with lincoln. cura isnt a problem and using plugins within it isnt a problem, im just not seeing how to export the x3g when i export my gcode

[Mark Walker]

OK, with the current build of Cura (as of today, 15.02.1) on Windows (or are you using a Mac?):

* Download the gpx.py file wingcommander attached above, put it in the plugins folder, if you accepted the defaults when you installed it will be C:\Program Files (x86)\Cura_15.02.1\plugins

* Before you load an .stl, go to the plugins tab, choose GPX and hit the down arrow button below that box

* There should be two edit boxes in the GPX box: path to gpx.exe and machine type, the path should not include the exe name itself, just the path to wherever you downloaded gpx.exe to (that thingiverse link above).  The machine type default is r2 which is replicator2.  For me I set it to r1d (replicator 1 dual).  But I believe that'll be ignored if you have a gpx.ini in the same folder as the gpx.exe

Now whenever you load an stl onto the platform or make a change, it'll spit out an .x3g file in the same folder as the stl.  If it isn't, the most likely reason is the path to the gpx.exe is wrong (it was for me, I'd originally included the gpx.exe on the end, you just want the path to the folder).  You can take that x3g file and copy it to the SD card and print like you would from repG or whatever you're using now.

However, you'll need to do a bit more techy stuff to actually get this to work.  More than likely the start/end-gcode in Cura is wrongish.  You probably want something closer to whatever you're using now.  Of course, since I'm 7 months too late, it's likely you've already solved it or moved on to something else.  But I thought I'd leave this here for other people who might turn it up in a Google search.  To complete this we should probably link to some page with working start/end-gcode.  But that'd be tricky because there are printer specific bits in that.