Ditto print feedback

[Cymon]

I may be the only person using this feature in this way regularly, but I have some feedback for the ditto print option. First of all I love having this option available to me without using an exe. That's awesome. But I don't know how much I love having it as a menu option on the board for a couple of reasons. First of all, it's easy to forget it's on and start a print not set up for dual extruders (ex http://joesmakerbot.blogspot.com/2012/11/ditto-printing-on-sailfish.html ). Secondly, if I'm running filament with two different diameters I miss out on the accuracy available that I need so much to make my chess sets work.

One solution I think would be a plug in for skienforge and bind the  to the s3g files. Settings to set the filament diameter for each extruder. That's one idea.

The other option is, and this is kinda revolutionary, the ability to set the filament diameter in the firmware on the menu. Hear me out. Imagine not having to re-build the gcode just because you bought new filament. I don't know everything that is effected by filament diameter, I suspect it's more than I think, but what if filament diameter were built into the gcode at 1 and everything effected by filament diameter scaled by the setting in the firmware. That would also open up the possibility of putting a filament measuring device on the incoming filament and adjusting on the fly. The biggest bane of 3D printing fixed instantly.

[Adan Akerman]

That would be pretty amazing: setting the filament diameter on the 'bot, seriously helpful. All these files I've sliced that can only be used with one filament... what a great fix. 

I'm assuming it's a processor-intensive thing, to compute (or re-compute) the amount to extrude relative to a move. But Dan & Jetty, if that could at all be an option it would top my Christmas wish list.

--
 
 

[Shawn]

I don't think this is feasible with the current software/electronics
approach. I'm not an expert here, so correct me if I'm wrong, but...

The filament width is used to determine how many steps are required to
extrude the required volume of plastic. This translates into GCode
instructions for "turn the extruder this many turns". Only the software
has any concept about the required volume of plastic.

To do as you suggest, the firmware would need to know the required
volume of plastic - not just "turn the motor this many steps". This
moves a fair amount of the software functionality down to the hardware.
Which means a substantial change in the way things are done now.

BUT, I think if this were ever done, we'd likely see a huge improvement
in the tech. This would allow things like dynamically measuring the
filament width on the fly. I think there would be other long term
benefits to this approach as well. I'm just not sure if anyone wants to
blaze that path because of the substantial work required when the
current path arrives at almost the same destination.

My thoughts.

> --
>
>

[Cymon]

On Thursday, December 13, 2012 10:59:11 AM UTC-7, Shawn wrote:

I'm not an expert here

That has been the only response I've heard to this. Just once I'd like someone who was an expert to respond to this.

Here's my thought, filament diameter is just a variable that percolates through the system. So theoretically it's effect in the final output could be predicted and here's how I'd do it. Set filament diameter to 1.0 and slice some shape. Set filament diameter to 10 and slice another. Compare the resulting gcodes and see what's different. If there are numbers that are different then take difference, find the halfway point, create a prediction, and slice again with a filament diameter of 5. If you're predictions are correct then you have a list of variables that are directly related to filament diameter and what commands they apply to. Easy.

Actually, that is pretty easy. Lemme give that a shot...

[Laird Popkin]

You're right, to do the volume calculations on the fly would likely be too much math.

But I think that as long as you're only making small adjustments, it might be "close enough" to scale the number of steps based on the square of the difference in diamater. That is, if you sliced for 1.75mm and measure 1.80mm, that's about 10% more plastic per step, so subtracting 10% of the plastic move steps would (roughly) give you the right volume of plastic. Yes, it won't be exactly right, but it might be close enough, I'd guess. Still, I'd think that you're better off slicing at about the right filament size and adjusting a little up or down from there, rather than slicing at an arbitrary size and scaling everything by a lot.

--

[Dan Newman]

On 13 Dec 2012 , at 11:46 AM, Cymon wrote:

>
>
> On Thursday, December 13, 2012 10:59:11 AM UTC-7, Shawn wrote:
>>
>> I'm not an expert here
>>
>
> That has been the only response I've heard to this. Just once I'd like
> someone who was an expert to respond to this.

I'm not an expert on this either, but I was planning on responding after first
seeing just where and how SF uses the diameter. And the usage may be non-trivial.
However, the question in my mind is whether or not there's some simple fixup which,
when done while printing, is a useful 85% solution and overall improvement. For
all I know, a very empirical approach of "the diameter has changed 5%, take
the square of the difference into account, the distance from the measurement
point to the melt chamber (and hence the delay until the effect is seen), and
then tweak the steps ever so slightly keeping a running tab on steps needing
to be added/removed as you transition from one line segment to the next.

Of course, without a measurement device hooked up to the extruder, it's hard
to actually test anything. But the intriguing bit is that Sailfish already
has a means of tracking net added/removed extruder steps.

Dan

[Cymon]

Dan, you are exactly the sort of not-a-"Not an expert" that I was hoping would chime in on this.

Okay, so here's the exciting bit. I did the experiment outlined above and the difference in the gcode files is that from the 1.0 filament the E values on all the G1 lines is divided by the square of the new filament. I didn't expect it would be division, but that means that as long as the diameter of the filament is larger than 1 we're not losing any significant digits. So I tried again with 1.7 and sure enough every E value I tried was the E value of the 1.0 gcode divided by 1.7^2 or 2.89, rounded to whatever significant digits we want. It is remarkably consistent.

So theoretically all the firmware would have to do is take the square of the filament diameter, store it, and do a little division over ride on every G1's E value. Of course if we want future on-the-fly adjustments to be made then we can't precalculate that square and it we'd need a buffer, but in my mind that's a problem for a future day. Also, I don't know how ditto is handled so if there were a diameterL and diameterR value would it be possible to adjust the E values separately?

This is gcode, not s3g code. If my understanding is right, tho, this will translate over directly, right? I totally volunteer to Guinea pig a new firmware that implements this.

[Dan Newman]

On 13 Dec 2012 , at 1:47 PM, Cymon wrote:

> Dan, you are exactly the sort of not-a-"Not an expert" that I was hoping
> would chime in on this.
>
> Okay, so here's the exciting bit. I did the experiment outlined above and
> the difference in the gcode files is that from the 1.0 filament the E
> values on all the G1 lines is divided by the square of the new filament. I
> didn't expect it would be division, but that means that as long as the
> diameter of the filament is larger than 1 we're not losing any significant
> digits. So I tried again with 1.7 and sure enough every E value I tried was
> the E value of the 1.0 gcode divided by 1.7^2 or 2.89, rounded to whatever
> significant digits we want. It is remarkably consistent.

Most interesting. Thanks for doing that experiment.

> So theoretically all the firmware would have to do is take the square of
> the filament diameter, store it, and do a little division over ride on
> every G1's E value. Of course if we want future on-the-fly adjustments to
> be made then we can't precalculate that square and it we'd need a buffer,
> but in my mind that's a problem for a future day. Also, I don't know how
> ditto is handled so if there were a diameterL and diameterR value would it
> be possible to adjust the E values separately?
>
> This is gcode, not s3g code. If my understanding is right, tho, this will
> translate over directly, right?

Yes basically. There is a round off collection issue. The gcode uses
fractional values measured in mm. The s3g uses steps which have to
be integral values (integers). And in producing the s3g, RepG does some
roundoff accumulation (i.e., change 3.4 steps to 3 here and the next time
even though we thought we needed 6.3 add in the .4 and round that up to
6.7 = 7 steps noting a carry forward now of -0.3 steps).

Then in the firmware there will be a similar issues: fed integer values (steps),
do fractional computations on them causing round offs when going back to integer
steps. And if one isn't mindful of how RepG did the roundoff accumulation and
does something a bit different, you can find yourself with interesting print
artifacts (e.g., why's there this unexpected spiral pattern on the surface?).

> I totally volunteer to Guinea pig a new
> firmware that implements this.

I'll put it on the to do list. However, I'm not too sure how well this would
actually play into "Ditto" printing which tries to be really dumb and just
make the left hand do *exactly* what the right hand is doing (or vice versa).
But it's definitely useful in a variety of contexts and not just ditto printing
with dissimilar filaments.

Dan

[Laird Popkin]

+1 to being able to adjust for filament-diameter via the control panel. It's very nice workflow to be able to slice to SD card once, and then play with print parameters (temp, diameter, speed) on the printer to tweak until the particular filament is dialed in. At least for me - I keep my printer far from my computer, which perhaps others don't do. :-)

Right now we can override temperature, which has been a real eye-opener. This discussion is about filament diameter, which would also be good.

That leaves speed. Would it be easy to adjust printed speed from the control panel? The Ultimaker does this via a control knob in real-time, which is perhaps overkill, but when calibrating for new filament, it would be great to be able to dial print speed up or down interactively while printing, as it would make the whole process much faster.

Dan

--

[Dan Newman]

> That leaves speed. Would it be easy to adjust printed speed from the
> control panel? The Ultimaker does this via a control knob in real-time,
> which is perhaps overkill, but when calibrating for new filament, it would
> be great to be able to dial print speed up or down interactively while
> printing, as it would make the whole process much faster.

That one's not likely to happen. At issue is that Marlin spends time doing
all the velocity rate limiting so as not to exceed any of the per axis
feed rates. (And Marlin consumes gcode and thus has to do that.) That
means that Marlin can on-the-fly change the speeds but not violate
the per axis feed rates. And doing that eats of processing cycles which
can be spent doing other things.

Sailfish, otoh, consumes s3g and has the luxury of letting RepG do the
per axis feed rate limits as it produces the s3g. Thus, Sailfish doesn't
do speed limits. (Jetty 3.x used to.) We'd have to go back and put code
back in to impose per axis feed rate limits. And that would then
slow down the acceleration planner. While that might be okay on a late
model Thing-o-Matic which has the code space for the extra code and
isn't crippled by having excessive resolution (i.e., doesn't have
to step twice as many times as the Rep 1), this would definitely
have an impact on Rep 1s.

