[BUGLIKE FEATURE REPORT] Unconventional gcode causing problems with third party tools

Support for UP Software. To report a bug, post with a title [BUG REPORT]. To request a feature, post with a title [FEATURE REQUEST]
Post Reply
pleppik
Posts: 336
Joined: Sun Dec 11, 2011 2:14 pm

[BUGLIKE FEATURE REPORT] Unconventional gcode causing problems with third party tools

Post by pleppik » Thu Jan 18, 2018 3:54 pm

I've successfully gotten my printer to accept gcode from a third party slicer. It works, but there's some very unusual ways the TierTime gcode works as compared to how open source printers work, and these are causing some problems for me when trying to use some 3rd party tools.

Specifically:
1. The conventional units for extrusion distance on most printers is in mm of filament. The gcode that Up expects uses some other unit (this is what requires the extrusion multiplier of 20). I've got some postprocessing software that gets really confused by the large extrusions present in the gcode for my printer.

2. The coordinate systems most printers use puts the platform at Z=0, while my Up puts Z=0 at the top of the build volume and printable Z values are negative. This is also confusing some software I'm trying to use which assumes that the print bed is at Z=0.

Is it possible to update the Up software so it will accept conventional gcode, or at least make this an option? Otherwise, the only way I can use these tools with my Up is to write a gcode preprocessor and accept a really cumbersome workflow.

Owen Sparks aka Marksman
Posts: 610
Joined: Tue Mar 15, 2016 9:56 am

Re: [BUGLIKE FEATURE REPORT] Unconventional gcode causing problems with third party tools

Post by Owen Sparks aka Marksman » Thu Jan 18, 2018 4:25 pm

Yeah, I second this.

Simplify3d have rewritten some of their stuff specifically to make it compatible with the weird way TT have set up their conventions but we cant expect this from every vendor.

Hopefully the political decision by TT to support GCODE was the hard bit, now it's up the the engineer(s) to implement it well. We've waited 3 months for "phase 2" of implementation so I hope it's actively being worked on but have no idea if that's the case.

The bigest thing for me is opening up the printer control to Simplify3D so we can run propper nozzle detect and bed leveling. Having nozzle height hard coded into the GCODE is daft.

Here's hoping for good things to come.

Cheers,

Owen S.

pleppik
Posts: 336
Joined: Sun Dec 11, 2011 2:14 pm

Re: [BUGLIKE FEATURE REPORT] Unconventional gcode causing problems with third party tools

Post by pleppik » Fri Jan 19, 2018 1:59 am

I found a solution to #2 at least. The TierTime gcode interpreter respects the M206 command (coordinate offset) so you can put Z=0 at the bed level by inserting the following into your start gcode:

Code: Select all

M206 Z-XXX.X ; nozzle offset so the bed is at 0 (where XXX.X is your bed height)
This isn't optimal because it means calibrating Z height requires changing your starting gcode in your slicer, but it at least lets you use tools (like Cura and Chroma) which require the bed to be at Z=0.

brunningm
Posts: 210
Joined: Fri Jul 21, 2017 9:44 am

Re: [BUGLIKE FEATURE REPORT] Unconventional gcode causing problems with third party tools

Post by brunningm » Fri Jan 19, 2018 5:46 am

Interesting. I wonder if this has anything to do with the odd issue of prints starting 2mm above the bed no matter what you set z-height and offset too.

Post Reply