Print quality comparison - Makerware 2.0 versus ReplicatorG Sailfish 040R11 - printing on a Relicator2 with Sailfish firmware r00942

[Enginwiz]

To test the quality of accelerated prints at a speed of 120 mm/s several test models were sliced with a layer resolution of 0,15 mm

in Makerware 2.0 and ReplicatorG Sailfish 0040r11 and printed on a Replicator 2 with Sailfish firmware r00942.

In Makerware 2.0 custom profiles for Makerbots fast slicer Miracle Grue had to be optimized for the black 3rd party PLA.

Printing calibration cubes 20 x 20 x 10 mm with 100% infill showed best results at a "FeedDiameter" of 1.80 mm

and a "FeedstockMultiplier" of 1.0. Print speed in my Makerware profiles remained at 80 mm/s. After printing the

first layer the "Change speed" option in the sailfish firmware was used to increase the print speed to 150%.

In ReplicatorG 0040r11 the new "Replicator 2 - 100 micron" profile of Wingcommander WPThomas uses the same

value 1.0 for "Filament packing density" (aka FeedstockMultiplier) in the dimension plugin. Calibration cubes

again verified a filament diameter setting of 1.80 mm as optimum. The slicer used inside ReplicatorG was

Skeinforge 50.

The calibration cubes sliced with ReplicatorG have a visible zipper.

No zipper is visible on the sides of the cubes sliced in Makerware.

Next Wingcommanders Surface Calibration Test got sliced and printed.

Again the flat sides sliced with RepG show a Zipper.

The Makerware test sample has a bump in the zylindrical section

and a rougher top section.

The last test sample was Wingcommanders Acceleration Test part.

The part sliced with ReplicatorG / Skeinforge again show a visible Zipper. 

Overall surface finish is still quite good at 120 mm/s.

 

The sample sliced with Makerware / Miracle Grue shows some surface defects

in the round surfaces at a comparable print speed of 80 mm/s x 150% set on the printer display.

The flat backside of the Makerware print looks perfect.

On this side ReplicatorG / Skeinforge show two Zippers and some ringing.

Overall Makerware 2.0, Miracle Grue and the Sailfish firmware r00942 worked together well

and produced better surface quality on flat vertical surfaces. No Zippers.

ReplicatorG 0040r11, Skeinforge50 and Sailfish firmware r00942 produced better looking

rounded surfaces and top areas. The visible Zippers still need some more fine tuning. 

Starting prints slow and increasing the speed with the "Change speed" function at the bot

if everything runs smoothly is a game changing advantage. The print quality at 120 mm/s is

still quite good. At a layer height of 0,15 mm and a speed of 120 mm/s the hot end 

holds a constant temperature of 230°C and extrudes reliably. The Replicator 2 did not

reach its speed limit during the test. Some more speeding up seems possible at least

for high resolution prints without reaching the limit of the hot end melting capacity.

[Mike Gervasi]

I use it as standard practice now to get a solid bottom layer. If it fails at that speed I know quickly I have more tweaking to do :)

[David Celento]

Superb comparison! Many thanks for sharing this.

In MW, were the only custom profile settings that you modified the ones you listed, or were there more? If so, care to share the entire MW custom profile?

[Joseph Chiu]

Thanks for the comparison and those pictures, Enginwiz!

Those zippers on the SkeinForge cube comes from jitter moving the start/end position of the loops.  Looking at the picutre of the calibration cube by MakerWare, I don't see loop start/end's at all.  Could you send the Gcode for the MW calibration cube output?  I have a hard time believing the loop ends could merge together that nicely.  (I would love to be proven wrong.) Could it be that the loop start/ends are somewhere else?   Perhaps right at the corners?

In your last picture, you can actually see loop start/end's on the MW prints -- they are not jittered, though:

I think this suggests that at higher speeds, SF jitter is lowering print quality by introducing layer-to-layer phase variations on the ringing ripple patterns.  Put differently, if you turn off jitter in SkeinForge, I think you might get a much more similar cube wall quality.  I'd run a test to show this, but I am away from my printers today (one is on loan to LA Makerspace, the other is at the office).

Joseph

On Sun, Mar 17, 2013 at 7:03 AM, David Celento <dcel...@gmail.com> wrote:

Superb comparison! Many thanks for sharing this.

In MW, were the only custom profile settings that you modified the ones you listed, or were there more? If so, care to share the entire MW custom profile?

--
You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.
To unsubscribe from this group and stop receiving emails from it, send an email to makerbot+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Joseph Chiu]

Hmm, pasted picture didn't show.  Let's try that again -- this is on the right:

[Dan Newman]

On 17 Mar 2013 , at 7:54 AM, Joseph Chiu wrote:

> Thanks for the comparison and those pictures, Enginwiz!
>
> Those zippers on the SkeinForge cube comes from jitter moving the start/end
> position of the loops. Looking at the picutre of the calibration cube by
> MakerWare, I don't see loop start/end's at all. Could you send the Gcode
> for the MW calibration cube output? I have a hard time believing the loop
> ends could merge together that nicely. (I would love to be proven wrong.)
> Could it be that the loop start/ends are somewhere else? Perhaps right at
> the corners?
>
> In your last picture, you can actually see loop start/end's on the MW
> prints -- they are not jittered, though:
>
> I think this suggests that at higher speeds, SF jitter is lowering print
> quality by introducing layer-to-layer phase variations on the ringing
> ripple patterns. Put differently, if you turn off jitter in SkeinForge, I
> think you might get a much more similar cube wall quality. I'd run a test
> to show this, but I am away from my printers today (one is on loan to LA
> Makerspace, the other is at the office).