Net, net, I don't see this as being a priority.

Dan

[Joey]

Before I had Marlin with the ditto function (which I think is a great idea!) I wrote a program to do the same thing on the gcode files. It takes in a single extruder file and outputs a dual extruder file. It also optionally handles using different filament diameters on each extruder. You give it the input file name, the filament diameter used for that file, and the diameter to be used on the other extruder.. It does the rest.

It's at:  http://www.thingiverse.com/thing:24195

Joey

[Cymon]

And thank you very much for your exe. That's the one I used. A lot. And I liked having the doubling on the gcode (hence the reason I mentioned it in the first post) and would have love to see this translated into a python plugin for skienforge.

[Andy]

Having this capability in the firmware would also open the door for a very nice filament diameter auto-calibration script.  It could print an array of cubes, each cube assuming a different filament diameter.  The best looking cube = the filament diameter to use.  You could define a range at the start of the script, say 1.7 to 1.9 or something, and each cube would be a .n increase in assumed filament diameter.

I would pay good money for this feature  (filament diameter adjusting) to be added to sailfish.  Hell, I'd learn gcode so I could write the script I just described! :) (provided there was a command added to tell the firmware to switch to a new diameter value)

I think jetty mentioned there was some script like this in the past, but it required multiple discreet prints , not performing all "wedges" of diameter in one printing session.

