search

whpthomas / GPX

Gcode to x3g conversion post processor
GNU General Public License v2.0
98 stars 16 forks source link

X3G binary fails horribly while gcode result is really good. #19

Open dennisdevulder opened 9 years ago

dennisdevulder commented 9 years ago

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

markwal commented 9 years ago

Well, you want -r instead of -g for cura since it ouputs reprap flavor. Though most of those differences are to do with temperatures and wait behaviors not with z-axis.

Also gpx can't do anything with an stl so that second parameter is the output name which should be .x3g

./gpx -v -r -m r1d input.gcode output.x3g

There is a decompiler tool in the zip package you can use to look at the x3g and look for the z positioning. Do you have an example (hopefully small) gcode file that demonstrates the issue? You could paste it into hastebin.com or pastebin.com or a gist.github.com and paste a link here.

I don't think Henry is active here any more so you might want to use the google group. https://groups.google.com/forum/#!forum/gpx-converter

markwal commented 9 years ago

BTW I've got gpx working with the new Cura 15.06. It takes some work due to the profile settings not editable in Cura. My guess about your problem though is that the start gcode is messed up somehow and gpx doesn't know where you are enough to give the right absolute point in the x3g output.