Close



Results 1 to 10 of 55

Hybrid View

  1. #1
    Staff Engineer printbus's Avatar
    Join Date
    May 2014
    Location
    Highlands Ranch, Colorado USA
    Posts
    1,437
    Add printbus on Thingiverse
    UNDERSTANDING JERK SETTINGS
    There's a couple of ways to look at what the jerk settings do. From a dead stop, the jerk setting defines the first move rate Marlin will factor into the move planning, and it will accelerate from that rate as required. When already moving and about to make a change in speed or direction, the jerk setting defines the instantaneous step Marlin can make in the feed rate.

    Visualize this on a motor vehicle. For the smoothest ride, you put the vehicle in gear and slowly let out the clutch and give it some gas to gradually accelerate from a stop. To corner nice and smooth, you slow down to a near stop to complete the turn and then gradually accelerate back up to the speed limit. All this takes time. If you're in a hurry, you can drop the vehicle into gear without using the clutch and the vehicle will lurch forward. To save more time, you can screech around the corners almost to the point the vehicle goes out of control. Completing the turn, you might need to adjust the steering for a while to get the vehicle moving in a straight line again. In a similar way, the Marlin jerk settings allow you to set where in the range you want the printer to run - slow and conservative, or fast and bouncy.

    Let's fire up some gcode on the printer -

    Code:
    ; gcode for demonstrating XY jerk setting in X axis movements
    ; 
    G21       ; metric dimensioning
    G90       ; absolute positioning
    ;
    M201 X500  ; restore safe & fast acceleration value for homing; mm/sec per second unit
    G28 X      ; Home X to initialize the zero reference point
    ;
    G0 F6000  ; override DEFAULT_MAX_FEEDRATE with this; mm/minute unit
    M201 X100  ; override DEFAULT_MAX_ACCELERATION for X with this; mm/sec per second unit
    M205 X0  ; override DEFAULT_XYJERK for XY with this; mm/sec unit
    G0 X180
    G0 X20
    G0 X180
    G0 X20
    G0 X180
    G0 X20
    G0 X180
    G0 X20
    After homing the X axis, this gcode will just move the carriage back and forth on the X-axis. Gcodes are provided for manipulating feed rate, acceleration, and jerk settings pertinent to the X-axis. As provided, the M205 gcode command sets the XY jerk setting to 0. Acceleration has been set low so that we can observe any jerkiness at the movement end points (otherwise fast acceleration from the end points might mask it). This is the slow and conservative extreme. Run this, perhaps with a finger resting on the xcarriage to feel for any jerk or snap at the movement extremes. It's nice and smooth. Focus on the movements in the middle, not the first and last ones where Marlin is factoring coming from/to a dead stop. It doesn't matter in this test, but that's an important consideration for later when we raise the jerk setting from zero.

    Now rerun the gcode, increasing the value on the M205 command each time. At about M205 X30, you might start to feel a bit of a bump or tick as the carriage snaps to the opposite direction. Get real aggressive and try M205 X100 to observe how that bump or tick gets very distinct. If you haven't tried the value, load M205 X20. 20 mm/sec is the MakerFarm default setting for XY jerk. In the non-scientific testing we're doing here, that seems pretty appropriate. Those that have the ability to measure vibration with their phone are certainly welcome to do so in comparing the effects of settings. Share the results.

    Now let's do the same test on the Y axis instead of X -

    Code:
    ; gcode for demonstrating XY jerk setting in the Y axis
    ; 
    G21       ; metric dimensioning
    G90       ; absolute positioning
    ;
    M201 Y500  ; restore safe & fast acceleration value for homing; mm/sec per second unit
    G28 Y      ; Home Y to initialize the zero reference point
    ;
    G0 F6000  ; override DEFAULT_MAX_FEEDRATE with this; mm/minute unit
    M201 Y100  ; override DEFAULT_MAX_ACCELERATION for Y with this; mm/sec per second unit
    M205 X0  ; override DEFAULT_XYJERK for XY with this; mm/sec unit
    G0 Y180
    G0 Y20
    G0 Y180
    G0 Y20
    G0 Y180
    G0 Y20
    G0 Y180
    G0 Y20
    This starts at an XY jerk setting of 0 again. This time rest your finger on the Y-bed as it moves. The bounce at the endpoints can get pretty pronounced when you get to high value settings. Note that X and Y share the same jerk setting. You use the M205 Xx command to set it. There is no separate command for Y.

    Now we'll get more interesting and experiment with the extruder -

    !! WARNING: REMOVE THE FILAMENT FROM THE EXTRUDER BEFORE RUNNING THIS GCODE !!

    Code:
    ; gcode for demonstrating extruder jerk settings
    ; 
    G21       ; metric dimensioning
    G91      ; relative positioning
    M302      ; enable cold extrusion
    ;
    G0 F900  ; override DEFAULT_MAX_FEEDRATE with this; mm/minute unit
    M204 T5  ; override DEFAULT_RETRACT_ACCELERATION with this; mm/sec per second unit
    M205 E0  ; override DEFAULT_XYJERK for E with this; mm/sec unit
    G0 E10
    G0 E-10
    G0 E10
    G0 E-10
    G0 E10
    G0 E-10
    G0 E10
    G0 E-10
    Like our earlier testing with the extruder, the gcode will rotate the extruder motor back and forth the equivalent of 20mm filament feed movements. The gcode starts with the extruder jerk setting at 0, it runs smooth. Adjust it upwards and you'll start to feel the snap at the ends of the rotation. The MakerFarm default for extruder jerk is 5 mm/sec. IDK - I don't feel much difference between that and say 10 mm/sec. NOTE: My printer didn't seem to like high jerk settings like 40 mm/sec; the motor buzzed like it was missing steps. I didn't repeat it to diagnose or figure out exactly what jerk setting causes problems.

    There's another very important aspect related to jerk showing up in this test. Go back and rerun the gcode with different jerk settings. Note the difference in gear rotation speed that is obtained. The feed rate and acceleration settings in the gcode were purposely selected so you can see how controlling the jerk at endpoints can and does affect the max speed obtained of the overall movement. In our test example here, accelerating and decelerating to a stop at the end points using the acceleration constraint it's given, Marlin can't let the motor spin as fast mid-movement like it can if it's allowed to jump-start the feed rate to say 20 mm/sec. We're showing this on the extruder simply because it's where I lucked into the right combination of settings to notice it, and here we don't need to shut down the movement once we're out of room. The same concept would apply to the other axes. More importantly, we should be worried about this effect on X and Y since we're moving in those axes all the time.

    OK. Now we know that having small jerk settings might lead to better prints but they might take longer to print. Higher jerk settings will help get prints completed faster, but at risk of some ringing in the print corners as hardware settles from being snapped around.

    There's still more to know regarding jerk settings. Load up this gcode -

    Code:
    ; gcode for demonstrating simultaneous Y and Z jerk settings
    ; 
    G21       ; metric dimensioning
    G90       ; absolute positioning
    ;
    M201 Y500  ; set safe & fast acceleration value for homing; mm/sec per second unit
    G28      ; Home all to initialize the zero reference point for Z and Y
    ;
    G0 F6000  ; override DEFAULT_MAX_FEEDRATE with this; mm/minute unit
    M201 Y100  ; override DEFAULT_MAX_ACCELERATION for XY with this; mm/sec per second unit
    M204 T10   ; overrude DEFAULT_RETRACT_ACCELERATION for E with this; mm/sec per second unit
    M205 X200  ; override DEFAULT_XYJERK for XY with this; mm/sec unit
    M205 Z0  ; override DEFAULT_ZJERK for Z with this; mm/sec unit
    G0 Y180 Z10
    G0 Y20 Z8
    G0 Y180 Z10
    G0 Y20 Z8
    Here I've taken the movements from the earlier Y jerk demonstration and added some Z moves that are occurring at the same time. No, we're not going to use this to determine what Z jerk setting works. When you run it, the bed slowly moves forward and back, and the carriage slowly moves up and down. No snapping at endpoints. Now - edit the M205 Z0 to M205 Z20. Make sure you edit the M205 Z0 line. What's going to happen? Something on the Z-axis, right? Well, maybe, but we now get a pronounced snap on the Y-axis movement. Say what?

    The gcode as provided has the Z jerk term set to 0, and the Y jerk term set really, really high. When you run it, the low jerk setting for Z dominates the move planning and the high jerk setting for Y doesn't come into play. Welcome to Marlin move planning. It is solving in a three-dimensional world, and constraints you apply in one axis can and will affect the performance of what's happening in other dimensions where a move is occurring at the same time.

    I admit that I don't know the ins-and-outs Marlin move planning, but this seems to suggest it may be best to use jerk settings that are consistent for all three axes. The MakerFarm defaults are 20 mm/sec for XY, 0.4 mm/sec for Z, and 5 mm/sec for the extruder. Without knowing more about exactly how Marlin multi-axis moves, it seems we're at risk of the low value for Z affecting moves in the other axes. We were able to demonstrate that here. Again, without knowing more about Marlin planning code, this could be affecting not only Z-axis layer shifts, but also printing with spiral contours or ABL where Z is frequently adjusted, or especially with Z-lifts on retraction if that is enabled in the slicer. In the demonstrations here, I couldn't see any negative effect of running with the Z and extruder jerk settings the same as XY. So why worry about possibly constraining move planning by having them set lower?

    I'm running out of demonstrations to add to the thread. But the next test is where everything we've discussed gets combined.

    HOMEWORK AND INDEPENDENT STUDY
    About that snap we could see in the Y axis. Why couldn't it be in the Z axis as it changes direction? Ignoring the obvious fact that we feel it in the Y-bed... Change the gcode so the Z movements keep moving in the same direction. Marlin shouldn't be decelerating and accelerating Z anymore, right? Is the snap still there?

    I didn't try this, but you could put together some g-code with just Z axis movements to experiment with Z jerk settings. My guess is that nothing new is to learned by doing it, but...
    Last edited by printbus; 12-25-2014 at 06:13 AM.

  2. #2
    Staff Engineer printbus's Avatar
    Join Date
    May 2014
    Location
    Highlands Ranch, Colorado USA
    Posts
    1,437
    Add printbus on Thingiverse
    LINEAR CONCENTRIC SQUARES TEST
    This brings me to the last of the non-printing demonstration gcode I have currently thrown together. I plan to run the printer with some new settings for a while, perhaps adjusting to the need for some new settings in the slicer. There may very well be better tests, but this was straightforward to put together from the demonstrations already prepared. One thing I like about it is you know exactly what movements the printer should be doing, making it easier to anticipate what to watch for.

    OVERVIEW
    The demonstration involves moving the printer axes in a path outlining a stack of concentric squares, from 180mm to 2mm width. Between each square, the Z-axis is increased by 0.2mm to mimic a layer shift. Three passes at the stack of squares is made. The first pass moves the X-carriage and Y-bed at a high travel rate. The second pass is identical except the X-carriage and Y-bed are moved at printing feed rates. The third pass continues with the printing feed rates, but adds in extruder movements mimicking printing and also retractions around the layer shift points. Including homing and a few seconds of pause between each pass, the demonstration runs for around three minutes.

    !! REMOVE FILAMENT FROM THE EXTRUDER BEFORE RUNNING THE DEMONSTRATION GCODE !!

    Two versions of the demonstration gcode are provided. File squares_oem.gcode uses parameters from the MakerFarm distribution for the 8 and 10 inch i3v printers. The same values might also apply for the 12-inch printer; I haven't downloaded the 12-inch firmware to compare settings. File squares_fast.gcode is identical except for changes I've made to DEFAULT_MAX_FEEDRATE, DEFAULT_MAX_ACCELERATION, DEFAULT_ACCELERATION, DEFAULT_ZJERK, and DEFAULT_EJERK. Both files assume a 250 mm/sec travel rate, 100 mm/sec printing feed rate, Z feed rate of 2mm/sec, and retraction rate of 15 mm/sec. Make sure your printer is configured for a DEFAULT_MAX_FEEDRATE of at least {250,250,2,15} before running the gcode, since gcode commands can't increase above what the printer is set to. You can verify this by checking Vmax x, Vmax y, Vmax z, and Vmax e on the i3v LCD.

    The demonstration starts with a home-all, with all pertinent parameters set to what are known to be safe parameters. This way if you alter settings later in the gcode that mess up printer movements, the next pass of the gcode will restore anything needed for the homing to function properly. After the home all, gcode commands are used to set up certain demonstration parameters; those would be the parameters you could change for tailored rates you want to try. In the pass including extruder movements, changes to XY travel rate, XY print speed, Z feed rate, and retraction/replenish speeds would require editing hardcoded values in gcode commands throughout that pass.

    OBSERVATIONS
    I first ran the squares test with travel rate limited to the 160mm/sec rate determined earlier to not lead to X and Y belt flutter. I found that to seem woefully slow for a travel rate used in printing, and quickly raised it to 200 mm/sec and ultimately to the 250mm/sec rate from the MakerFarm defaults. The 250 mm/sec rate is pretty snappy. Although it is high from the reprap wiki notion of achievable step rates, I have the perception that a lot of people have kept the 250 mm/sec rate and no one has reported any problem with it. Interestingly, when I went to the 250 mm/sec travel rate, I no longer had any of the belt flutter that earlier drove me to the 160mm/sec rate. In going back and verifying settings, I'm convinced that flutter had to be an artifact of previously overdriving the X and Y motors.

    In observing how the printer accelerated from each corner of a square, I thought it was interesting to see how the printer would get to the printing rate of 100mm/sec fairly quickly. For the acceleration to a 250 mm/sec travel rate, however, I offer two opinions. First, even on my 8-inch bed the printer took a lot of time and distance to accelerate up to the 250 mm/sec travel rate. As the demonstration moves to the smaller and smaller squares, you see how the high travel rate is never achieved on many of the moves. Second, the sound of the acceleration makes it seem like the motors are straining under load, and slow to get to speed. These are step motors and that isn't the case, but it sounds that way.

    I like the 15mm/sec extruder max feed rate being applied to retraction and replenish. It seems snappy enough. I've been using that on all of my prints for the last couple of weeks, and it seems to work fine.

    TAILORED SETTINGS IN THE FAST DEMONSTRATION FILE
    I eventually settled on 750 mm/sec per second as values for X and Y in DEFAULT_MAX_ACCELERATION. That seems to be a great help in getting X and Y moving at the travel rate quickly, at least quick enough that the full travel rate should now be applied to a significant percentage of travel moves. At a glance, this may seem like a reduction from the values of 1000 in the MakerFarm DEFAULT_MAX_ACCELERATION, but with DEFAULT_ACCELERATION at 500, those higher settings were being clipped to 500. To benefit from the higher settings in DEFAULT_MAX_ACCELERATION, DEFAULT_ACCELERATION was also changed from 500 to 750. I could have just increased DEFAULT_ACCELERATION alone, but I just don't like propagating the confusion of having a setting that ultimately gets limited by another, so I set them to the same value.

    Z axis movements at the OEM settings seem slow, and have the same motor-under-load sound. Earlier testing had determined the Z motors I have are limiting me to a Z feed rate of 2 mm/sec. To speed up Z adjustments, I changed the Z term in DEFAULT_MAX_ACCELERATION from 5 to the 500 mm/sec per second originally used for X and Y. I maybe wouldn't have had to go that high to get the benefit I was looking for, but I've seen no issue with the high value. Z layer shifts are now very crisp and quick. I admit I've been rethinking the weight I've got strapped onto the Z-rods in the two aluminum shaft couplers - at some point they may be viewed as a limiting factor in Z motor acceleration. The extruder was left at the 500 mm/sec per second value in DEFAULT_MAX_ACCELERATION and DEFAULT_RETRACT_ACCELERATION.

    Based on earlier experimenting, I increased DEFAULT_ZJERK from the 0.4 mm/sec MakerFarm default to 10mm/sec, and DEFAULT_EJERK from 5 mm/sec to 10 mm/Sec. DEFAULT_XYJERK was left at 20 mm/sec since I didn't want to increase the risk of XY corners ringing due to jerk.

    IMO, these few changes in settings leads to an i3v that both looks fast and sounds fast. Combined with adjusting the stepper drivers in real use and not by voltage reading, the printer sounds like an entirely different machine. From the 160 mm/sec travel rate I entered the testing with, the settings in the fast file led to a time reduction of about 30 seconds in the demonstration. The difference between the OEM settings file and the fast settings file is about 15 seconds on my printer. That's not a scalable number that means much, but it does demonstrate the changes have led to a faster printer.

    In attempting to push test prints to a 100mm/sec print speed with these settings, I have ran into some issues, primarily with extrusion being light for short segments in solid infill layers like on the bottom or the top. This did lead me to reduce the XY acceleration term from 1000 to 750 mm/sec per second, but I also simultaneously increased my extruder temp and put more attention on what the actual movement speeds were on perimeters and solid layers. I think I've just gotten by with sloppier settings on earlier prints when I haven't been pushing the printer (I'm typically slicing with Cura Engine and Repetier-Host, with all speeds proportionally adjusted through one integrated speed slider control). I also haven't ruled out the possibility that the test issues have been with the filament or the extruder stepper driver setting. To further assess viability of printing at 100 mm/sec, I'm likely going to have to look at the rate of filament volume the hot end can properly handle. I also need to validate the Y motor driver setting and Y axis acceleration term with more weight on the Y-bed than I've had in the few test prints completed.

    FOLLOWUP COMMENT: The print issue I was having was evidently the stepper driver adjustment. I must have been skipping a few steps on the extruder motor. I haven't seen the extrusion problem after adjusting the extruder driver upwards a bit more. It is amazing how much quieter the printer runs with the readjusted driver settings. It's also important to note that my "run hot" type motors also now hardly warm up at all.
    Last edited by printbus; 05-02-2015 at 09:20 PM. Reason: migrated to offsite attachment storage due to 3DPrintBoard issues

  3. #3
    Staff Engineer printbus's Avatar
    Join Date
    May 2014
    Location
    Highlands Ranch, Colorado USA
    Posts
    1,437
    Add printbus on Thingiverse
    RIPPLE INVESTIGATION - PART TWO
    Disclaimer: The information provided is for the purpose of sharing ideas on what can cause the ripple effect and how it can be prevented and masked. There's a reasonable possibility that there is more than cause of a ripple artifact in prints. Results obtained on these test prints may or may not be reproducible in other print objects or on other printers.

    THE PHOTOGRAPHS
    Those that have taken a detail look at ripple on their prints understand how the appearance of the ripple depends greatly on lighting and viewing angles. To provide a reasonable consistency between photographs, test objects were photographed on a fixture with markings for object orientation, the lighting was from a mounted reflector lamp, the camera was on a tripod, and no camera flash was used. The standardized approach to the photos may not show the worst of the effect on each print - just a consistent view of it.

    Due to board posting limitations, result photographs are not embedded in this thread. Photograph file names are based on the test print number. Links to individual photographs are provided where appropriate.

    TEST PRINTS
    • (no photo) SETTINGS: Initial attempt at a baseline print. OBSERVATIONS: Artifacts from Simplify3D wipe setting complicating print finish. Print rejected; wipe setting disabled on all subsequent ripple test prints.
    • ripple_02: SETTINGS: Baseline print. OBSERVATIONS: Ripple present on the trailing edge of all corners, dimples, and recesses on all four sides of the test print. "Trailing edge" is defined as the direction the nozzle took in leaving the corner, dimple, or recess.
    • ripple_03: SETTINGS: Per baseline except Marlin XY_jerk decreased from 20 to 2. OBSERVATIONS: Some reduction in ripple on surfaces in the X orientation. Minor reduction in ripple on surfaces in the Y orientation. Some increased ballooning on edges, likely due to additional nozzle soak time at the minimal speeds enforced by the low jerk settings.
    • ripple_04: SETTINGS: Per baseline except Marlin overall acceleration reduced from 750 to 200. OBSERBATIONS: While the effect of the ripple appears to be reduced, the lower acceleration appears to "compress" the width of the ripple, not eliminate it. This would imply that the frequency of the ripple is independent of the print speed.
    • (rejected print due to possibility Marlin had reset before the print started)
    • ripple_06: SETTINGS: Per baseline except E jerk setting reduced from 10 to 1 mm/sec. With no change noted, E acceleration was also reduced from 500 to 100 mm/sec per second partway through the print. OBSERVATIONS: No effect on ripple noted.
    • ripple_07: SETTINGS: Per baseline except perimeter print speed increased from 50mm/sec to 75mm/sec. First print on new filament roll. OBSERVATIONS: Marked reduction in ripple appearance, likely from the ripple being stretched due to the higher print speeds.
    • ripple_08: SETTINGS: Retained speeds from ripple_07. Reduced extrusion flow rate by decreasing filament diameter setting to 1.60mm. OBSERVATIONS: No substantial change from ripple_07 results.
    • ripple_09: SETTINGS: Revalidation print of new filament roll using same settings and gcode file as ripple_02. OBSERVATIONS: Some loss of sheen from ripple_02. No difference in ripple effect other than that attributed to loss of surface sheen from the new filament.
    • ripple_10: SETTINGS: Same increased print speed as ripple_07. Filament temp reduced from 220 to 205 degrees. OBSERVATIONS: Near total loss of surface sheen. Ripple barely perceptible. Significant degradation in corner quality.
    • ripple_11: SETTINGS: Per baseline but filament temp increased from 220 to 230 degrees. OBSERVATIONS: Improved surface sheen. Ripple effect more apparent.
    • ripple_12: SETTINGS: Per baseline except combination of increased speeds from ripple_07, X and Y acceleration reduced from 750 to 200 mm/sec per second, XY Jerk reduced from 20 to 10 mm/sec. OBSERVATIONS: Ripple effect reduced from that observed in ripple_07. Compression of ripple noted in same acceleration settings of ripple_04 not apparent.
    • ripple_13: SETTINGS: Per baseline except object rotated 45 degrees so perimeters do not fall in X or Y planes. OBSERVATIONS: This one is tough to gauge due to a change in surface sheen. Some surfaces show no change in ripple effect. Others show a reduction in ripple, but also a difference in sheen.
    • ripple 14: SETTINGS: Per baseline except parameter dropsegments in configuration_adv.h reduced from 5 to 1. The dropsegments parameter instructs Marlin to skip or drop any line segments with step counts less than this value. Code comments do not explain why this is done. OBSERVATIONS: No change in ripple effect noted.
    • ripple_15: SETTINGS: Per baseline except perimeter print speeds reduced from 50 mm/sec to 35 mm/sec. OBSERVATIONS: ripple appears to be compressed similar to ripple_04 and reduced acceleration settings.
    • ripple_16: SETTINGS: Per baseline except layer height increased from 0.20mm to 0.30mm. OBSERVATIONS: Marked reduction in ripple.
    • ripple_17: SETTINGS: Revalidation print to baseline settings. OBSERVATIONS: Ripple comparable to other baseline prints in ripple_02 and ripple_09.
    • ripple_18: SETTINGS: Per baseline except layer height increased from 0.20mm to 0.24mm. OBSERVATIONS: Some reduction in ripple effect, but not as reduced as in 0.30mm layer height in ripple_16.
    • ripple_19: SETTINGS: Per baseline except layer height increased from 0.20mm to 0.28mm. OBSERVATIONS: Continued reduction in ripple from that observed at 0.24mm layer height.


    UNTESTED THOUGHTS

    • Belt tightness. Belts on the test printer are very tight. It is interesting to note that some suggest reducing belt tension will reduce the ripple effect. For example, read the comments associated with this ripple test object: http://www.thingiverse.com/thing:277394
    • Stretch/rubber-band effect in the belts
    • Attributed to beginning of belt flapping sometimes observed on trailing side of X and Y motor pulleys
    • Stepper motor drive level
    • Lash in the extruder drive anywhere from extruder motor to filament
    • Flex in the hot end heat break as the nozzle drags on previous layer around corners, recesses, etc.
    • Attributable to flaws in Marlin move planning for line segments involving acceleration. Is the acceleration between XY motors and the extruder motor properly coordinated?
    • Possible flex in the M3 screws used to attach belt ends to the X-carriage
    • Motor source voltage fluctuating axis and extruder motors both work to accelerate, possibly caused by varying voltage drop in RAMPS polyfuse


    FINDINGS AND CONCLUSIONS
    • Bear in mind that there may multiple causes of the ripple effect. Perhaps different causes result in different effects on different printers. Results from one machine such as my printer may not apply to other printers.
    • It could also be that the ripple is a resonation effect formed from the composite of multiple causes.
    • The ripple effect is not a result of the 2mm tooth spacing on the i3v motor pulleys, belts, or idler wheels. If it was, the pattern of the effect would be constant, and would not be affected by changes in jerk, acceleration, or print speeds.
    • Testing here suggests that the connection between ripple and XY Jerk or XY acceleration factors may not be as strong as typically thought. Here, reductions in XY acceleration seemed to compress the ripple more than reduce it. The momentum gained during lateral axis movement resulting from surface lettering and other shallow recesses has to be minimal considering the effects of acceleration. Yet the ripple effect on these minimal movements is just as pronounced as on 90 degree corners. Although not captured as part of these test results, the ripple effect can occur on recesses such as lettering on round corners. If the ripple was caused by something happening in the X and Y axes, it seems reasonable to assume that the observed effect would vary depending on the incidence angle of the lettering with respect to the X and Y axes.
    • Leave open the possibility that the ripple may be something non-mechanical. Without a microscope or other means to inspect the ripple at a near-molecular level, it's hard to tell what the ripple really is. I can't feel it on the test prints. Carefully inspecting some of the prints, the dark and light waves of the ripple seemed to switch - much like the effect of tilting a prismatic picture back and forth. Is the extrusion simply being imprinted with some iridescent effect? We all know the sheen of PLA can vary. Couldn't something be occurring during extrusion that causes the sheen to vary in the pattern of the ripple? Test results here related to changing the extrusion temperature or layer height somewhat validate this premise.
    • Reducing the XY Jerk, XY acceleration, and/or print speed can reduce the effect of the ripple by reducing the duration length on the print. The slower nozzle movements associated with these can lead to their own degradation in print quality, so there's a bit of a trade to be made.
    • Increasing the print speed surprisingly shows promise as a way to reduce the ripple appearance by stretching out the duration of the ripple.
    • There may be a connection the hot end flow rate and the ripple pattern. Testing here suggests significant reduction in ripple by increasing the layer height. One user has reported to me little or no ripple effect is apparent on prints made with a 0.30mm nozzle. Is the effect attributable to a vacillation in hot end pressure or temperature as the extruder decelerates to and accelerates from corners and recesses?


    FOLLOWUP COMMENT: Meh. I may have wasted a lot of time on this. A new roll of black PLA I obtained prints at a high gloss sheen at much lower temperatures than the second roll I was using in the ripple tests. I don't plan to repeat all the tests, but running one print at 0.28mm layer height and 80mm/sec perimeter speeds with this new filament printed 15 degrees cooler showed little or no improvement from the baseline print.
    Last edited by printbus; 06-02-2015 at 09:44 PM. Reason: migrated to offsite image storage due to 3DPrintBoard issues

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •