.gcode versus .s3g - MakerBot Operators

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion .gcode versus .s3g
Received-SPF: neutral (google.com: 64.30.218.170 is neither permitted nor denied by best guess record for domain of dan.new...@mtbaldy.us) client-ip=64.30.218.170;
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Subject: Re: [MakerBot] .gcode versus .s3g
From: Dan Newman <dan.new...@mtbaldy.us>
In-reply-to: <F80A7138-447F-4603-B603-2A9AA7B3879C@mtbaldy.us>
Date: Sun, 18 Nov 2012 11:34:27 -0800
Message-id: <B2F80A1D-1960-4B3B-BC5F-6A989C0C704A@mtbaldy.us>
References: <9b838be4-d412-4cf7-958d-75e944e2eee1@googlegroups.com>
 <c5e011ba-b103-4859-8408-a26de6a38c35@googlegroups.com>
 <7d261b11-092c-4d9e-a421-2813baec398a@y8g2000yqy.googlegroups.com>
 <2ffe1b57-cebc-44b0-ae51-3801797cf4e3@googlegroups.com>
 <758bfdd7-e1e9-4a7d-8759-895d06998e72@googlegroups.com>
 <df80af7e-3e73-4615-909e-a645c43553fc@googlegroups.com>
 <08e317c8-b8f3-4752-98bc-0fca5ea3b349@googlegroups.com>
 <F80A7138-447F-4603-B603-2A9AA7B38...@mtbaldy.us>
To: makerbot@googlegroups.com

P.S. Folks who have looked at the Sailfish firmware know that inside it's
doing fixed point math in the accel planner and not floating point.  So,
some/most of the below calcs are actually faster -- fewer cycles -- for
Sailfish in reality.  That said, on a Rep 1 with the extruder control
no longer offloaded to a separate processor and the need to deal with five
1/16th stepping axes, we found that saving 1000+ cycles per gcode move
command was still very benficial.

Dan

On 18 Nov 2012 , at 11:09 AM, Dan Newman wrote:

> Here's my take on the issue.  The big savings isn't so much binary s3g vs. gcode,
> but rather the computations which RepG offloads from the uProcessor as part of
> generating the s3g.
> 
> In generating the s3g, RepG performs some floating point calculations which
> otherwise would be done on the uProcessor
> 
> 1. Convert units of millimeters to steps.  The uProcessor does this as multiplies:
> one per axis.  If it's smart it only does it for axes which have to move in order
> to execute the instruction.  Typically that will be three axes (x, y, extruder)
> but worst case it's five on a Rep 1.  For an AVR with built in integer multiply,
> that takes 140 cycles per multiply.  So typically, that's 420 cycles and worst
> case it's 700 cycles.
> 
> 2. Determine the distance involved in the move.  Since different axes may have
> different steps per mm, you really need to do this calculation in units of mm.
> If you do it in units of steps you hit what I call the "non-square pixel problem".
> (Comes up when doing dithering for things like facsimiles which have a vertical
> axis in units of lines per inch and a horizontal axis in pixels per mm -- gotta
> love compromise in standard bodies -- and the aspect ratio of the pixel size is
> either 1.04 or 2.07, depending upon the resolution.)
> 
> Anyhow, for the distance calc you have one multiply per axis involved, n-1 additions
> where n is the number of axes involved, and a sqare root.  That's
> 500 + (n-1)*110 + n*140 cycles and for a typical case (n=3) and worst case (n=5), that's
> 1140 and 1640 cycles, respectively.
> 
> 3. Finally, there's decomposing the feed rate (magnitude of the velocity vector)
> into the speed components along each axis and then applying per axis feed rate
> limits.  I don't recall how that breaks down, but it's easily 150 cycles for
> typical case.
> 
> So, typical case the total cycles is 1710 cycles and worst case 2490 cycles.
> On a 16 MHz processor, that's 0.11 ms for typical and 0.16 ms for worst case.
> 
> That may not sound like a lot, but there's a lot else going on on a Rep 1.
> For instance at ~95 steps/mm for X & Y, to move at 120 mm/s, that's 11400
> steps/s and if the stepper interrupt takes on average 60us, that's 0.684 s.
> That leaves only 0.316 seconds for everything else: monitoring three temp
> sensors, updating the LCD display, managing USB comms, and acceleration
> planning.
> 
> With Sailfish, we've found that saving that pittance of 0.11 - 0.16 ms
> actually helps when doing prints with lots of very tiny line segments (fine
> detail): it helps reduce the incidents of the acceleration planner falling
> behind.  And, we actually introduced a new accelerated move s3g command
> which offloads a bit more work onto RepG.  Actually, what it did was provide
> a s3g move command more apropos to acceleration.  The old move commands
> were geared towards non-accelerated moves and just said: execute these
> steps at this step rate.  You'd have to work backwards and figure out
> what the target feed rate was in mm/s so that you could then impose
> max accels in units of mm/s^2.  (No point in doing things in units of
> steps and steps/s^2 owing to the non-square pixel problem.)
> 
> Now, s3g isn't needed to do the above: it's possible to send the gcode
> commands using units of steps instead of mm and to add a new G or M
> command which provides the details useful to an accelerated planner.
> So my point isn't that s3g is necessarily better than gcode.  Rather
> my point is that offloading calc onto your desktop (which has built
> in floating point and a much faster processor) is beneficial.  And
> that's what I think RepG is bringing to the table and the use of
> s3g can be argued to be a side effect.  (You can still argue the utility
> of that side effect, but I think it's a secondary benefit.)
> 
> Dan
> 
> -- 
> You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.
> To post to this group, send email to makerbot@googlegroups.com.
> To unsubscribe from this group, send email to makerbot+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/makerbot?hl=en.
>
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
