whpthomas / gpx

Gcode to x3g conversion post processor

This project is now maintained at https://github.com/markwal/GPX

GPX was created by Dr. Henry Thomas (aka Wingcommander) in April 2013

GPX is a post processing utility for converting gcode output from 3D slicing software like Cura, KISSlicer, S3DCreator and Slic3r to x3g files for standalone 3D printing on Makerbot Cupcake, ThingOMatic, and Replicator 1/2/2x printers - with support for both stock and sailfish firmwares. My hope is that is little utility will open up Makerbot 3D printers to a range of new and exciting sources and utilities for 3D printing input.

Usage:

gpx [-dgiprsvw] [-b B] [-c C] [-f F] [-m M] [-x X] [-y Y] [-z Z] IN [OUT]

Options:

-d	simulated ditto printing
-g	Makerbot/ReplicatorG GCODE flavor
-i	enable stdin and stdout support for command line pipes
-p	override build percentage
-r	Reprap GCODE flavor
-s	enable USB serial I/O and send x3G output to 3D printer
-v	verose mode
-w	rewrite 5d extrusion values

B is baudrate for serial I/O (default is 115200)

C is the filename of a custom machine definition (ini)

F is the actual filament diameter in the printer

M is the predefined machine type:

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)
r2h = Replicator 2 with HBP
r2x = Replicator 2X

X,Y & Z are the coordinate system offsets for the conversion:

X = the x axis offset
Y = the y axis offset
Z = the z axis offset

IN is the name of the sliced gcode input filename

OUT is the name of the x3g output filename or the serial I/O port

Examples:

gpx -p -m r2 my-sliced-model.gcode
gpx -c custom-tom.ini example.gcode /volumes/things/example.x3g
gpx -x 3 -y -3 offset-model.gcode
gpx -m c4 -s sio-example.gcode /dev/tty.usbmodem

gpx's Issues

LOW PRIORITY: Test to close sio_port descriptor in exit_hander() makes a false assumption

In gpx-main.c/exit_handler(), the sio_port descriptor is only closed if it is > 2. That assumes that when it was opened, it was assigned a value of 3 or more. That won't be the case when the process is exec() and forked() in a context that doesn't open one or more of stdin, stdout, and stderr. That is, that test assumes that stdin=0, stdout=1, and stderr=3. That's not always true.

The test should be changed to "if(sio_port >= 0) close(sio_port);".

Instruction

Are there any instructions on how to use this for Win 7 in Cura and Slic3r ? Please note I'm not a coder or Linux user and know nothing about 'compiling'. Thanks

Incorrect progress reported (Sailfish)

Hi!
I have a Replicator 1 dual extruder clone - Wanhao Duplicator 4, upgraded to Sailfish firmware.
I think it's strange, but files converted with GPX report wrong progress - it starts somewhere around 15-50% instead of 0%...
And it was the same with stock makerbot firmware...
What may be the cause?

Benign comment can cause GPX to generate a "change tool" command

When using the left extruder (tool 1), benign comments in the gcode cause GPX to generate a "change tool command" switching unexpectedly to the right extruder (tool 0).

Here's simplified gcode exhibiting this behavior. The Z axis has 400 steps/mm and so 324 steps = 0.81 mm and 444 steps is 1.11mm.

G90
M83
M73 P0; enable build progress
G21; set units to mm
G90; set positioning to absolute
G92 X0 Y0 Z0 A0 B0
M140 S100 T0
M104 S0 T0
M104 S210 T1
M6
G1 E-1 F1800
; layer 1, Z = 0.21
M135 T1
; tool H0.3 W0.48
G1 X14.72 Y-11.8 F3600
G1 Z0.21 F600
G1 E-1 F1800
; layer 2, Z = 0.51
G1 X-9.28 Y9.28 F3600
G1 Z0.51 F600
G1 E1 F1800
G1 E-1 F1800
; layer 3, Z = 0.81
M140 S74 T0
G1 X-9.28 Y9.28 F3600
G1 Z0.81 F600
G1 E1 F1800
G1 X-9.28 Y-9.28 E1.0474 F2700
G1 X8.896 Y8.465 E0.0244
G1 E-1 F1800
; layer 4, Z = 1.11
G1 X-9.28 Y9.28 E0 F3600
G1 Z1.11 E0 F600
G1 E1 F1800
M73 P100 ; end build progress

And here's the X3G dump. Note the switch to tool 0 on command 28. That's right at the end of "layer 3" for 0.81 mm and the start of layer 4 for 1.11mm. If the comment flagging the start of layer 4 is removed, the spurious tool change command goes away.

