Blobbing due to small pauses. [help me]

that was totally it. in doing everything else i completely forgot to set the baud rate to match between repsnapper and the firmware.

Thanks

I've been exhibiting all the same issues here...

Just uploaded the sprinter firmware but in Repsnapper for mac I'm not getting a temperature reading (blank). In windows, repsnapper does report it. Any thoughts?
I may need to move to a later version of repsnapper mac but I'm clueless with compiling the latest version (seems that others are having trouble too)

If anyone has the latest version of repsnapper compiled for Mac I'd greatly appreciate a link to it!

Thanks guys, really great thread...


PS my current mac version is:
Oct 28, 2010 at the following link:
[sites.google.com]

Edited 1 time(s). Last edit at 06/14/2011 02:35PM by Adrian.

Adrian Wrote:
-------------------------------------------------------
> I've been exhibiting all the same issues here...
>
> Just uploaded the sprinter firmware but in
> Repsnapper for mac I'm not getting a temperature
> reading (blank). In windows, repsnapper does
> report it. Any thoughts?
> I may need to move to a later version of
> repsnapper mac but I'm clueless with compiling the
> latest version (seems that others are having
> trouble too)
>
> If anyone has the latest version of repsnapper
> compiled for Mac I'd greatly appreciate a link to
> it!
>
> Thanks guys, really great thread...
>
>
> PS my current mac version is:
> Oct 28, 2010 at the following link:
> [sites.google.com]
> -for-osx-binaries

I'm not using Sprinter yet, but I ran into a similar problem with RepSnapper, when I updated to the 2010-12-21 version of the 5D firmware. With older versions, temperature is reported correctly, but with that version, the temperature field remains blank.

If your trouble has the same cause as mine, then it's possible that the problem is in the Sprinter firmware, rather than in RepSnapper.

I haven't tried running it on a PC to see if there's a difference.

Thanks raldrich, I switched to the latest 5d firmware by Mendel-parts and I'm getting the reading again... Hopefully sprinter can shake that bug. I did confirm again that sprinter does report temp properly in windows but not in the older Mac version...

I loaded sprinter on RAMPS and I'm getting both extruder and bed temperature with repsnapper in MacOS 10.5.8 in the communications log but the GUI only shows the extruder temperature. Temperature control works fine too.

well i got sprinter running on my gen6 board. but now am running into another problem entirely.. the build gets a few layers in, then the electronics just reset, board shuts off and powers back on. I don't see any errors in repsnapper's log, so i'm at a complete loss

Just saw this thread resurface, and I thought I'd update how things are going with my Gen6 and Teacup. I've been running a bunch of Skinning test prints with Teacup. It took a bit of tweaking but I'm getting really clean prints now. No blobbing, no pausing and with the skin algorithm very smooth external surfaces.

I'm playing with the acceleration settings to help close the external surfaces fully. I've found that I've never been able to close the top surface fully because the extruder pulls the short threads off the surface. But, with acceleration enabled, it is slow enough on the short threads to avoid this.

Regards,

James

---

--
Check out my blog: AdventuresIn3-DPrinting

I can confirm at least that the electronics restarting is an issue with sprinter on my gen6 board.. i switched back to the mendel-parts firmware, and didn't encounter the problem at all... man this is frustrating

Good to hear about your stuff working well jim. Were you ever able to get the teacup firmware to communicate with repsnapper or are you still just sticking with the host software?

I haven't got Repsnapper working. I have verified that the values being returned from the Teacup firmware are correct using portmon. It purely seems to be a problem with Repsnapper interpreting the response. I have noticed that when it does get around to displaying a result it is 8 values old, making me suspect the command buffering code in RepSnapper is slightly screwy.

I haven't looked through the code on RepSnapper yet as I don't have a why to recompile it for PC at the moment.

Instead I've written a Python script that heats up the extruder and monitors the temperature while I'm waiting to print. Then I switch to send.py to actually print (with a GCode in my Gcode start-up to set the extruder temp again). It seems to work reasonably well, but I miss the graphical interface of RepSnapper.

JB

---

--
Check out my blog: AdventuresIn3-DPrinting

jim_blag: I suggest you try out [github.com] and specifically pronterface. I think it'll suit your needs perfectly. And yes, repsnapper is buggy, I can only make it work with 19200 baud for some reason.

---

--
-Nudel
Blog with RepRap Comic