Interesting suggestion about the jitter.

Also, did the SF profile have

1. More than one shell, and
2. Use loops > perimeter > infill ?

That is, I'm wondering if there was only one shell in the SF cube and thus
SF left the zipper out in plain sight. If there was more than one shell,
then the zipper is still in plain view unless "perimeter" is not the first
layer path.

Dan

[Enginwiz]

The Makerware / Miracle Grue custom profiles have been published on Thingiverse.

Download them from http://www.thingiverse.com/thing:38390 and try them out.

These profiles are just some basic calibrated settings for PLA with a diameter of 1.70 to 1.73 mm.

Feedback of your results are appreciated. Maybe I will tweak these profiles a bit more.

[Enginwiz]

Hello Dan,

For the print test I used the new RepG / Skeinforge profiles of Wingcommander whpthomas.

He published them on Thingiverse: http://www.thingiverse.com/thing:61022

Wingcommander whpthomas: Thank you for tweaking and sharing the skeinforge profiles.

[Enginwiz]

Hello Dan,

In Makerware / Miracle Grue and RepG / Skeinforge I added 1 extra shell.

The skeinforge profile "Replicator 2 - 100 micron" had Loops -> Perimeter -> Infill selected in the Fill tab.

I don't know how Miracle grue avoids the Zipper. My best guess is that the

extruder prints the loop, jumps to the perimeter with a running extruder and

jumps back inside when the perimeter is finished. I recently got a number of prints

out of Makerware / Miracle grue that are practically seamless on the outside.

However - some delicate models with thin walls produced spectacular slicing errors

in Miracle Grue. I design in Autodesk Inventor 2013 or Solid Edge ST3. STLs exported

from these midrange CAD programs are usually one single mesh hull. RepG and

Skeinforge don't produce these slicing errors.

Big solid models already have a good success rate in Makerware / Miracle Grue, if the surface

of the part is not too complex.   

[KM Design]

Note that for fine detail in Miracle Grue you need to set the number of shells to 1 (which is the equivalent to setting the number of shells to 0 in ReplicatorG/Skeinforge). Setting the number of shells to 0 in Miracle Grue will actually generate 0 shells..... (a little bit of knowledge I discovered while getting technical support from MB).

Kevin

[funmakerBart]

As far I know the testing is about four items:

• the two slicers ReplicatorG(with Skeinforge) and MiracleGrue.
  
• two firmware types: Makerbot and Sailfish.
  

The four items can get mixed and may show different results. The Makerware firmware is using the Sailfish acceleration part for it's acceleration. ReplicatorG/skeinforge  is almost the same regarding the slicing part, but differs regarding the ability to adjust onboard preferences. For Sailfish firmware you need the Sailfish version of ReplicatorG.

IMO it would be more clear to compare all those items in a way it's clear what the influence of each component is, so:

• compare MiracleGrue sliced models with the about the same settings sliced with RepG/Skeinforged and print with Makerbot firmware and Makerware as "print driver" as it's belonging more to it.
  
• compare MiracleGrue sliced models with the about the same settings sliced with RepG/Skeinforged and print with Sailfish firmware: and RepG40sailfish as "print driver". Although it makes no difference, for what I know, to use Makerware as "Print driver" with Sailfish as firmware, as long you won't change the onboard preferences.
  

Bart

[Enginwiz]

Hello Bart,

The initial question for me was: Which print quality do the latest versions of RepG and Makerware produce on a Replicator 2 with the latest Sailfish firmware?

I intend to use Sailfish firmware r00942 for the rest of 2013 and wanted to share the results of my calibration and testing procedure with this group.

During the last five month tips and feedback from this group were quite helpful to tweak a Replicator 2 into reliable operation.

[funmakerBart]

Ah, they are all printed with Sailfish firmware, I didn't understand that! So it's a comparison between Skeinforge and Miracle grue I suppose. Or did I understand it wrong again?

[Enginwiz]

Hello Bart,

Yes, this test compared ReplicatorG 0040r11 / Skeinforge 50 versus Makerware 2.0/ Miracle Grue printing on the same Rep2 with Sailfish firmware r00942.

Due to the midrange CAD-Software (Inventor and Solid Edge) I use for my engineering projects I have to work on a Windows workstation.

ReplicatorG 0040r11 / Skeinforge 50 are awfully slow even on a high end CAD-Workstation. Currently ReplicatorG does not

work with PyPy on a windows machine and PyPy is not available for Windows 7x64.

So I will try to use Makerware 2.0 / Miracle Grue for bigger prints that would take hours to slice with Skeinforge 50.

Miracle Grue is a Beta version and sometimes produces slicing errors that lead to failed prints. Thin walls and

complicated surface geometry are still problematic. If Makerware fails or the models are small and delicate want to use