% s3g-decompiler.py cube2.x3g | more
Command number [byte offset]: Command name: options
1 [0]: Start build: steps 0, name "cube2"
2 [11]: Set build percentage: 0%, ignore 0
3 [14]: Switch tool: change to tool 0
4 [16]: Set machine position extended: (0,0,0,0,0)
5 [37]: Tool 0: Set build platform target temperature: 100
6 [43]: Set build percentage: 1%, ignore 0
7 [46]: Tool 0: Set target temperature: 0
8 [52]: Set build percentage: 80%, ignore 0
9 [55]: Tool 1: Set target temperature: 210
10 [61]: Set build percentage: 99%, ignore 0
11 [64]: Switch tool: change to tool 1
12 [66]: Wait on platform: tool 0, 100 ms between polls, 65535 s timeout
13 [72]: Wait on tool: wait for tool 1, 100 ms between polls, 65535 s timeout
14 [78]: Move to: (0,0,0,0,96), dda_rate 2560, relative mask 18, distance 1.000000, feedrateX64 1706
15 [110]: Move to: (1386,-1111,0,0,0), dda_rate 4407, relative mask 18, distance 18.865799, feedrateX64 3840
16 [142]: Move to: (1386,-1111,84,0,0), dda_rate 4000, relative mask 18, distance 0.210000, feedrateX64 640
17 [174]: Move to: (1386,-1111,84,0,97), dda_rate 2560, relative mask 18, distance 1.000000, feedrateX64 1706
18 [206]: Move to: (-874,874,84,0,0), dda_rate 4243, relative mask 18, distance 31.943174, feedrateX64 3840
19 [238]: Move to: (-874,874,204,0,0), dda_rate 3999, relative mask 18, distance 0.300000, feedrateX64 640
20 [270]: Move to: (-874,874,204,0,-97), dda_rate 2560, relative mask 18, distance 1.000000, feedrateX64 1706
21 [302]: Move to: (-874,874,204,0,97), dda_rate 2560, relative mask 18, distance 1.000000, feedrateX64 1706
22 [334]: Tool 0: Set build platform target temperature: 74
23 [340]: Move to: (-874,874,324,0,0), dda_rate 3999, relative mask 18, distance 0.300000, feedrateX64 640
24 [372]: Move to: (-874,874,324,0,-97), dda_rate 2560, relative mask 18, distance 1.000000, feedrateX64 1706
25 [404]: Move to: (-874,-874,324,0,-101), dda_rate 4235, relative mask 18, distance 18.559999, feedrateX64 2880
26 [436]: Move to: (837,797,324,0,-2), dda_rate 3031, relative mask 18, distance 25.401812, feedrateX64 2880
27 [468]: Move to: (837,797,324,0,96), dda_rate 2560, relative mask 18, distance 1.000000, feedrateX64 1706
28 [500]: Switch tool: change to tool 0
29 [502]: Move to: (-874,874,324,0,0), dda_rate 5642, relative mask 18, distance 18.194263, feedrateX64 3840
30 [534]: Move to: (-874,874,444,0,0), dda_rate 3999, relative mask 18, distance 0.300000, feedrateX64 640
31 [566]: Move to: (-874,874,444,-96,0), dda_rate 2560, relative mask 18, distance 1.000000, feedrateX64 1706
32 [598]: Set build percentage: 100%, ignore 0
33 [601]: End build: flags 0x0
34 [603]: Enable/disable axes: axes bitmask 1F
EOF

The offending code in GPX appears to be in the main processing loop around line 4595 of gpx.c,

else {
    // X,Y,Z,A,B,E,F
    if(gpx->command.flag & (AXES_BIT_MASK | F_IS_SET)) {
        CALL( calculate_target_position(gpx) );
        CALL( queue_ext_point(gpx, 0.0) );
        update_current_position(gpx);
        command_emitted++;
    }
    // Tn
    else if(!gpx->flag.dittoPrinting && gpx->target.extruder != gpx->current.extruder) {
        int timeout = gpx->command.flag & P_IS_SET ? (int)gpx->command.p : MAX_TIMEOUT;
        CALL( do_tool_change(gpx, timeout) );
        command_emitted++;
    }
}

That code triggers when a comment is handled. I assume it's meant for structured comments of significance to GPX. The comment here creates a case of gpx->target.extruder == 0 since there is no extruder target. And since the current extruder is 1, a change tool command is output. Not immediately obvious what the correct fix is here. A hack might be to set the target extruder to the current extruder when initially parsing a gcode comment.

Unaccelerated moves occur at max axial feedrate

Unaccelerated moves such as the first move at (1) the start of a print with (2) an ill-defined position are done using the fastest max feedrate amongst the X, Y, and Z axes. It should be done at the minimum of { requested feedrate, max feedrate of the involved axes}.

