Message from discussion .gcode versus .s3g
Received: by 10.50.153.199 with SMTP id vi7mr4189121igb.0.1353267264127;
Sun, 18 Nov 2012 11:34:24 -0800 (PST)
Received: by 10.50.40.134 with SMTP id x6ls2291261igk.21.canary; Sun, 18 Nov
2012 11:34:21 -0800 (PST)
Received: by 10.66.86.6 with SMTP id l6mr2632414paz.11.1353267261368;
Sun, 18 Nov 2012 11:34:21 -0800 (PST)
Received: by 10.66.86.6 with SMTP id l6mr2632413paz.11.1353267261356;
Sun, 18 Nov 2012 11:34:21 -0800 (PST)
Received: from mtbaldy.us (host-64-30-218-170.static.linkline.com. [22.214.171.124])
by gmr-mx.google.com with ESMTP id yl8si1226508pbc.1.2012.11.18.11.34.20;
Sun, 18 Nov 2012 11:34:20 -0800 (PST)
Received-SPF: neutral (google.com: 126.96.36.199 is neither permitted nor denied by best guess record for domain of dan.new...@mtbaldy.us) client-ip=188.8.131.52;
Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 184.108.40.206 is neither permitted nor denied by best guess record for domain of dan.new...@mtbaldy.us) smtp.mail=dan.new...@mtbaldy.us
Content-type: text/plain; CHARSET=US-ASCII
Received: from mac-dicky.mtbaldy.us (mac-dicky.mtbaldy.us [10.30.0.206])
(Sun Java(tm) System Messaging Server 7u3-12.01 64bit (built Oct 15 2009))
with ESMTPA id <0MDP00D4N7P71...@central.mtbaldy.us> for
email@example.com; Sun, 18 Nov 2012 11:34:19 -0800 (PST)
Subject: Re: [MakerBot] .gcode versus .s3g
From: Dan Newman <dan.new...@mtbaldy.us>
Date: Sun, 18 Nov 2012 11:34:27 -0800
X-Mailer: Apple Mail (2.1283)
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.
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
> 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.)
> You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.
> To post to this group, send email to firstname.lastname@example.org.
> To unsubscribe from this group, send email to email@example.com.
> For more options, visit this group at http://groups.google.com/group/makerbot?hl=en.