I'm loving this idea Cymon!

-Andy

--
 
 

[Lincoln]

I use the ditto print for about 80 percent of the things I have been making.  It is soooooo much easier and gives much better results than when I was doing it without sailfish.

While I like your idea of having it be a tag in the SG3 file, if that couldn't be done, if there was just a change in the LCD menu on the bot that went like this it would be helpful:

Print from SD

Preheat

Utilities

DOUBLE Print from SD

By doing it that way you would just go into the menu at the top for regular and the one at the bottom for ditto print.  I think it would make it a lot easier to not make the mistake I've made many times and double printed when I didn't mean to, and visa-versa.

Lincoln

[Jetty]

A bit of history about Ditto Printing. Ditto Printing was intended to
just be something crude
to print multiple objects, that could be switched on say at a show to
print multiple copies
for people where quality due to variance in filament diameter wasn't
too much of an issue.

There were a few design choices that were made that were less than
ideal, but made for a
good reasons.

1. Filament width was ignored and the steps were just duplicated from
one extruder to another. The reason was to avoid adding extra
calculations to the
main interrupt.

2. It was implemented as a firmware switch instead of the correct way
to implement
it which would have been an SF plugin. The reason for this was
because it was
more convenient as a firmware switch and didn't require rebuilding the
s3g. Doing
it in SF would have allowed for filament diameter variance
calculations. One way to mitigate
this slightly is to pick the midpoint between the 2 filament diameters
and generate
with that size.

