Perimeter detached from infil

[ktmseth]

Hey All, I was a terrible customer and completely ignored my build thread in my excitement to get teh Max up and running, after some teething problems with calibrations and finally zeroing in on what i consider at least passable quality prints, i have run into a problem. larger prints are experiencing a situation where the perimeter passes do not meet the infill. In fact at the worst locations i can see completely through to the heated bed. Is this speed, filament diameter, layer height? Otherwise the troubles have just been figuring out retraction to clean up prints and how to speed full print cycles. i have gotten the bed as flat as possible, though the acrylic warps terribly in the middle in some situations, not overly happy with that aspect of things as heat, time etc all makes for a print that is not completely flat, instead crowned.

That being said, the max is a wonder of DIY engineering and im quite happy with the results so far. I am heading out now or id post a picture of the issue, and will do so when i return. Please Help!

--Seth

[Polygonhell]

Assuming the generated GCode is good, the most likely culprit for the fill not reaching the edge is backlash, which is usually a function of the belts not being tight enough.
I use predominantly kiss slicer where I do set the edge/infill overlap to 75% but I don't get gaps at the edges.

[ktmseth]

Thanks Polygonhell, ill try the belt tightening route and see how that works. I may also experiment with kiss slicer as well if eliminating backlash does not solve my problems.

--Seth

[geneb]

With the Rostock MAX, I _seriously_ doubt belt lash is a significant contributing factor. Mine have been tight as guitar strings from day one and I've got (or HAD!) horrible infill problems.

I printed my best infill yet the other day. I used Cura with an infill overlap of .8 (80%). The Slic3r guys really need to add this option.

g.

[ktmseth]

Okay so this is even more apparent in its severe detachment (perimeter from infil) No matter what settings, the infill refuses to contact the perimeter, this is generally a problem around 100% of a print. obviously, as you can see, its closer in some areas and more prevalent in others, the gcode displays correct layers when stepping through them...please help ready to sell this thing!