ReplicatorG 0040r11 / Skeinforge 50 to get the job done. 

This test should verify that both combinations of PC Software create an acceptable print quality on a Rep2 with Sailfish firmware.

Robert

[Enginwiz]

Hello KM Design,

I printed the same test model with only one shell through Miracle Grue. It has a line of holes in the surface instead of a Zipper. This is not the best quality I can get with my sailfish setup. 

Here comes a comparison between one and two shells. On the surface with two shells a line of very small bumps marks the beginning and end of the outer shell loop called perimeter.

So I will stick to 2 shells. The very small bumps on the print are almost invisible. 

Thank you for the remark concerning "numberofShells" in Miracle Grue. 

Contrary (and maybe more logically) than in Skeinforge "numberofShells": 2 means that 

the vertical hull of the printed part consists of 2 shells. The outer shell is called "perimeter"

the additional shell inside the perimeter is called "loop". Miracle Grue first prints the loop inside,

then jumps outward and prints the perimeter, then jumps inwards over the loop and prints the 

fill pattern to complete the layer. With "numberofShells": 2 this worked almost perfectly and left

only a barely visible line of small bumps on the outside of the part. I did not find the small bumps

on the initial 2 shell print. After seeing the holes in the one shell print I knew where to search for

some kind of imperfection. Without knowing where the perimeter starts you would not find it.

Robert

[TaErog]

That is a sweet bike, Good luck!

On Monday, March 18, 2013 1:13:15 AM UTC-4, Wingcommander whpthomas wrote:

So here is an example of what I would call a real world object - printed at 120mm/s with my replicatorg sailfish profiles. No issues with zippers here, great surface finish, and the results are dimensionally pretty accurate.

So i am heading off to Taipei tomowwor for the international bike show - wish me luck!

[Enginwiz]

Hello Wingcommander whpthomas,

this is a very nice training bike. Good luck in Taipei!

[funmakerBart]

Actually you can use PyPy on a windows7x64 machine. I have it running together with skeinforge by the almost 'one click' install of Repetier-Host.

The downside is that you can't use RepG (which is just a shell to Skeinforge) and have to fill in the settings to be used in Skeinforge directly.

When comfortable with that: you have all running in no time with Repetier-Host. It gives great 3D Gcode feedback and is as well capable to use slic3r as slicer. The produced Gcode has to be imported into ReplicatorG to print of course.

Download the correct version of Repetier-Host http://www.repetier.com/download/

I have provided somewhere a short guide for installing on the forum (or Jetty forum), but I trust Whpthomas is being able to produce a more understandable guide, as he is native English speaking, testing it with new users in mind, and, last but not least:  looking good on Youtube ;-)

Have fun in Taipei!

Bart

[Enginwiz]

Hello Bart,

I already tried to use Repetier Host for my Rep2 on a Windows XPx32 computer 

and got lost in setting up the machine definition for the Rep 2 in Repetier Host.

Would you mind to share the machine configuration in Repetier Host for your Replicator as a Thing on Thingiverse?

Just make some screenshots of the configuration settings and upload the pictures. This would be great.

Thank you

Robert

[funmakerBart]

Hi, you don't have to use that settings actually, as you are not being able to steer your printer with it. 

If wanted you can adjust the bed settings to be sure you place your object at the zero point for slicing (by Slic3r or Skeinforge) with Repetier-Host as shell. (As ReplicatorG is a shell for Skeinforge). 

After that you have to use Skeinforge settings or Slic3r settings to slice and examine the 3dGcode. After that you have to copy paste the Gcode to RepG to print.

I use Slic3r directly, not in the shell of Repetier-Host, and I don't use Skeinforge a lot. But I look into it later and see I can provide some start settings. But you have to fine- tweak them yourself. I base my settings on the rep 1 dual BTW.

Bart

[funmakerBart]

I'll see if it's easy to copy some basic settings for the Rep2 BTW.

[Brian Jones]

Robert-

I was curious about your ability to switch back and forth from RepG-Sailfish r011 to Makerware 2.01.   Are you saying that I can run Makerware/ Sailfish firmware 7.3 without relative headache?   If so that would be great since I thought I was "all in" once I switched over to RepG-Sailfish. 

Thank you for the test (and getting a good discussion started) , I noticed a lot of loops on a model I printed as well.  Will post pics and contribute.  

Cheers,

Brian 

[funmakerBart]

You can use Sailfish firmware with Makerware or Sailfish RepG. Only: be sure to adjust the onboard preferences (or upload the firmware) with RepGSailfish when Sailfish loaded (or uploading the Sailfish firmware).

And as result of that:  change Makerbot firmware only with the onboard preferences of Makerware or with the RepG version of Makerbot.

You will get headaches and will express yourself very specific, and very loud, when not ;)

[Eighty]

In addition to what Bart said, you also need to be aware of the differences between MBI firmware and Sailfish firmware. Slicer retraction should be avoided if using firmware deprime. But since you're new to this, it might be better to do the opposite. Disable firmware deprime for now, and let the slicer dictate retraction. Results won't be as good in high speed prints, though.
I recently abandoned the retraction settings in Skeinforge, and moved to firmware deprime, and almost all my zits are gone. The zipper looks much better on single-wall prints too.