3. I was particularly unhappy with not popping up a reminder for it
being on,
from a UI point of view.
The reason I didn't was because we were very slim on available space
on the Replicator
and popping up extra menus took a lot of extra space. (Saying that
now though, we could probably
play a tune instead when it was on at the beginning of a print and
that would be less space).
Ultimate decision was that the user should take some responsibility
for remembering it's on
if they switched it on. (And yes, I've forgotten it's on too :-) )

4. It's completely untested on the Thingomatic and may or may not
work. The plan was to get
a dual extruder for the ToM, but that fell through when Qu-Bd failed
shipped me a keyboard
membrane instead of the ToM extruder. They did make good in the end,
but I don't have that dual
for the ToM. Thinking about it now, dual extruder for the ToM takes
away from the available printing
space on the ToM. If you have a dual ToM and it works, or doesn't,
please let me know.

> Print from SD
> Preheat
> Utilities
> DOUBLE Print from SD

I love that idea. The only issue with that, is that you'll then lose
the ability to Ditto print
from RepG via the Ditto Print setting.

[Jetty]

Also meant to say, regarding the filament diameter. As Dan said,
maybe something could be done via a similar approach to the Advance
mechanism, but it require more thought and could end up slowing down
the main interrupt and reducing the print quality.

Advance (and pressurize / depressurize), add on and remove steps to
the s3g
stream of steps. A similar approach could be use with Ditto, however
we'd need to avoid floating point calcs for speed reasons (i.e. add/
subtract this percentage).

Also there could be aliasing issues as partial steps are calculated
across s3g moves
in volumetric.

Plus it would need to be stored in another variable, as those steps
would need to be
distinguished from advance/pressure steps.

In short, I can't say for sure it won't work, but I think it's likely
to cause issues, or enough
issues that the calculations involved to fix / work around them exceed
what we
can do on the Arduino with it's lack of horsepower before starting to
effect the print quality significantly.

[Andyways]

I finally had a chance to play around with Cymon's discovery of the trivial conversion of E values to adjust gcode for a different filament diameter.

I've put together a simple python script that consumes a gcode file of a calibration cube, and generates a new gcode file with the E values adjusted for a given filament diameter.  The end goal is to write a script that can generate gcode of an array of calibration cubes, all with different "filament diameters" so one could just fire off the print, and pick the filament diameter that made the best cube.   Currently, it just converts the existing cube to a new filament diameter and writes it to disk.

It mostly works, but I've noticed some things in the RepG39 Sailfish->SF 50 generated gcode that I have questions about.

First question.

I'm noticing that my math doesn't exactly line up when compared to an actual cube sliced at a specific filament diameter.  Usually, the E values are identical, but sometimes I'm off by .001, but never more than .001.  I'm guessing either my code has precision issues, or SF 50 is doing something funny to round off the E float values to 3 digits after the decimal.

The vast majority of the G1 extrude commands are spot on.  Is .001 error in E values enough to make a noticeable difference in the print? Its not a cumulative error, as even the last layer's extrusion commands hop back and forth between being spot on and .001 off.  I'm guessing that SF is internally preserving precision, but doing something to the values when writing them to gcode.

