GPX, GpxUi and OctoPrint-GPX release: 2.5.2

[Mark Walker]

There's a new release of GPX available.  A few of the changes are:

* Apple Mac builds for GPX and GpxUI including homebrew support

* Some serial communication fixes including for improved pause@z

* Removed heated bed cap (now we're relying on the firmware)

* More Debian platform compatibility (Thanks Chow Loong Jin!)

* May be drop-in compatible with S3D (sorry, I probably shouldn't list because I can't test it since I don't have S3D, but... I added support for the -u command line parameter according to info from S3D)

Plus, now all three forms of GPX release use the same release numbering :-)

[Mark Walker]

I probably shoulda put urls:

GPX: https://github.com/markwal/GPX/releases

GpxUi: http://markwal.github.io/GpxUi

OctoPrint-GPX: It's in the plugin manager in OctoPrint, but also auto-updates (or at least, auto-offers to update)

I haven't made auto updates work for GpxUi on Mac and Linux, yet, the update command just has buttons that don't work. :-(

[TobyCWood]

A quick question. Should one simply replace the GPX that came with S3D in the S3D folder?

Anything else needed?

[Dan Newman]

On 06/05/2016 12:20 PM, TobyCWood wrote:
> A quick question. Should one simply replace the GPX that came with S3D in the
> S3D folder?
> Anything else needed?

Well, FWIW, here's what I do and why. Starting with why. If you replace
the GPX in S3D, then you have a maintenance issue as regards S3D. When you
update S3D, you have to remember to replace GPX. And you have no idea if S3D
will, in an update, expect some new, undocumented behavior of GPX. And since
S3D hides any error/warnings from GPX, you won't know if there's an issue unless
it is very serious (e.g., no .x3g file produced).

So, what I do is put my GPX somewhere under my control and where S3D won't touch
it, won't replace it in an upgrade, and generally will remain ignorant of its
existence. I then untick the box in the slicing profile to automatically produce
X3G. And then I provide my own post-processing command in the box below that tick
box. The command I provide tells S3D exactly how to run my squirrelled-away copy
of GPX using the switches I want.

Dan

[Dan Newman]

On 07/05/2016 5:54 PM, tramalot wrote:
> What does the "cxysz" relate too?

cxy = Core XY
cxysz = Core XY slow Z axis

Dan

[Dan Newman]

On 07/05/2016 5:54 PM, tramalot wrote:
> What does the "cxysz" relate too?

Also, from the command line you can get a description,

% gpx -?
...
MACHINE: the predefined machine type
some machine definitions have been updated with corrected steps per mm
the original can be selected by prefixing o to the machine id
(or1, or1d, or2, or2h, orx, ot7, ot7d)
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
cxy = Core-XY with HBP - single extruder
cxysz = Core-XY with HBP - single extruder, slow Z
cr1 = Clone R1 Single with HBP
cr1d = Clone R1 Dual with HBP
r1 = Replicator 1 - single extruder
r1d = Replicator 1 - dual extruder
r2 = Replicator 2 (default)
r2h = Replicator 2 with HBP
r2x = Replicator 2X
t6 = TOM Mk6 - single extruder
t7 = TOM Mk7 - single extruder
t7d = TOM Mk7 - dual extruder
z = ZYYX - single extruder
zd = ZYYX - dual extruder
fcp = FlashForge Creator Pro
...

[Mark Walker]

Are you printing directly from Simplify3D over USB or via x3g file on SD card?

Could you put a gcode and x3g file that demonstrates the problem on a share somewhere and post the link back here?

One possibility is that a change I made is erroring out on the parameters Simplify3D is sending in.  Because S3D eats all of the error messages you may have ended up with a truncated x3g, just the part through the start gcode and nothing else.

If you hook it up the way that Dan did (put your old back and then call the new gpx directly as a post process), I think you get to see the error messages.  I'm not certain because I don't have S3D.

On Sunday, May 8, 2016 at 8:01:21 PM UTC-7, JF Kansas wrote:

So a few months ago when a release of the GPX.exe was released, I backed up the old file by changing the extension to old and put the new one in the Simplify3d directory. Everything worked just fine with no changes. 

This time I did the same thing. I changed the .exe to old and put the new one in that was released a few days ago.

I ran a file and everything sliced/converted as normal, however when I ran the file everything worked up until the point where it was supposed to print something. It even did the purge at the right front corner and nozzle wipe. Then it just sat there heated and not moving. Probably a kind of dangerous situation since if you walked away or left the area expecting it to just print as usual it could be just sitting there cooking filament. 

What could of changed?

[Dan Newman]

> If you hook it up the way that Dan did (put your old back and then call the new
> gpx directly as a post process), I think you get to see the error messages.

Nope: it eats them. And the way S3D runs the supplied command seems to
defeat redirecting stdout and stderr within the supplied command. I've
had to make a shim shell script, let S3D run it, and have the script then
run gpx with "> blah.log 2>&1" redirection.

Dan