What's happening is that get_longest_dda() is confused and returning the smallest of the step periods (microseconds/step) required to effect each of the maximum feedrates for the X, Y, and Z axes. It should be returning the largest of the step periods as that gives the slowest of the maximum feedrates.

Then, in queue_absolute_point() the code should see what the requested feedrate is in terms of steps per microsecond and then compare that to the value returned by a corrected get_longest_dda(). The larger of the two values should then be used in the resulting x3g output.

Source for Windows version?

Dear wingcommander

Is it possible that you share the source code for the windows version of GPX.

All the bests

Possible serial port issue on Linux

When I compile and run this on Linux (I've tried Debian and Fedora on x86 and ARM), there seems to be an issue with serial communications.

On Fedora on an x86 machine, the serial port is opened, the build notification is sent to the printer, but then the process hangs and the printer doesn't move.

On Debian on a Raspberry Pi, the process goes a bit further and the printer starts moving, but dies once the command to heat the build plate of my 2X is sent, the process dies. The build completed notification is not sent to the printer and the HBP remains on

Fedora output (x86_64):

Reading from: butterfly.gcode
Communicating via: /dev/ttyACM1

Debian output (ARM):

Reading from: butterfly.gcode
Communicating via: /dev/ttyACM0
Extrusion length: 0.030 metres
Estimated print time: 10 minutes 51 seconds
X3G output filesize: 663 bytes

OR

Reading from: butterfly.gcode
Communicating via: /dev/ttyACM0
Extrusion length: 0.000 metres
Estimated print time: 10 minutes 32 seconds
X3G output filesize: 267 bytes

M140 vs M109

Makerbot Replicator uses M109 Gcode command to set HPB temp, not M140

X3G binary fails horribly while gcode result is really good.

Hi there,

I've been using GPX for a while now and I am currently testing some slicers. When using skeinforge_50 the result is fine. However when I run GPX the same way for CuraEngine output it messes up the print badly.

It seems like the Z-axis isn't used and the head puts on the new layer while not lowering the bed, to the point where the head is putting the bed under alot of stress.

When I run the .gcode file from ReplicatorG the result is almost flawless.

I can't seem to figure out how to get it to work properly.
Any ideas?

PS: the command Im running is: ./gpx -vpg -m r1d output.gcode input.stl

Sailfish 7.7 serial connection only executes first command?

Hi there,

After playing around with GPX and setting up a serial connection to my FlashForge Creator Pro it seems that it only executes the first command.

here's an example:

// test.gcode
M70 P5 ( We <3 Making Things!)
M72 P1  ( Play Ta-Da song )

When running:

./gpx -vgps -m r1d test.gcode /dev/tty.usbmodem* 

it only shows the "We <3 making things" message and then exits.

However when I do:

./gpx -vgp -m r1d test.gcode test.x3g

And put on the SD card it works fine.

Any ideas on how to fix it?

undefined reference to 'sqrt'

I am building on linux. It looks like there is a problem accessing the math libraries.

make --trace
Makefile:24: update target 'getopt.o' due to: getopt.c
cc -c -w getopt.c -o getopt.o
Makefile:24: update target 'gpx.o' due to: gpx.c
cc -c -w gpx.c -o gpx.o
Makefile:24: update target 'gpx-main.o' due to: gpx-main.c
cc -c -w gpx-main.c -o gpx-main.o
Makefile:20: update target 'gpx' due to: getopt.o gpx.o gpx-main.o
cc -lm getopt.o gpx.o gpx-main.o -o gpx
gpx.o: In function `magnitude':
gpx.c:(.text+0x1c4b): undefined reference to `sqrt'
gpx.o: In function `mm_to_steps':
gpx.c:(.text+0x2256): undefined reference to `round'
gpx.c:(.text+0x227d): undefined reference to `round'
gpx.c:(.text+0x22a4): undefined reference to `round'
gpx.c:(.text+0x22f4): undefined reference to `round'
gpx.c:(.text+0x2350): undefined reference to `round'
gpx.o:gpx.c:(.text+0x2390): more undefined references to `round' follow
collect2: error: ld returned 1 exit status
Makefile:20: recipe for target 'gpx' failed
make: *** [gpx] Error 1

here's my version

uname -a
Linux 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

How to compile under windows

Are there any instructions on how to compile under windows. I use 3dSimplify software that implements this software to convert for Replicator 2x printer. The latest version has a Heated Build Plate max temperature setting of 120 degrees. I need to remove that max temp or change it so i can heat my build plate to 130C. This was not an issue in previous versions. The issue is in gpx.h line 66 which has this line #define HBP_MAX 120. I have cygwin installed but don't know the commands required to compile a version without the limit.

Source code only?

Previously I found a direct download for Mac, reporting as version 1.5

This fails badly on 9/10 prints with Replicator2, so I was hoping to try the 2.0 version here from github - but on downloading, it appears to only have the raw source code.

Is there anywhere I can download GPX itself?

-g option is not documented

This page lists a '-g' option but does not document what valid settings are or how to choose the correct one for your machine.

Can't heat the build plate of the 2X

Hi, when trying to print a valid 2X gcode file I get the following error:
Semantic warning: M134 cannot select non-existant heated build platform T0

Any ideas?

Invalid tests for 0xD5 in received s3g/x3g frames

Since compiler warnings were disabled with -w, these two important warnings went unnoticed,

gpx.c:5445:38: warning: comparison of constant 213 with expression of type
'char' is always true [-Wtautological-constant-out-of-range-compare]
if(gpx->buffer.in[0] != 0xD5) {
gpx.c:5460:42: warning: comparison of constant 213 with expression of type
'char' is always false [-Wtautological-constant-out-of-range-compare]
if(gpx->buffer.in[0] == 0xD5) break;

Ooops. A fix is to cast to (unsigned char)

Circles perimeters shaking

Hello, my FlashForge printer is shaking in small circles, mainly in the internal perimeters. I tried to use very low values ​​of acceleration but for linear movements acceleration is ok while small circles continues shaking (something minor but continual). I've tightened all belts and screws...

It gives the feeling of skip lines of code G, or maybe not had time to process as many coordinate changes so quickly as in the circles?

I uploaded a video so you can see and hear the problem is in the perimeters of the circles. Using MakerWare seems to be ok, but using GPX produce shaking.

I use "gpx file.gcode" to produce the .x3g file and my .ini file configured as:

;
; gpx.ini
;
; gcode to x3g conversion configuration file
;

;************ POST PROCESSING OPTIONS ************

[printer]

; MACHINE TYPE
;
; specify the machine definition using a pre-defined built-in type identifier
;
; NOTE: settings are order dependnet, so always start by settng the machine type
;
; 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

machine_type=r1d

; GCODE FLAVOR
;
; specify the gcode flavor
;
; reprap = M109 Set Extruder Temperature and Wait
; makerbot = M109 Set Build Platform Temperature (Same as M140)

gcode_flavor=makerbot

; BUILD TEMPERATURE
;
; override the gcode build plate temperature
; 0 = disabled

build_platform_temperature=0

; BUILD PROGRESS
;
; generate gcode for the build progress
; this should be enabled for slic3r and kisslicer
; 1 = enabled
; 0 = disabled

build_progress=1

; DITTO PRINTING
;
; print simultaniously with both nozzles
; 1 = enabled
; 0 = disabled

ditto_printing=0

; FILAMENT DIAMETER
;
; set this to the filament diameter setting used in the slicer
; 1.75 = default

slicer_filament_diameter=1.75

; SD CARD PATH
;
; if an SD card is inserted the x3g file will be written there
; uncomment to enable and substitute the name of your SD card volume

sd_card_path=F:\

;************ RIGHT EXTRUDER ************

[right]

; ACTUAL FILAMENT DIAMETER
;
; override gcode for the right filament diameter
; 1.75 = default
; 0 = disabled

actual_filament_diameter=0

; ACTIVE TEMPERATURE
;
; override gcode for the right active temperature
; 0 = disabled

active_temperature=0

; STANDBY TEMPERATURE
;
; override gcode for the right standby temperature
; 0 = disabled

standby_temperature=0

;************ LEFT EXTRUDER ************

[left]

; ACTUAL FILAMENT DIAMETER
;
; override gcode for the left filament diameter
; 1.75 = default
; 0 = disabled

actual_filament_diameter=0

; ACTIVE TEMPERATURE
;
; override gcode for the left active temperature
; 0 = disabled

active_temperature=0

; STANDBY TEMPERATURE
;
; override gcode for the left standby temperature
; 0 = disabled

standby_temperature=0

If i setup very slow acceleration seems that the extruder is not following the rounded path of the circle. View this video : https://www.youtube.com/watch?v=Ay6Nj9Ukdjs&list=UU1d_Q8QR1mhUhq3L6Ko6_6w

And this one is in normal acceleration, it works perfectly on the linear filling but shaking on perimeters: https://www.youtube.com/watch?v=MuQMbVjXw8E&feature=youtu.be

Thanks for the great work!!

Missing tags in repository

Judging by your thingiverse.com page, you've made a few releases, but I don't see any tags or source tarballs available for download. Could you at least push the tags up to the repository so I can figure out which revision to package for Debian?