Second question. 

I noticed that retraction (SF dimension version) is accomplished by sending G1 E# commands before and after a series of G1 XYZFE commands.  Something I've been curious about before, if we have acceleration disabled, does the Sailfish firmware still perform deprime, or do we need to reenable SF retraction?  The only reason I ask, is if this script eventually prints a bunch of cubes, I'll need to support some flavor of retraction or people might complain that it sucks because of strings between layers on different cubes.

Any other advice/suggestions for this script I'm more than happy to hear.  This is my first attempt at hacking gcode and I feel like I know just enough to shoot myself in the foot. Cymon has already requested that each cube have its filament diameter value written in front of it.  I think I can manage this, as long as he can accept simple LCD watch style digits. ;) 

thanks y'all

-Andy

[Andrew Russell]

BTW, just so its said, I'm happy to share this code and I'll be posting it on thingiverse once its working/dummy proof enough to not destroy someone's machine if they don't know what they are doing.

thx,

-Andy

--
 
 

[funBart]

Sounds good! Happy to try, but I'm afraid I'm not able to contribute because of my mouse-sized brain...

[Dan Newman]

On 16 Jan 2013 , at 4:37 AM, Andyways wrote:

> I finally had a chance to play around with Cymon's discovery of the trivial
> conversion of E values to adjust gcode for a different filament diameter.
>
> I've put together a simple python script that consumes a gcode file of a
> calibration cube, and generates a new gcode file with the E values adjusted
> for a given filament diameter. The end goal is to write a script that can
> generate gcode of an array of calibration cubes, all with different
> "filament diameters" so one could just fire off the print, and pick the
> filament diameter that made the best cube. Currently, it just converts
> the existing cube to a new filament diameter and writes it to disk.
>
> It mostly works, but I've noticed some things in the RepG39 Sailfish->SF 50
> generated gcode that I have questions about.
>
> First question.
> I'm noticing that my math doesn't exactly line up when compared to an
> actual cube sliced at a specific filament diameter. Usually, the E values
> are identical, but sometimes I'm off by .001, but never more than .001.

Rounding errors because

1. You arrived at the answer using different MORE calculations:

You produced: printing-roundoff( scale * printing-roundoff( f( old-diameter ) ) )
SF-50 produced: printing-roundoff( f(new-diameter) )

So your calc is pretty much guaranteed to be off from time to time. Since the
printing roundoff rounds to the nearest 0.001, I'm actually surprised that you're
not occassionally off by more than 0.001.

You can actually tweak SF and make it write to a higher "precision". Or, more
correctly, output more digits past the decimal. Whether they are precise or
not is an entirely different discussion.

> Second question.
> I noticed that retraction (SF dimension version) is accomplished by sending
> G1 E# commands before and after a series of G1 XYZFE commands. Something
> I've been curious about before, if we have acceleration disabled, does the
> Sailfish firmware still perform deprime,

It still does deprime.

> or do we need to reenable SF
> retraction? The only reason I ask, is if this script eventually prints a
> bunch of cubes, I'll need to support some flavor of retraction or people
> might complain that it sucks because of strings between layers on different
> cubes.

I'd say that folks are asking too much then.

Dan

[Andrew Russell]

Thanks for the feedback Dan! Replies inline below.

On Wed, Jan 16, 2013 at 8:36 PM, Dan Newman <dan.n...@mtbaldy.us> wrote:

On 16 Jan 2013 , at 4:37 AM, Andyways wrote:

Rounding errors because

1. You arrived at the answer using different MORE calculations:

You produced:  printing-roundoff( scale * printing-roundoff( f( old-diameter ) ) )
SF-50 produced: printing-roundoff( f(new-diameter) )

So your calc is pretty much guaranteed to be off from time to time.  Since the
printing roundoff rounds to the nearest 0.001, I'm actually surprised that you're
not occassionally off by more than 0.001.

