Surface blemishes caused by brief pauses; firmware to blame?

On certain high-resolution models with lots of curves and arcs, such as the Yoda head, I've noticed that my printer will simply stop moving for a fraction of a second here and there, causing these ugly blobs to appear on the otherwise nice-looking surface:



It seems to happen more in areas with a lot of contour. My Prusa is rocking a Sanguinololu 1.3a and uses Pronterface and the Marlin beta 1.0 firmware, from [github.com]. The acceleration settings are unchanged from the defaults.

This feels kind of like an issue with the look-ahead acceleration, or possibly my poor Sanguinololu's ATMEGA644P not being fast enough to keep up. Thoughts?

I've seen this problem a lot with Pronterface and either Sprinter or Marlin on a MacPro with OS X 10.5.8. I guessed it was due to the printer not getting data fast enough from the Mac when I'm doing other things to keep it busy while printing. Now, I print everything from SD card to avoid this problem.

Those are Yoda's moles. :^)

In all seriousness, you might try reducing the poly count a bit, and see if that gets you there. You may be operating near the transmission limits if the object resolution is too high (lots of short line segments, packed tight).

I believe Netfabb can do this.

so would printing from your sd card help?

spad007 Wrote:
-------------------------------------------------------
> so would printing from your sd card help?

Referencing what brnrd was saying, printing from your SD card could eliminate the problem of whatever your host software is, like pronterface, not being able to keep up with the moves of the printer. For example, if your printer is executing gcode commands faster than your host software can send them, then your printer will have to wait until it receives a complete command from the host software. So if pointedstick's problem is infact caused by that, then printing from the SD card could be a solution.

I've had similar problems if I try rendering something or open a file in solidworks while I'm printing. It has to do with the scheduler for the operating system, it has to give some Cpu time to a different program and pronterface slows down.

Hoped this helps.

bdc

Stay calm out there

Had the same problem. For me the cause was pronterface. With high detail models the update of the gcode-viewer window during print was to to cpu intensive so the notebook was unable to send data fast enough.

