On 25 Apr 2013 , at 11:56 AM, Simplify3D wrote:
> Perhaps "proprietary" isn't the best word. 3D printers, CNC machines, and
> a wealth of other equipment all share a common standard already; G-Code.
> The x3g format is only used by MBI printers and basically creates this
> extra step for anyone who is using the G-Code format.
FWIW, it was also used for a while in the RepRap world. However, being
an extra step and barrier, it was abandoned. Then things caught up and
now its again provides benefit. For example, Marlin's acceleration planner
is cpu bound now on 8bit, 16 MHz AVRs and the slicers are having to
compensate for that to prevent blobbing/zits in regions with lots of
small fine detail. There's actual benefit to not having to do some
of the parsing and computations required of gcode (parse, convert to
steps, compute distances -- squares and square roots -- needed by
the accel planner, do feed rate limiting, etc.). 'tis one of the
reasons the accel planner in Sailfish is 5 - 10x times faster than
Marlin and doesn't have the same issues being CPU bound.
OTOH, if Erik or other Marlin maintainers were to add s3g support to
Marlin, I'd consider them crazy: they should instead spend their time
on supporting faster, better uProcessors. (Bernhard has had a version
of Marlin on an ARM for a while, for instance.) Which is to say, that
s3g/x3g still has benefit -- as a stop gap measure. I for one would
like to see it disappear. I even started on a Sailfish which consumed
straight gcode but then realized that there were better uses of my time.
If/when there's better electronics hardware to put Sailfish on, then
(1) first get Sailfish on it, and then (2) go back to gcode. BUT, it
would also be real tempting to use NIST standard gcode and not the
almost standard gcode which is being used on DIY 3D printers.
Dan