You can actually tweak SF and make it write to a higher "precision".  Or, more
correctly, output more digits past the decimal.  Whether they are precise or
not is an entirely different discussion.

Does the precision of the Gcode E values have any downstreams repurcussions?  I'd rather preserve the precision in my code if its NBD to have E values like E1.8977, vs E 1.9.

Admittedly, I did not programmatically check the error, so there could be values off by more than .001. Diff'ing the code output with SF generated gcode, the vast majority of E values I looked at were exactly right or off by .001.  If I add a unit test suite for this thing (probably a good idea since the code is ultimately telling my $2k printer what to do) I'll put one in to check the rounding errors. 

> Second question.
> I noticed that retraction (SF dimension version) is accomplished by sending
> G1 E# commands before and after a series of G1 XYZFE commands.  Something
> I've been curious about before, if we have acceleration disabled, does the
> Sailfish firmware still perform deprime,

It still does deprime.

This is great.  Another side question, is there a way to independenty dial prime and de-prime? From all the on board prefs available, its looks like they are both controlled by the same deprime value.

> or do we need to reenable SF
> retraction?  The only reason I ask, is if this script eventually prints a
> bunch of cubes, I'll need to support some flavor of retraction or people
> might complain that it sucks because of strings between layers on different
> cubes.

I'd say that folks are asking too much then.

:) 

For the moment, it currently just sets the G1 E# retraction values to the previous E# value used during extrusion.

I could at least use the existing retraction values in the incoming gcode, and just apply their offset (retraction/extra filament) to the updated E# .

This would make the script inherently work with both Sailfish deprime as well as SF retraction.

I'm pretty sure if I code this correctly, it can use any object/gcode as a calibration print, not just a calibration cube.  Could be useful if someone intends to print a large number of the same object, and wants to get the values dialed in without a lot of manual print tests.

After realizing how SF retraction works, in theory, I can have other various wedge options:

- retraction wedges

- extrusion temperature wedges

- extrusion speed wedges

- travel speed wedges

Does anyone think there will be issues if I simply switch between the various values for each layer of each object?

IE: if I'm printing layer 1 of cube1 @ filament diameter 1.77, and then start printing layer 1 of cube 2 @ filament diameter 1.79, should I do anything between these extrusion events to smooth the change, or more specifically, eliminate any nozzle pressure buildup/release that would make the the print results less accurate than a single print with the desired filament diameter?

thanks!!

-Andy 

[Dan Newman]

>
> Does the precision of the Gcode E values have any downstreams
> repurcussions? I'd rather preserve the precision in my code if its NBD to
> have E values like E1.8977, vs E 1.9.
>
> Admittedly, I did not programmatically check the error, so there could be
> values off by more than .001. Diff'ing the code output with SF generated
> gcode, the vast majority of E values I looked at were exactly right or off
> by .001. If I add a unit test suite for this thing (probably a good idea
> since the code is ultimately telling my $2k printer what to do) I'll put
> one in to check the rounding errors.

An error of 0.001 mm on the input side of the extruder ammounts to
9.3 * 0.001 mm = 0.0093 mm of output noodle. Not a lot. Or in
steps, 0.001 mm on the input side is 0.095 steps. That's probably
noise when you take into account positioning error in those microsteps.

> This is great. Another side question, is there a way to independenty dial
> prime and de-prime?

No. It's meant to be simple.

Dan

[Andyways]

Thanks Dan.

I've got a few questions specifically about gcode.