I then patched pronterface to not update the view during print (didn't need that anyway) . All problems gone,
no pauses any more.

fks Wrote:
-------------------------------------------------------
> Had the same problem. For me the cause was
> pronterface. With high detail models the update of
> the gcode-viewer window during print was to to cpu
> intensive so the notebook was unable to send data
> fast enough.
>
> I then patched pronterface to not update the view
> during print (didn't need that anyway) . All
> problems gone,
> no pauses any more.


That's awesome. Can you contact Kliment and see if you can get that added to master?

If the other GUI features of pronterface are unnecessary, can't you send the Gcode over with pronsole?

I use most of the other buttons (home, move) so I'm quite happy with the rest of the GUI.

Did anyone ever solve this issue.... I am having the same problem.

Im running at Prusa with Windows/RAMPS/Slic3r/Pronterface/Marlin (previously Sprinter).

The problem started when i switched to Pronterface (which i really like and want to totally switch to if i can get this fixed).... I can print the same exact gcode files with RepSnapper perfectly, no pauses or blobs.

When i use Pronterface my printer has a few short millisecond pauses that cause little inconsistencies in the surface finish, but then every now and then it will have a 2 - 5 second pause that leave a huge blob. (switching to Marlin from Sprinter helped a TON with the surface finish, but there are still some little blobs/inconsistencies).

Like i said, when i print these same files with RepSnapper i don't get any of that behavior. I think it probably is that Pronterface isn't able to send gcode fast enough because it slows down as its updating the gcode viewer window (or it's doing something else which takes up processing power).

@fks, can you explain how you patched Pronterface to not update the gcode viewer window during a print? i.e. what file you edited and what code you replaced/edited and where.

Thanks!

Turn off the automatic temperature updates (checkbox).

---

Bob Morrison
Wörth am Rhein, Germany
"Luke, use the source!"
BLOG - PHOTOS - Thingiverse

Thanks I will give that a try this weekend. (maybe sooner if i can get the time!)

I am having the exact same problem. I've tried the recommended solution of disabling updates on Pronterface, but I'm still getting the same blobs as in the Yoda picture above when I'm printing curved surfaces. I even tried from a brand new Corei5 computer I just received to ensure that it didn't have anything to do with the speed of the computer. Any other thoughts on what to try?

For reference, my setup is Prusa (v2), LM8UU on X/Y/Z, T2.5 belts and machined pulleys, 1.75mm Makerbot ABS, Greg's extruder, purchased hobbed bolt, Budaschnozzle hotend, heated bed, glass bed with kapton tape, Sanguinololu, Marlin Firmware 1.0.0, Pronterface, Slic3r. Oh, and the object I'm testing on from Thingiverse is the Stanford Bunny. It prints beautifully from my Makerbot Thing-o-matic without any of the blobs.

I have tried everything I can think of on the hardware side and I'm starting to feel that this is a software issue. I've tried playing around with the settings in Slic3r, but keep getting the same results regardless of how fast/slow I go, whether I'm using Sprinter or Marlin, etc. I seem to have the same phenomenon as 'Pointedstick' where it seems to be 'stuttering' around curves causing the blobs. Any feedback on something I could try or check would be greatly appreciated. Thank you so much in advance!

Try using sender.py, which comes with skeinforge. Its a tiny little program that does nothing but send gcode to the printer. If you still get issues with that, its not an issue with the host software.

Could the pauses be caused by data transmission rate issues on the serial side? I just updated the rate in my (Marlin) firmware to 250000 rather than the 115200 default and it seems to run smoother... The only issue this caused was that the printer would reset randomly - turned out to be electrical noise from other kit around the house. Solution : I wrapped the USB cable in kitchen foil, earthed that and then wrapped insulation tape round that. No more reset crashes! (Yet). Just a thought...

Also, I believe that Marlin buffers its instructions as they are received. It might be worth having a look at increasing the buffer size; I would suspect that if the problems are caused by interruptions in the flow of instructions being received, a bigger buffer would help, providing the overall communication rate is sufficient ?

Thanks so much for the suggestions. I tried using send.py, but had the same results so I don't think it's a problem with the host software. I also tried the other suggestions of messing with the baud rates, port settings, and making sure there are no electrical interference and all with the same results.

HOWEVER, I have finally found a setting in the Marlin firmware that allows me to print without blobs! If I set the DEFAULT_MAX_ACCELERATION to an extremely low setting, it finally prints without the blobs (or very little at least) and without the stuttering around corners. Even changing the DEFAULT_MAX_FEEDRATE in Marlin or the Print Speeds in Slic3r doesn't seem to make any difference on the stuttering so it seems to be an issue with acceleration. However, I have to adjust the setting so low that it prints unbearably slow so I know there is still something wrong. I still need to figure out the root cause. Any ideas on what may be causing this issue and/or how to resolve it? Thanks again!

rhmorrison Wrote:
-------------------------------------------------------
> Turn off the automatic temperature updates
> (checkbox).

I also tried turning off the "Monitor Printer" check box, which is what i think you meant to say. I also bumped up the process priority of python.exe (pronterface) in the Windows Task Manager to make sure it had all the processing power from the computer it needed.

Both didn't have any effect, my Yoda print still came out the same.... small blobs all over it from tiny pauses (seems to be where there is a lot of contour), it also still had a few big blobs from long (2-5 second) pauses.

I printed another object, the hollow pyramid, and it comes out with a smooth surface due to no short pauses, but it would still have the occasional long 2-5 second pause and a big blob.

Seems like the short pauses are due to complex curved surfaces which there are a lot of on Yoda, but i don't know what causes the long pauses, they seem to be pretty random. Any thoughts?

I'm also having this problem.

Windows XP
RAMPS 1.4
Sprinter 115200 baud
Pronterface

I get long pauses 5-30 seconds randomly during a print. They somewhat coincide with the amount of processing power i'm using. I haven't printed anything high-res enough to notice small blobs, only large ones.

I resolved this issue by switching to an older dell laptop from my newer HP laptop. both are running win xp.

Someone should update the Print Troubleshooting Pictorial Guide to include this issue. The picture of PLA with water absorbed into it looks almost identical to this problem. I thought that was what I was dealing with until I correlated the head stopping with the blemishes. I'll be changing to an LCD with SD card shortly, but in the meantime I minimized Pronterface and am the symptom had disappeared.

Sorry to bump this, but I had the same problem the other way round. I had very similar pause-bubbles in my first print using a LCD and an attached SD-card.

If anybody ever encountered that problem this way round, please say so!

pause bubbles like that can also happen why the z axis moving to the next layer or at the start of the perimeters,

---

-=( blog )=- -=( thingiverse )=- -=( 3Dindustries )=- -=( Aluhotend - mostly metal hotend)=--=( Facebook )=-

guys. this is also possible a hardware issue, such as loose belts, or wires that are rubbing against rods. i would oil the rods, and check to ensure no wires are rubbing against rods, that there are no sticky parts on the rods, and that the bed and carriage are tight.

this would be why printing with little acceleration and speed would also fix the issue.

Edited 1 time(s). Last edit at 05/13/2014 01:08AM by jamesdanielv.

Naaa.
Cant be an hardware issue. I am running the same, unmodified hardware off my PC and get no such bubbles. On top, the bubbles did not appear when the printer started a new layer. It appeared pretty random. Although there was a tendency to get the bubbles somewhat on the same place in one of the following layers. But without a obvious pattern...

I made a video to better explain it. There is text to clarify what exactly I did.
[www.youtube.com]

For me this problem was scaling, printing off of my SD-card, which worked fine.

When I made a model smaller, the details that were too small would print out like that. The larger I printed it, the better the model would turn out.