Yes. I also recommend Pronterface (part of Kliment's Printrun). Much better than Repsnapper since you don't have to wait for it to interpret the g-code if you just want to send it to the printer. Also, it supports loading the g-code into a microSD card like Kliment's SDRAMPS and printing from it. I expect that this will eliminate blobbing due to pauses (also called segment pause).

I just ordered a microsd adapter from Gravitech which I expect will also work with RAMPS. See this thread.

Edited 1 time(s). Last edit at 06/24/2011 06:41AM by brnrd.

unfortunately with sprinter on gen6 Pronterface is not an option right now, after a long chat with kliment and a few others on irc today i got sprinter "working" with my electronics.

the problem with pronterface and gen6 right now is that it will home before starting the print.. then just stop. it will just home and sit there. and if you use the mendel-parts 5d firmware, you get resend errors on just about every line of code sent.
I haven't tried teacup on gen6 with printerface yet but so far looks like at least till kliment figures this out, pronterface is a no go for gen6 :\

I have had excellent results now with Skeinforge41, thanks to the SF thread, running Gen6 and repsnapper but i'm using windows not Linux. Everything is working very well

---

__________________________________________________________________________
Experimenting in 3D in New Zealand

jim_blag Wrote:
-------------------------------------------------------

>....
> I then decided to look at the retractions. There
> are a lot of retractions that are unnecessary,
> they cause more of a blob due to the pause then
> they would if the head just moved straight away.
> So I wrote a script that removed any retractions
> where the next move was less than 1mm away. This
> also helped noticeably with the blobs. Removing
> those at the end of strings, but it didn't help
> with blobs at the end of a layer, which are the
> most noticeable ones since they are on the outside
> surfaces.
>
> ....

Would you mind sharing this script? Those unnecessary retractions always annoy me!

In addition, try send.py to send your g-code. It seems to ignore all replies from the FW, so your comm. problems get minimized.

If that doesn't help, try using Teacup as Firmware - it seems faster to me than any other flavor.

ST

Here you go. Since it was a quick test I can't vouch for its robustness.

Good luck.

James

---

--
Check out my blog: AdventuresIn3-DPrinting

Hi Jim

Regarding CleanRetractions.py - do you run it on an exported gcode file or do you add it to the Skeinforge print chain so it is included in every build?

Cheers

You could also try theodleif's amended dimension.py, which removes retractions where the travel distance is short. Works within Skeinforge 41m, configurable in SK GUI. See this thread: [forums.reprap.org] and make sure you get the latest version (linked in one of the later posts).

It's run on the exported GCode, it's not written to be inserted in Skeinforge.

JB

---

--
Check out my blog: AdventuresIn3-DPrinting

Hello,


I'm get blobbing on the test cube too, regardless of trying large variations in speed, temperature and retract settings. Different firmwares don't help either (recent Sprinter and latest Marlin with different advance settings. Both produce the same result. It's to be expected when one is a direct derivative of the other perhaps. I am trying Teacup today.)

Then l noticed something peculiar:




Settings:
Sells mendel
Gen6
Marlin 0.94E
SF40+ - various versions tried

20mm test cube
0.15mm layer height, 3.5 W/T
80 mms
175 dC
1 extra shell
0.0 fill - hollow cube
6 solid layers thickness

Observations:
1. For 6 solid layers the cube prints normally, with no blobbing.
2. Hollow section of cube starts and so do the blobs.
3. Blobs disappear again for the 6 solid layers on top of the cube.


I looked at the Gcode for the perimeters on solid fill sections and sparse fill sections. The amount of filament extruded is volumetrically identical. The extra filament lost to the blob can only be accounted for with the convex curves of the cube walls. Where there are blobs, the filament is stretched and dragged in at subsequent corners to make up for the deficit.

Somehow the X and Y of my mendel are not keeping pace with the E of my extruder. Inaccurate firmware volumetric calculations? Real world limitations to the XY acceleration possible? What do you think?

Next problem is why blob on sparse layers only?

I suspected the blobs were varying inversely with the amount of filament laid down on that particular layer. I printed a another test piece to confirm this: 40-20-10 calibration piece has step changes in it's cross sectional area, so it should provide visible proof:







And it does. The layer start positions are circled. Almost no blob for layers around the base, same sized blob as the 20 mm hollow cube for layers equal to that cube, and a larger blob for the small cross sectional area of the tower.

I know nothing about python and programming in general. But presumably the volumetric extrusion calculation to feed rate acceleration calculation are off somehow? And small total layer volumes exaggerate this misalignment. Or are the acceleration settings in my FW too optimistic? Perhaps Gen6's calculations for micro stepping make high acceleration impossible. Please sort me out!

woodsmoke.

.

Edited 6 time(s). Last edit at 09/02/2011 12:00PM by Woodsmoke.

Woodsmooke, did Teacup do the trick?

I see a small blob at every retraction. When the extruder resumes after a retraction, it spits out a small blob of filament. I've experimented with jitter, clip, different temperatures, retraction speeds, retraction distance and "Restart extra" distance, without success.

jim_blag: Could you post your blob-free Skeinforge profile?

Sorry jseaber, for this tardy reply. I've had a temporary contract for the last month that ate all my time.
Teacup rather confused me I'm afraid. I don't believe I got it working.

I did work out that my blobbing problem was speed related though. Increasingly slower test prints reduced then eliminated the issue. That leads me to believe that the post retraction blob, when the printer sets off again, is something to do with acceleration settings. Perhaps the real world acceleration lags behind what the firmware is calculating? Ie belt stretch or something? So you get excess filament because the print head hasn't reached the speed or distance that it should have?

Doesn't account for all the symptoms though.

woodsmoke.

I had this same issue with my Mendel/Gen6/5D. I was unable to solve it with any tuning in skeinforge. Then I noticed, as others have pointed out, that when there was blobs there was error messages. I upgraded to Marlin/Sfact/Pronterface and the problem went away. I have had other issues such as random resets during prints but I suspect those issues were related to bad STL's since once I repaired the STL's the reset went away.

---

----------------------------------------------------------------------------------------------------------------------------
www.Robosprout.com RepRap Mendel parts and accessories.
Message if there is anything you need...I have more than what is listed on my site.
Located in the Spokane, WA / Coeur d'Alene, ID area.
Contact: Robosprout@gmail.com Flickr: [www.flickr.com]