(Hopefully this won't turn into a g-code tutorial)

I've been reading this doc:

http://reprap.org/wiki/G-code

as well as the help drop down in RepG w/ the list of "supported gcodes" to get my answers. If there are better resources for this info, please let me know.

First question,

Are the ()'s comments used in any way when generating the s3g file from the gcode?

I only ask so I know if I need to bother with preserving them in any meaningful state. For example, when merging the multiple calibration cubes into one gcode file, does it matter if there are redundant (<layer>) commands or are they only there for gcode parsers and documenting the chunks of gcode?

I see these commented out lines around the beginning of layers:

;M108 R15.0

Why are they in the code?  Are they ignored, or are they actually used when generating s3g?

I notice that gcode generated with SF when slicing multiple (2) cubes, the travel commands between cubes do a little dance, like this:

G1 X-17.4 Y-4.41 Z0.1 F1800.0

G1 X-2.6 Y-4.41 Z0.1 F1800.0

G1 X-4.8 Y-4.41 Z0.1 F1800.0

I thought at first this was to avoid traveling over already extruded filament, but then I noticed the Y value doesn't change, only the X.

Whats the point of generating g-code like this, and not just 1 command moving directly to X -4.8?

And the last stupid question (for today at least ;] ).  In this example of an extrusion event:

G1 X-9.8 Y-9.49 Z0.3 F1800.0

G1 F1200.0

G1 E48.412

G1 F1800.0

M101

G1 X-9.8 Y-9.8 Z0.3 F900.0 E48.429

G1 X9.8 Y-9.8 Z0.3 F900.0 E49.472

G1 X9.8 Y9.8 Z0.3 F900.0 E50.516

G1 X-9.8 Y9.8 Z0.3 F900.0 E51.56

G1 X-9.8 Y-9.49 Z0.3 F900.0 E52.588

G1 F1200.0

G1 E51.588

G1 F900.0

M103

According to the RepG help, M101 is start extruder, M103 is stop extruder.  

When the G1 E48.412 command is issued before the M101 command, is this actually rotating the extruder gear, or is it just setting the E value in the current machine state?

Just making sure my gcode merging is going to do the right thing...

thanks for the help,

-Andy

[Jetty]

> I've got a few questions specifically about gcode.
> (Hopefully this won't turn into a g-code tutorial)
>
> I've been reading this doc:http://reprap.org/wiki/G-code
> as well as the help drop down in RepG w/ the list of "supported gcodes" to
> get my answers. If there are better resources for this info, please let me
> know.
>
> First question,
> Are the ()'s comments used in any way when generating the s3g file from the
> gcode?

No, they're comments. There is an exception however when they are
used with the new LCD message commands, in which case they
are. But everything else, no.

> I only ask so I know if I need to bother with preserving them in any
> meaningful state. For example, when merging the multiple calibration cubes
> into one gcode file, does it matter if there are redundant (<layer>)
> commands or are they only there for gcode parsers and documenting the
> chunks of gcode?

No. Except it can be useful to debug things sometimes. For example,
if you need to know what skeinforge settings
someone was using.

> I see these commented out lines around the beginning of layers:
> ;M108 R15.0
> Why are they in the code?  Are they ignored, or are they actually used when
> generating s3g?

They're ignored.

> I notice that gcode generated with SF when slicing multiple (2) cubes, the
> travel commands between cubes do a little dance, like this:
> G1 X-17.4 Y-4.41 Z0.1 F1800.0
> G1 X-2.6 Y-4.41 Z0.1 F1800.0
> G1 X-4.8 Y-4.41 Z0.1 F1800.0
>
> I thought at first this was to avoid traveling over already extruded
> filament, but then I noticed the Y value doesn't change, only the X.
> Whats the point of generating g-code like this, and not just 1 command
> moving directly to X -4.8?

That's poor. There could be something going on in the slicer causing
that, but it shouldn't
be happening, and with acceleration it'll slow your print down. It's
likely some artifact of the slicer code.

> And the last stupid question (for today at least ;] ).  In this example of
> an extrusion event:
> G1 X-9.8 Y-9.49 Z0.3 F1800.0
> G1 F1200.0
> G1 E48.412
> G1 F1800.0
> M101
> G1 X-9.8 Y-9.8 Z0.3 F900.0 E48.429
> G1 X9.8 Y-9.8 Z0.3 F900.0 E49.472
> G1 X9.8 Y9.8 Z0.3 F900.0 E50.516
> G1 X-9.8 Y9.8 Z0.3 F900.0 E51.56
> G1 X-9.8 Y-9.49 Z0.3 F900.0 E52.588
> G1 F1200.0
> G1 E51.588
> G1 F900.0
> M103
>
> According to the RepG help, M101 is start extruder, M103 is stop extruder.
> When the G1 E48.412 command is issued before the M101 command, is this
> actually rotating the extruder gear, or is it just setting the E value in
> the current machine state?
>
> Just making sure my gcode merging is going to do the right thing...