[Brian Jones]

Whoa ha-ha  So many options there. 

Bart,  thanks for the information. Confirming so I can be sure...  you said: 

change Makerbot firmware only with the onboard preferences of Makerware or with the RepG version of Makerbot.

Do you mean the non Sailfish version of RepG?   To say that if I am going over to Makerware I would reset the  onboard prefs  with RepG (non-Sailfish) or Makerware.  When going with RepG-Sailfish I would use that application to set the onboard prefs (using the WingCommander's settings). 

Apologies if I am being overly granular, I just want to adopt the proper workflow.  As with all of this. I want to solve one problem and (hopefully) never look back!

[funmakerBart]

No problem at all.

Please read a little as well: http://jettyfirmware.yolasite.com/v73-v43.php as well follow the links on that site

Yes and I mean the "non Sailfish version" of RepG. 

Shortly:

So the normal Makerbot version of ReplicatorG40 is downloaded here: http://replicat.org/download. To avoid confusion call it RepG40MB for short.

The firmware of Makerbot is pointed at the URL in your RepG40MB  preferences and is: http://firmware.makerbot.com/firmware.xml. 

And the Sailfish version of ReplicatorG is normally downloaded at thingiverse: http://www.thingiverse.com/thing:32084 Lets call it RepG40Sailfish

and the URL under preferences is: http://jettyfirmware.yolasite.com/resources/release/firmware.xml  . When doing this, be sure to choose as well under Machine//type: the Sailfish version of your printer, not difficult to recognize because it has "sailfish" in the name. After that you can upload the Sailfish firmware belonging to your machine 

Bart

[David Celento]

One very unfortunate problem in MakerWare is that it is making "Travel" moves while still extruding. 

In very thin prints, or things like tight lattices of minimal thickness, this leads to random diagonal extrusions. Until extrusion is turned off, and/or retracted during travel moves, this could be a deal breaker for some using MakerWare for intricate projects.

RepG+Sailfish does not seem to do any such nonsense. I'm a convert.

[Eighty]

Somewhere, I read that MBI intentionally leaves the extruder going on those diagonals. I forget the logic behind it, though.

[funmakerBart]

Yep, I opened a support ticket about that 'keep extruding while traveling in an infill island'  Because  that extra line was visible on the outside, with (at least with me) 0.2mm layers, 3 layers solid. Ugly!

But they weren't planning to change it, because by this a more consistent infill was achieved they claimed...

[David Celento]

If MBI chose this strategy to double their filament sales due to prints failing, then they have achieved their goal!

More seriously, this is like a bit like a CNC router that does not lift, during a travel, slicing through all the work it just cut.

FEATURE REQUEST: As the Slicer Wars duke it out for primacy, improved craft will undoubtedly win a number of fans. Allow users to enable an option to have "lifts" during travels for delicate objects and/or high quality finishes.

Yes, "lifts" would take longer, but for many quality is more important than speed. Maybe most importantly, this would practically eliminate small elements being "knocked over" during builds.

[Eighty]

You can use Hop in Skeinforge to do exactly what you want.  Just use SF50 as the slicer, not MakerWare slicer. 

[Eighty]

But I should add that if you're knocking prints over during travel moves, then you have an issue with outputting too much plastic.  That's not a problem with the slicer, it's a problem with your calibration. 

[David Celento]

Thanks for the "Hop" tip! Will look into this.

Last night I did a back to back test of a modified version of MAKE magazine's Torture Test using RepG+Sailfish (using Wincommander's .2 profile), and MakerWare (using Enginwiz's .2 profile).

The layer thickness seems to have differed (neede to exam GCode to be sure), but the MW print worked entirely. The RepG+S print knocked over the arch.

Would like to run test again to confirm a few things. If I find anything useful, will post results.

[David Celento]

Eighty, simply reduce filament diameter setting in both RepG and MW to test this?

[Eighty]

No.  INCREASE the filament diameter.  You're trying to trick Skeinforge into thinking it has more filament (and will therefore put out less).  It's hard to understand at first, I'll admit.

[David Celento]

That makes sense (in a weird way). Thanks!

What are useful percentage ranges to increase the FeedDiameter.  Is a 5% increase (from 1.80 to 1.89) too much, or reasonable?

[Eighty]

Well, you should really calibrate it properly first. For PLA using Skeinforge 50, do the following:

Using the ABS setting, change the filament packing ratio (in the dimension plugin) from 0.85 to 0.97 or so. That alone makes a huge difference.

Then input the measured filament diameter from your spool (using calipers) in Print-o-Matic.

Run a test print of a calibration cube. If it bulges up at the top, increase your filament setting by 0.01-0.02 and try again. Repeat as necessary.

[David Celento]

Gracias!

[David Celento]

On Wednesday, March 20, 2013 6:27:04 PM UTC-4, Eighty wrote:

change the filament packing ratio (in the dimension plugin) from 0.85 to 0.97 or so.

 Just to be sure I'm headed in the right direction, am I correct to believe that the ratio of 0.85 will result in less flow and 0.97 will result in more?

[Eighty]

No, it's the opposite.

 

The 0.85 setting is the default for ABS.  It's a packing factor meant to offset the losses from extruding.  In other words, for every mm^3 of ABS you put in, 15% of that goes to the gods (in the form of smelly fumes), and 85% goes onto the print.

 

So backtracking the math, Skeinforge will put (1.00/0.85)=1.1765 times more plastic down than you really need.

 

The losses for PLA plastic are almost nil, meaning you should set it to nearly 1.0. 

[Eighty]

So to really confuse you here...

 

Your goal is to put down the correct amount.  Makerbot, in their infinite wisdom, has screwed these settings up royally in the defaults.

 

Every millimeter of plastic you push in results in a volume of (Cross-Sectional Area)*(Length)/(Packing Ratio).

 

In MakerWare, they use 1.82mm filament and a FeedstockMultiplier of 0.773.  So MakerWare is expecting that 1mm of input spits out ((1.82/2)^2)*PI*(1.0)/(0.773) = 3.3655 mm^3

 

In Skeinforge, they use 1.82mm filament and a Filament Packing Ratio of 0.85.  So Skeinforge is expecting that 1mm of input spits out ((1.82/2)^2)*PI*(1.0)/(0.85) = 3.0607 mm^3

 

In reality, inputting 1mm of 1.75mm PLA filament will spit out ((1.75/2)^2)*PI/(0.97) = 2.4797 mm^3.

 

Comparing what you SHOULD get vs. what MBI programmed, you'll spit out anywhere from 23.4% to 35.7% too much plastic.  That's why a print with their defaults will have a crappy finish on the outside.  The day I adjusted these settings, my skins started looking right.

 

The RepG/SF50 thing is a carryover from ABS.  Their PLA setting results in lots of problems, so you have to use the ABS setting and tweak.  The MakerWare thing, though, makes no sense to me.

 

Now, you could adjust any of these factors (or a few others) to end-game your filament output.  Some have taken to adjusting the stepspermm in their machine settings.  But if you do it right, then life becomes much easier.  You can measure your filament and input the TRUE value to make a successful print.  Some people lie to their slicers by making up a filament diameter that is bigger, just to get decent prints.

 

I'm not saying you might not still do that from time to time.  For example, I may measure a length of filament and find that it varies from 1.73 to 1.78.  I'll input 1.78, so that I err on the side of "not quite enough", instead of "too much".  Too much plastic causes a lot more problems than too little.

 

[David Celento]

Actually, not confusing at all (other than the bizarre MW approach). The detailed insights are very much appreciated!

This explains a number of unpredictable behaviors. I can now approach both RepG+SF and MW with my wits about me and better comparisons.

The one question I have is with regard to RepG+SF (based on Wingcommander's slicing profiles, which, uses the PLA settings instead of ABS, actually). One can enter filament diameter when editing the slicing profile, but one can also input the filament diameter (under Plastic, in the pop up). Which filament diameter value takes priority -- or does one over-ride the other? If so, which value is used to generate the GCode?

[Eighty]

Whpthomas was trying to do everyone a favor by fixing the PLA profile. But it has caused a bit of confusion, because the standard instructions are to ignore it. So the new advice is, ignore the PLA profile because its broken unless your using the whpthomas version because its not broken.

The filament diameter in the profile is overridden by print-o-Matic. So what you enter in the gcode dialog box will be used (assuming you're using P-o-M).

[David Celento]

Enginwiz,

Been playing with your MakerWare Custom Profiles (http://www.thingiverse.com/thing:38390). Very helpful -- especially when beginning to play with MW's custom profile feature.

As requested, here's some feedback following some experimentation. (For reference, I used Wingcommander's Surface Calibration Shape (http://www.thingiverse.com/thing:39050). Comparing your 0,20mm - 20% profile to MakerWare's Medium setting (with Infill=10%, Shells=2, Layer Height=0.2)

1. Material usage was 77% of MW's setting.

2. Print time was shorter. Don't have the seconds (due to Sailfish Firmware only displaying minutes), but your print was 7 mins. MW's was 10 mins.

2. Surface grid spacing on the final layer of the flat surface seemed a bit loose—I could see through the layers.

3. I noticed some 'ringing' (if that's the term for spaces between shells.)

4. I did notice one possible error:

, "layerWidthRatio": 1.482   MW guide indicates this value to be extrusion width / layer height. Thus, it appears that this should be 0.40 / 0.20 = 2. The value of 1.482 is the default value when creating a new profile because default layer height is 0.27. Just wondering if you left this value for a particular reason or possibly might have overlooked this. Not sure why this isn't an automatic calculation, or why one would adjust this. Insights?

BTW: Is there a way to view/edit MakerWare's default profiles? This would be very useful for comparisons and tweaking. (Requests for this information from MBI have gone unanswered, and I fear they are 'locked down'?)

I've been playing with a few custom profiles of my own, and will share the results if they offer any promise. Most frustratingly, and as mentioned earlier, it seems that there is no ability to 'lift' or 'stop extruding' (like 'hop' in RepG+SF) in the custom profiles? Big problem for my goals.

Thanks again for sharing these! ~Dave

[David Celento]

So.... what exactly does Print-o-Matic do in RepG+SF?  Based on my understanding of the above, it should simply over-ride the already specified values in the selected Slicing Profile? And one need not use it, right?

Playing with Wingcommander's Sailfish profiles using his Surface Calibration Thingi. The result was really, really sparse on the flat part. Then, on a whim, I turned PoM off, even though I had pretty much set the values to the same values as in the profile. Then I simply selected the profile, generated code, printed and BAM!!!  BEAUTIFUL PRINT! (aside from the indented seam at the start/stop line endings -- which MW actually handles a bit better -- and a 'thready' bottom, which I thought was kinda odd).

When the values in PoM match up EXACTLY with the same values as the Slicing Profile, are the print results identical for either method for others? One would expect, YES; however, my two results were REALLY different. Maybe I simply flubbed something—which seems more than likely given that I'm still pretty new to RepG+SF! :-)

[Eighty]

Print-o-Matic overrides a lot of stuff in SF50. Many of the overrides are calculated, based on the info you gave PoM. In The SF profile editor, you'll notice that some fields are yellow or blue, that signifies that it will be overridden. Haven't figured out why one is yellow and another is blue, but I haven't put enough brain power to it yet.

Here's an MBI article on it.
http://www.makerbot.com/support/replicatorg/documentation/printomatic/

[Dan Newman]

On 22 Mar 2013 , at 1:03 AM, David Celento wrote:

> So.... what exactly does Print-o-Matic do in RepG+SF? Based on my
> understanding of the above, it should simply over-ride the already
> specified values in the selected Slicing Profile? And one need not use it,
> right?

Look in the logging window at the bottom of the main RepG window. It will
show you everything Print-o-Matic overrides in SF.

Dan

[joe...@gmail.com]

Those blues and yellows are telling you the value is above or below the "default" value. Keep in mind the defaults are not necessarily the right values or even close for working well on your machine.

-- Sent from my HP TouchPad

---

--
You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.
To unsubscribe from this group and stop receiving emails from it, send an email to makerbot+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Eighty]

Joseph,

Thanks for that tip.  I always wondered about that, as the color schemes never quite married up to what I expected.  Oddly enough, the colored items (at least, on my profile) are items that get overridden by PoM. 

[Enginwiz]

Hello David,

Thank you for your remarks concerning an individual "layerwidthratio" for each layer height.

I did a set of test prints with a calculated "layerwidthratio" of 0,4 mm (the nozzle width) divided by layer height.

To compare the vertical surface quality I did prints with 1 shell (only one perimeter shell) and 2 shells (one loop and one perimeter shell).

The horizontal surfaces of all prints look consideraby better with an individual "layerwidthratio".

However - with only one shell I get holes in the surface where start and end of the outer shell (perimeter) should meet.

A total of two shells leaves almost no visible seam in the outer shell (perimeter). 

The surface defects of prints with ony one shell look even worse in rectangular parts. 

Therefore I will prefer 2 shells (one loop and one perimeter) for printing big engineering prototypes with Makerware / Miracle Grue.

However - Profiles with only one shell (the perimeter) are sometimes neccessary to print delicate parts 

with thin walls of less than three nozzle diameters like this part I had to print today as a spare part

for our shower doors. The left part is one of the original parts. I increased the wall thickness a bit

in the right part to make it a bit sturdier than the original part and printed it with with a layer height

of 0,15 mm - 1 shell - 100% fill in white PLA. Looks almost like an injection molded part.

I uploaded my improved custom profiles for Makerware / Miracle Grue to Thingiverse. 

You can download them at http://www.thingiverse.com/thing:38390

Happy printing!

Robert

[David Celento]

Robert,

I'm glad what I thought might be a misunderstanding on my part about one setting in your profiles turned into a fortuitous improvement overall. The parts you show look VERY NICE, indeed. I look forward to playing with your revised profiles.

BTW: Stunning test print comparo—the rigor is to be applauded!

I'm currently doing some tests comparing MakerWare (defaults, and your profiles) and RepG+SF (WingCommander's). I can only make generalized conclusions at this stage, but the much maligned MakerWare appears to be holding up pretty well so far.

I've been printing a lot of very delicate parts (playing with thin, single walls at 0.40 width, if possible), so appreciate your shell comments about these needing to be different from larger parts. The one big complaint I have with MakerWare thus far is that it extrudes while traveling. Do you know if this is something that can be edited out?

[David Celento]

To clarify my MW complaint, the 'travel' while extruding is generally on a diagonal within an island, and very evident embedded in the surface of thin models and in between closely spaced vertical elements with no raft.  I seem to recall a discussion on this somewhere in the last few weeks, but can't find it, nor can I remember the conclusion.

[Enginwiz]

Hello David,

the diagonally extruded line on the top surface seems to be a slicing error in Makerware 2.X.X.

I did not notice that behaviour in Makerware 1.X.X.

Developing slicing engines is tough work. Skeinforge has seen some years of development and debugging. 

Miracle Grue saw the light of this world (in the eyes of us users) only 7 to 9 month ago.  

Anyway - Makerbot seems to be headed in the right direction and the Sailfish fimware r00942 seems to

eat Miracle Grue created .s3x code with pleasure.

 

I look forward to read about your testing results.

Happy printing

Robert

[Enginwiz]

Hello Henry,

today I installed Dan's latest ReplicatorG 0040r12 and selected PyPy for slicing with Skeinforge.

PyPy really makes Skeinforge fly through the layers. Big thanks to Dan and Kubus to work this out.

To compare Makerware 2.0.2 / Miracle Grue and ReplicatorG 0040r12 / Pypy / Skeinforge

with the same speed settings I selected 80 mm/s for printing in Print-o-Matic and printed

the first two layer with this speed. During the third layer I changed the speed on the bot

to 150%. On these small parts the maximum speed will not reach 120 mm/s because

the stroke lenghts in one direction are too short to reach the top of the acceleration ramp.

Anyway - at 150% the print finishes a considerable time earlier. This is what finally matters

together with the resulting print quality on the outside of the printed part.

With your sailfish profile "Replicator 2 - 100 micron" I sliced your surface calibration

test print for a layer height of 0,15 mm with 20% infill, started to print at 80 mm/s and

changed the speed after the second layer to 150%.

The overall surface quality is very good, maybe a bit better than the Makerware / Miracle Grue sliced prints I did yesterday.

However - on the perimeter I always get a visible zipper. Selecting ZERO shells in Print-o-Matic for one

perimeter and zero loops on the inside produces a smaller zipper than selecting ONE shell in Print-o-Matic for one

perimeter and one loop.

Sorry - Google Chrome doesn't let me add a second picture in this post. I will have to continue with a second post.

Robert

[Enginwiz]

Hello Henry,

the ugly zipper gets even worse on rectangular parts.

I printed a small calibration cube 10 x 10 x 10 mm at layer height of 0,15 mm with zero shells in P-o-M and 100% infill

to check that my filament diameter is correct for 100% fill and to show that not underextrusion is creating my surface errors.

The zipper on the cube gets a twin on a second side. The other two vertical sides are perfect.

I printed one of the shower door spare parts in white PLA to try a different filament. Again a prominent zipper.

The zipper weakens the part just in the area of most stress along the hole for the screw. This is exactly

where one of the original parts broke.

Please try to cross check this behaviour on your Replicator 2. I tried to follow your instructions

on the PDF installation guide for your profiles. Deprime is set to 64 in onboard preferences.

All calibration prints have been printed from a SD card. I don't understand why I get zippers

when using ReplicatorG / Skeinforge and others don't.

Thank you for sharing your Skeinforge profiles and for your advice.

Robert

[David Celento]

Enginwiz (and any other interested folks),

As a test, in RepG+SF, run two prints:
A) set PoM values as they are in Henry's profile.
B) just use Henry's profile, but turn PoM off.

Should be identical results printed, right?

When I tried this, my prints were very different. Either I screwed up something, or is it possible that there is a glitch somewhere in the matrix?

[Enginwiz]

Hello Henry,

to make sure that the zippers are not a result of my tinkering with the speed at the bot

during the print I printed out a standard calibration cube 20 x 20 x 10 mm 

with your "Replicator 2 -100 micron" profile and set the print speed

in Thing-o-Matic to your default of 120 mm/s. Layer height was 0,15 mm.

I selected zero shells in T-o-M and 100% infill.

Again I get 2 zippers - one on the right and one on the left side.

The two invisible vertical surfaces on the back of the cube are perfect.

After a bunch of calibration cubes I got best surface and fill quality with 

this brand of opaque PLA at a relatively high filament diameter setting of 1,80 mm  

for a measured average real filament diameter of 1,73 mm and a 

filament packing density of 1.0 in Skeinforge and Makerware.

Lowering the filament diameter settings below 1,80 mm leads to 

signs of overextrusion. 

What are your real filament diameters and your filament diameter

settings in T-o-M? We might accidentially use PLA from the

same original manufacturer (1kg, black spool, 32 mm central hole,

outer diameter 156 mm, spool width 96 mm). I am curious wether your

filament diameter settings are also higher than the measured diameter.

Robert

[Dan Newman]

>
> Again I get 2 zippers - one on the right and one on the left side.
> The two invisible vertical surfaces on the back of the cube are perfect.

To me zippers are an actual construct in the gcode caused by where
the extrusion of one layer ends, the Z coordinate is increased, and
the next layer then begins. So, with that definition in mind, have you
looked in the gcode and confirmed that you actually have two spatially
separated zippers? It's certainly possible to achieve that and they
would have an alternation similar to what I think I'm seeing. I'm
just seeking confirmation that that is what you have as opposed to
some other artifact which is causing those effects. For example,
I've seen SF do odd things where it starts breaking line segments
into a long run and a short run. And then, if you have it running
alternate layers in opposite directions then you can get surface
effects similar to what you seem to have.

Dan

[Enginwiz]

Hello Dan,

Tomorrow I will copy the gcode into Repetier Host and check the extruder moves.

Thank you for this hint. Could be a slicing error of Skeinforge.

I will also try to reduce deprime to 16 as suggested.

Robert

[Andy Chen]

I might need to retract that advice. Deprime 16 helps the gap, but I was shortsighted in only trying it on a 20mm calibration cube. I printed a model with more travel and got stringing.

About the clip module. I interpreted from the docs that clip is used to increase the perimeter gap to address bulging. Henry, one of your posts suggests that clip is used actually used to for the opposite purpose, to decrease the gap. Either way, by turning off clip you also lose its loop connecting feature.

[David Celento]

Very nice deprime test object!

This also begins to address one of the items I like to test which is small items with square corners. Might be interesting to make an object with one of the corners being a stepped square extrusion (aligned at the outer edge) with the topmost square being something like 1/16" or 1/8"?  Such a design would address a number of test parameters in one tasty little object that is quick to run.

[David Celento]

Yep! Maybe even one tiny cube on top -- making a nice little top corner torture test to see if it melts.

[Enginwiz]

Hello Dan,

Today I sliced the calibration cube again with ReplicatorG 0040r12 / PyPy / Skeinforge 50

and the "Replicator 2 - 100 micron" profile. T-o-M was set to 0,15 mm - 0 shells - 120 mm/s.

I opened the generated g-code with Repetier-Hostand and as you suspected there are gaps

in the gcode generated by Skeinforge on two sides of the calibration cube.

Is this a slicer error of Skeinforge? I would expect that the perimeter lines have no gaps.

Robert 

[Enginwiz]

Sorry - the screenshot of Repetier Host looks too bad. Converting it to JPG destroyed most of the detail.

Here comes a better one.

And an additional detail of the left side. 

I hope you can recognize the gaps on these pictures.

Robert

[Joseph Chiu]

Enginwiz, if you're willing to experiment a little, may I suggest adjusting the clip parameters to lower the clip amount?  Also, if the moving of the entry/exit points is not palatable, you could turn off jitter.

[Matthew Stonebraker]

I'm very sorry this conversation didn't continue, I was finding it VERY instructive and interesting.

On Tuesday, March 26, 2013 3:35:28 PM UTC-4, Enginwiz wrote:

Sorry - the screenshot of Repetier Host looks too bad. Converting it to JPG destroyed most of the detail.

Here comes a better one.

And an additional detail of the left side. 

[Enginwiz]

As per Matthews request I did another print quality comparison with the current versions:

Makerware 2.1.0 and Makerware slicer versus ReplicatorG 0040r16 and Skeinforge 50

printed on a Replicator 2 with Sailfish firmware 7.4 r1031, aluminium arms and glass plate.

For Makerware my latest Makerware slicer profile PLA - 0,10mm - 2 shells - 100% fill on http://www.thingiverse.com/thing:38390 was used.

For RepG / Skeinforge the latest 100 micron profile of Wingcommander whpthomas on http://www.thingiverse.com/thing:80728 was used.

Both prints were sliced with 0,10 mm layer height, one perimeter, one loop and 100% infill and printed in black PLA at 215°C and 120 mm/s.

Calibration cubes with a filament diameter of 1.80 mm printed upfront showed no under- or overextrusion.

On the Left: Makerware  --  On the right RepG / Skeinforge

There is some stringing on the RepG / Skeinforge print.

(On the bot deprime was set to 16 for both prints.)

Both prints have no gaps. There is a very small seam 

about the same size on both prints.

The seam on the Makerware print is hardly visible.

The seam on the RepG / Skeinforge print is a little bit more prominent.

Both prints look quite good. Maybe the stringing on the 

RepG / Skeinforge print might go away with some more

tweaking of the skeinforge profile and / or the print temperature.

[Eighty]

Enginwiz,

Can you clarify a couple of points for me?

 

1.) You're on a Rep2 with aluminum arms...were these Rep1 arms modified for a Rep2, or are these the new Bottleworks Rep2 arms?

 

2.) You used deprime=16 for both prints.  My understanding is that deprime shouldn't be used in conjunction with retraction.  I took a peek at the Makerware profile you used, and it still has 1.0 mm retraction set.  As best I can tell, the Skeinforge profile you used (Wingcommander 100um) has retraction set to 0.  I'm interested to know if your comparison would be different using the same retraction setting for both profiles.

 

3.) Where did you get the shiny silver filament shown in the last pictures?  It's surprisingly...shiny.

[Enginwiz]

Hello Eighty,

I did some measurements on the Replicator 2 for Bottleworks and bought a set of his modified Replicator 1 arms.
These were prototypes for the Replicator 2 and needed some filing and shimming. Anyway my Z-stage
is now more solid than the 10 mm Z-rods. His redesigned arms for the Replicator 2 / 2X look even better
and will be easier to install.

Wingcommander Henry requested a deprime value of 64 in onboard preferences - advanced for his sailfish
profiles published March 2013. In his latest profiles used for this test he switched back to 16 and my Rep 2
has this value of 16 in onboard preferences - advanced.

[Enginwiz]

The colour of the PLA used for this test is black.
You can see that on the first picture showing both prints.

I have a "JANSJÖ" clamp on LED spot lamp from IKEA
mounted on the frame of my Replicator 2 to illuminate
the immediate print area around the nozzle. This LED lamp
produces the shiny effect on the black PLA.

The PLA blend used for this test is Natureworks 4032.
I buy it on www.fabber-parts.de.

[Bottleworks]

The arms that he has are based on the older style arms.  The new arms are radically different.