I should also note that the perimeter is exactly sized as the model is built (built in NX 8, exported as stl and sliced with slicer both the included version and the new .098 revision exhibit the same problems. Someone suggested a switch to kisslicer which i am not opposed to but i have not come across a good setup tutorial on configuring for the Max. I also havent had much time to search out any kiss info either...Links would be appreciated, PM, whatever, desperate in CT.

Thanks
-Seth

[Polygonhell]

Looking at that I'd say you are losing steps, or one of your belts or pulleys is slipping because the infill is overlapping the the perimeter on one side, but not reaching the other.

I'd check the screws on the pulleys first, use some loctite or other threadlocker to hold them in.
if it's the stepper skipping, it can be one of a few things
it could be mechanical, and there is too much resistance to motion on one of the columns.
It could be the stepper drivers set too aggressively or not aggressively enough, are you using a RAMBO or RAMPS?
It could be your trying to move faster than the steppers are letting you (turn down your travel speed in the slicer)

[ktmseth]

I am going to try the first few layers now running slower speeds and tightening the belt pulleys. This is a Rambo board, suggestions on settings for the motor drivers? When off, the print head can easily be move around, with no apparent binding, so I don't think that there is any mechanical hindrance to motion in that regard.

Thanks for the suggestions, ill report back

[JakeCShake]

Just a reminder....be sure not to move the print head around too fast when off. It will produce a charge back to the board and possibly short out. Just an FYI....

[JakeCShake]

Also...Barnett and I have had much improved results with Kisslicer....although I haven't been able to play with in two weeks; it at his house. : (

[Polygonhell]

Assuming you've ruled out loose pulleys etc.
if you're using a RAMBO board, and you didn't change the default motor driver values in the firmware, I'd start by pointing a fan at the motor drivers.
You can turn them down in configuration_adv.h.

[ktmseth]

The driver values are at 195 as the stock setting, I moved to 180, no appreciable improvement in the problem, lower still? Whats acceptably low? Pulleys are all tight, verified no free play in cheapskates, belts are tight.

[Polygonhell]

I'd start by trying to figure out which tower is skipping, it's likely the one in the direction that the infil is moving. If it's not obvious during a print I'd write test GCode to try and reproduce it.
After that, I'd try and figure out what's different.
I'd try dropping print speeds and travel speeds to really low values (10mm/s or less) to see if it is likely an accelleration or speed problem.
Unfortunately if it's loosing steps there are a few things it can be and all you can really do is try and isolate them, there is no magic this is the issue answer unfortunately.
One possibility I forgot to mention is if the head isn't moving parallel to the bed, and it's rubbing on the bed or the printed material as it moves, that can be enough resistance to cause one motor to slip.
I usually look at the GCode visualization, and compare it to what i'm seeing in the print, and look for obvious correlation, like the perimieter looks good and if the issue is as it appears to be when the infill starts, I'd look at the travel move before the infil to see if it's moving in the direction of the shift.

I think I'm running my drivers at 185(with a fan), but I've run them as low as 135.

[Highcooley]

As I'm still in the detached infill boat as well, I would like to post my findings so far. Of course, this does not necessarily apply to other builds, as there can be several causes for this unwanted effect:

- I am 99% sure, that no motor is missing steps. Otherwise, it should be visible in the print by complete layers being shifted to one side. But the perimeters all fit, as well as do the detached infills.
- I also notice jerk of the carriage movement when printing slowly. It mainly occurs during perimeter printing But not during infill printing. I think it is because the infill is either straight lines or sharp turns and does not change the direction of movement only slightly.
- My explanation is, that the carriage is not moved quite as far to a certain point, if it is approached from different directions. Lets say, our perimeter is oriented along the X axis. The carriage has time to reach the correct Y position during the movement along the X axis. During the infill, the carriage approaches the perimeter along the Y axis, leading it not to reach the correct Y position.
- It could be backlash caused by the timing belts or by too tight fit joints (leading the rods to slightly bend first, before moving the carriage) or both.
- When printing really slow, the infill is definitely closer to the perimeter than during fast printing. If I am not mistaken, this leads more to too tight fit joints than to too sloppy timing belts.
- Another thing I noticed is, that the carriage slightly tilts towards the direction it is moving for less than 1°. Attach a long pencil to the carriage and put some tape at its end like a little flag, pointing towards the print bed, to make this visible.
- Tightening the belts didn't change much...or at least, it was not visible to me. However, I haven't compared two identical prints at identical speed before and after the change.
- I already sanded all the rods and joint mounting parts to reduce friction, but the problem is not solved yet. Probably, I am going to apply some grease to the joints next. My worst nightmare would be to sand any joint connection too much and worsening the precision irreversible.


- I read about the overlapping infill solution many times now. But for me, this is more like a hack than a proper solution, leading to accumulate plastic on the sides where the detached infill is closer to the perimeter. I would rather like to solve the actual problem by its roots and keep the hack for when I don't succeed otherwise. This said, I don't have the right solution just now.

[Nowhereman]

Hi All,

I got my Max a few weeks ago and I'm having a lot of fun with it. I just thought I'd chime in here and say that I too am having the same problem.

It's nice to know I'm not alone.

I've tried all of the suggestions here so far and I still have the same problem. I've even started looking at the Marlin firmware and I've been playing around with the delta axis movement settings. But so far I haven't been able to fix this problem. When I take measurements with the printer is in home position I notice diferences between the following measurements for each arm:
// Center-to-center distance of the holes in the diagonal push rods.
#define DELTA_DIAGONAL_ROD 269.0 // mm

// Horizontal offset from middle of printer to smooth rod center.
#define DELTA_SMOOTH_ROD_OFFSET 198.25 // mm

// Horizontal offset of the universal joints on the end effector.
#define DELTA_EFFECTOR_OFFSET 33.0 // mm

// Horizontal offset of the universal joints on the carriages.
#define DELTA_CARRIAGE_OFFSET 35.0 // mm

I modified the code to take into account for the exact measurement of each arm (X,Y,Z) but it didn't have any effect.

I also noticed one of my stop sensor switches was being stopped at the little rounded handle part of the switch and the other two were stopping in the middle of the switch. I fixed these but the problem is still there...

I could probably write up a program that would take the original gcode and fix the movements based on the way my printer acts to "fix" the problem and write a new gcode file with the necessary changes. But I'd rather figure out what the cause is and fix that rather then fix the symptoms.

Please let us know if anyone finds the real problem and has a fix.

[Polygonhell]

If you look at his attached pictures the original poster is not having the same issue, the infill is virtually touching the skirt on one side, the whole print is offset.

As to the perimeter issue, I don't use slicer, which may be the biggest reason I don't see it, it's possible that there is enough rounding occurring in positions in the delta coordinate conversion that the infil, is short of the perimeter in slicer, but the basic math I did suggested that any rounding was in the <0.1mm range.
Both KISSlicer and Cura allow control over the edge infill overlap. I set it to 75% in KISSlicer, rather than the default 50%.
There is a lot I don't like about the Slic3r calculation of default extrusion width.
FWIW I had 2 mechanical issues that were exacerbating the issue for me, a loose pulley and som backlash in the belts

[Polygonhell]

- I already sanded all the rods and joint mounting parts to reduce friction, but the problem is not solved yet. Probably, I am going to apply some grease to the joints next. My worst nightmare would be to sand any joint connection too much and worsening the precision irreversible.

If you look at how slop translates from the joints to the carriage I actually don't think this is much of an issue, but I can certainly see being tentative here.
If you're seeing movement that isn't flat, it's likely a mechanical issue, the way the firmware works the individual linear segments are <1mm for any move you're likely to be printing and the error is very small.

[Nowhereman]

Hi All,

Just a note, I'm using Cura for my gcode for the last couple of days since it makes a better (more legible) slice then slic3r does on small letters & numbers. Cura uses skeinforge for slicing, and I was looking closer at my gcode and I noticed my extraction speed in my gcode was F6000!! This is because Cura takes the value from the "Advanced config" menu setting under Retraction|Speed (mm/s) and multiplies it by 60. I had this setting at 100 which Cura turned into F6000. I know my printer can't retract that fast and I've noticed that retraction hasn't been working right lately.

I'm hoping a more reasonable speed like 4 which Cura turns into F240 will actually make the retraction work. I'll have to test with this speed to see how fast it needs to be.

I'm hoping that because it wasn't retracting at all in my prints it was slowing the movement of my extruders head causing the gap between the infill and the perimeter. I can't try it right now, as it's late and my printer will wake up my family. I'll do some tests tomorrow and I'll report my findings. Maybe others want to look at their gcode and see what the speed of the extracting is set for...

Update... "I tested the slower retraction and it's still the same... Doh!"

[ktmseth]

Just about to begin another attempt with really slow infill, motor drivers turned down and slow print speeds to see if this cures the problem. i also raised the zero z height just a touch to ensure that no dragging is occurring as i noticed that part of the print the extrusion was "mushed" wider as if the print head is to low in a few places (the acrylic surface warps under heat it seems). Updates to follow.

[barnett]

Hi Everyone,

So far, I'm not having a huge issue with this problem. Sometimes it's close, sometimes it's perfect, but it hasn't been really bad for me (yet).

So what would happen if you posted the gcode and an image showing the troublesome infill it produced... and then I tried running that gcode on my machine and post the image. As long as it's something small and we have similar filament size and bed temps, would that work? Would it point us toward the slicer vs the firmware/machine?

Just an idea. I should say I may be away from the printer for the next 3 days, but I'll get to it when I can.

Barnett

[geneb]

On Tuesday I got my best print yet out of the machine. My infill/perimeter issue is basically fixed.

I went back to square one and re-calibrated the entire machine.

I started out by using the new tower base points (these are listed in the current rev. of the assembly manual in the calibration section) and then I added a new step, calibrating the concave/convex shape of the build surface (or what the machine THINKS that is).

If you do "G28" and then "G1 Z0 F3500" you should have the same distance between the nozzle tip and the bed as you got from the tower base points. The key parameter here is DELTA_SMOOTH_ROD_OFFSET if you're using the Merlin firmware and PRINTER_RADIUS if you're using the Repetier firmware.

The default setting is 198.25 as shipped from SeeMeCNC. Assembly variances can and will cause this value to change a bit.

If your nozzle is higher at the center than at the tower base, you need to increase this number. Increase it about .5mm at a time. Don't forget, with each change of this value, you'll need to re-calibrate your tower figures because they'll have changed due to the concave/convex adjustment.

Conversely, if your nozzle is lower, decrease the value to pull it higher.

Another important point to note is managing the grip the extruder drive has on your filament. I was WAY over tightening the hobbed drive to the point where it was actually reducing the diameter of the filament as it passed through the drive. This resulted in the slicing software thinking it had a lot more filament to work with than it actually did.

Correcting the drive tension in conjunction with the re-calibration resulted in some excellent results.

This is what my infill/perimeter gap looked like before the changes:

[img]http://imgur.com/qxwhP8U[/img]

This is how it looks after:
[img]http://imgur.com/yORzC6l[/img]

I used KisSlicer v1.1.0.5 x64 with an Infill Overlay of .75 to slice the cube.

I've since printed a radio knob and a large threaded ring with excellent results!

g.

[Nowhereman]

Thanks Barnett for the offer to print my gcode to see the result on your printer, that will be useful to make sure the gcode is not the problem and the trouble lies somewhere else. But for now I'll try Geneb's recalibration ideas and hopefully I'll have similar results to his.

Thanks Geneb for the method and for the pics, my cubes look the same as your original, and I'm hoping I can get mine to look like your new version. It is promising, as right now, it is quite frustrating...

I wont have time for awhile to make the adjustments, but I'll let everyone know how I make out so others having similar troubles will know the results.

Nowhereman

[Nowhereman]

I thought I'd post a little update...

I did follow geneb's advice and set my DELTA_SMOOTH_ROD_OFFSET to the average of the three on my printer but that didn't seem have much of an effect.

I decided maybe there is something causing the arms to be a little stiff, so I went over each moving piece with WD-40 and made a gcode script to give the arms a workout, big movements at high speed back and forth for a half hour or so. That still didn't seem to make a difference.

The next day though it just seemed to be printing better. Maybe the WD-40 sank into some of the joints, I don't know but I'm happy with my printer these days.

Good luck,
Nowhereman

[geneb]

EH? Where did I write about setting the DELTA_SMOOTH_ROD_OFFSET to an average of _anything_?

g.

[mhackney]

I've started down the path of understanding and solving this infill problem - see my build thread post.

It would be great if we could band together and print the same calibration thing and report our conditions and photos. I've create such a thing and posted it in my thread.

cheers,
Michael

[mhackney]

Well, I solved my infill gap problem and suspect the "fix" may be generally applicable to others with gap problems. Here is a lengthy post (plus read a few leading up to this one): Don't Get Those Delta Arm Blues!

Basically, in my case, one stiff U joint was causing the problem. Imagine if you had 2 or more stiff U joints!

cheers,
Michael