On the latest RepG M101 sets the motor direction to clockwise, and
enables the extruder motor.
M103 disables the extruder motor.

However the later MBI and Sailfish firmwares if it see's E-steps will
enable the motor anyway, so it's somewhat redundant.

Keep em in, but E-Steps before the M101 will still run the extruder
for those e-steps.

M101/M103 is an overhang from the time when extruders were DC motors
and not stepper motors.

[Dan Newman]

On 18 Jan 2013 , at 4:07 AM, Andyways wrote:

> Thanks Dan.
>
> I've got a few questions specifically about gcode.
> (Hopefully this won't turn into a g-code tutorial)
>
> I've been reading this doc:
> http://reprap.org/wiki/G-code
> as well as the help drop down in RepG w/ the list of "supported gcodes" to
> get my answers. If there are better resources for this info, please let me
> know.

Wrong doc to read for Makerbots. See the gcode/mcode listings at http://replicat.org

> First question,
> Are the ()'s comments used in any way when generating the s3g file from the
> gcode?

Depends upon what gcode parser you are using and why. Consider MBI's support
of merging to sets of gcode for dualstrusion….

> I see these commented out lines around the beginning of layers:
> ;M108 R15.0
> Why are they in the code?

Presumably the slicer put them in and then commented them out. For example, SF
has a "replace.csv" file which, I believe, does exactly that in SF-50 as distributed
with ReplicatorG. The replace.csv file asked for all M108's to be commented out.

> Are they ignored, or are they actually used when
> generating s3g?

They should be ignored.

> I notice that gcode generated with SF when slicing multiple (2) cubes, the
> travel commands between cubes do a little dance, like this:
> G1 X-17.4 Y-4.41 Z0.1 F1800.0
> G1 X-2.6 Y-4.41 Z0.1 F1800.0
> G1 X-4.8 Y-4.41 Z0.1 F1800.0
>
> I thought at first this was to avoid traveling over already extruded
> filament, but then I noticed the Y value doesn't change, only the X.
> Whats the point of generating g-code like this, and not just 1 command
> moving directly to X -4.8?

I don't know offhand why SF does that.

> And the last stupid question (for today at least ;] ). In this example of
>
> an extrusion event:
> G1 X-9.8 Y-9.49 Z0.3 F1800.0
> G1 F1200.0
> G1 E48.412
> G1 F1800.0
> M101
> G1 X-9.8 Y-9.8 Z0.3 F900.0 E48.429
> G1 X9.8 Y-9.8 Z0.3 F900.0 E49.472
> G1 X9.8 Y9.8 Z0.3 F900.0 E50.516
> G1 X-9.8 Y9.8 Z0.3 F900.0 E51.56
> G1 X-9.8 Y-9.49 Z0.3 F900.0 E52.588
> G1 F1200.0
> G1 E51.588
> G1 F900.0
> M103
>
> According to the RepG help, M101 is start extruder, M103 is stop extruder.
> When the G1 E48.412 command is issued before the M101 command, is this
> actually rotating the extruder gear, or is it just setting the E value in
> the current machine state?

It's a G1 so it's saying to move there (rotate the extruder). However,
when RepG generates the s3g, it combines in (odd to me ways sometimes)
these lone G1 commands into a single move.

Dan

[hellphish]

It might be worth taking a look at the source for the Dimension plugin in SF. It always runs extremely quickly, even on complicated models. It is also one of the last scripts to run when slicing, implying that it is essentially "post processing" the gcode up to that point.

--