donmilne

To be fair, I'm a moderator on another forum (a phpBB one), and users deleting or gutting their own posts is an occasional problem there. User comes along, posts a question, gets a reply, and then they delete their Q post as if it was not community property, leaving just the orphaned replies. Very annoying! However, the normal way to handle this would be to enable edits and deletes only after the user has established a reputation.

Was anyone else finding this happening again yesterday evening? Hopefully UM now pays their bills, so maybe the provider needs a slap upside the head?

Tension needs to be high enough so that the knurled wheel bites into the plastic, which should leave nice precise series of toothmarks. The plastic should not be squeezed so hard that it deforms to an ellipse shape, as the feeder will then be losing a lot of torque just getting the filament through the narrow gap in feeder. The whole feeder chain is actually quite a simple mechanism. If you check for binding at every step along the way, e.g. possible binding on the spool, excessive tension in the feeder, excessive friction in the tube (tightly wound filament), dirty nozzle etc, it should be possible to pinpoint where the problems are. Also consider a temperature test and that the filament is good quality of the correct diameter.

I fail to see the point in putting it at the rear, making the ptfe tube very long. The shorter the distance the less prone to buckling and friction. And by reducing the length there will be less total elongation of the filament and maybe a more immediate response to retraction and hence less grinding. PLA is quite stiff, even brittle. Take 1m of PLA - it is quite easy to bend this into a circle. I.e. you can guide the filament tip anywhere you want it to go. Now try doing that with a 100mm length. I'm not saying you're wrong, I'm saying that my intuition doesn't match yours, and also that the current way lets the filament be tucked neatly behind the printer. But if you think this can be improved then have at it! It would certainly be an interesting project for you to try.

ISTM it's just the pigment that has been bleached out or oxidised. You could probably wash most of that off. The last set of pics is looking more like what I got a year ago... I described this bleaching earlier in the thread. I have to admit I'm hard pressed to see any improvement in "quality" in these latest pictures. The surface roughness has not really changed IMHO, e.g. the layer lines seem just as prominent. What am I supposed to be seeing?

I refuse to buy filament advertised as being 3mm. I will not accept verbal assurances. My rationale is that if the order form says 3mm and receive 3mm then I have no grounds to complain. But, if I order 2.85mm and receive 3.00mm then I do.

That's puzzling. You seemed to be saying above that the filament wa quite hard to pull out when you were cleaning the nozzle - presumably with the bowden tube removed. With the tube removed there's essentially nothing between you and the nozzle except the PTFE spacer, so it should feel about the same whether inside or outside the printer. Is there deformation of the mating face of the spacer? If there was a gap then melted plastic could get into that gap and make the filament hard to withdraw. That wouldn't be obvious with the spacer held in your hand.

Have you actually checked the firmware version, or at least made sure it's up to date?

I'm not sure I remember any discussion where the age of the PLA was a factor. There has been discussion of the effects of the tighter radius as you near the end of a roll, but raising the temperature will not help that. The only suggestions I can recall that might help is (a) use Robert's feeder to give yourself better tension control, (b ) use mineral oil to lube the tube, and (c ) put the filament on a larger diameter roll, and put somewhere hot (e.g. on radiator) to make it "relax".

To retain the tube you have to pull up the white collet, and then slip the bowden clip under the edge to hold it up. Without the clip it will not grip. Look at the hotend end for how the collet and clip should look. If you've mislaid your clip then there's a discussion in the link below about printing a replacement. A paperclip can also serve as a temp fix while you print this. http://umforum.ultimaker.com/index.php?/topic/7338-ultimaker-2-collet-locks

Hi Trevor. Thanks for your library and welcome to the UM forums! I hope you stick around.

Just a note that your Thingiverse link is broken, it looks like you included some text inside the URL.

Ok, I've given the new thread library a try, and I must say that the threads now look very nice. Perfect in fact. The only remaining concern I have is that when I render this in OpenSCAD the threads seem to peek above the cyclindrical shaft I put on the bolt, even if the cylinder is slightly large, e.g. 6.01. At 6.1 the threads no longer show, but of course that means this M6 bolt will not fit in a 6mm hole! I'm not sure where the problem lies - and I don't really have time to check the code myself, so for now I'll just alert you. As far as I can tell from a quick Google search, the peaks of an M6 thread should be exactly 6mm dia. [Edit] Never mind. The issue of the threads peeking through the cylinder was simply caused by the $fn=x number for the cylinder being different from the one the thread uses. Make them the same and the problem disappears.

Your latest results are looking great. I will try your new lib later today. Your timings are incredibly fast compared to mine. You're taking seconds and I'm taking minutes. You're doing a full "Compile and Render (CGAL)" right? Not just a compile? I.e. you're doing the step required to export to STL? Oh! And thanks for alerting me that there's a new OpenSCAD release out! (and just noticed that the menu wording has changed. It's now just "Render").

The test case in question is the bolt and two nuts script that I sent you, though I have since commented out the "$fs..." line and replaced it with "$fn=20;". This model is manifold (it's OpenSCAD after all), but has three separate parts. The old ISOThread_20120823 library renders this in just short of 7 minutes, using the original "$fs..." line. The new "fast" library takes... I don't know, - I aborted after 20-25 mins because I need my CPU for other things! [Edit] I decided to take a closer look at the timings, using the same "bolt and two nuts" script for each test. The old library takes 16m29s to render this test case. The unmodified new library takes 6m56s, and the modified new library takes 36m7s. Part of this is that the old and new libs default to different render quality. As you've mentioned in an earlier post (and I didn't really register), the new library hard codes $fn=30, the old library used to do a calculation that resulted in $fn=12. If I comment out the hard coded value and use $fn=12, then the modified new library takes 9m33s, so it is faster than the old library.

Hmm. That was disappointing. I was quite excited by the possibility of having high quality metric threads rendered with the speed of the new TrevM library, but what I found instead was OpenSCAD taking forever (I cancelled it after 20 minutes) to compile and render the M10 bolt and two nuts of my test (compile+render being needed for STL export). Perhaps I made a mistake with the patch, or misunderstood the purpose of it? How were you rendering your results?

I would appreciate a readable explanation of the changes, since while I am a coder, I code for Windows and embedded and do not use Linux patch tools. [Edit] Never mind, I worked out the patch language syntax.

0.02? I don't believe I've seen anyone go down that far. Standard layer heights are usually 0.1mm and 0.2mm (on vertically curvy or angular prints this would give lower quality). I think I've seen some people mention 0.06mm. You can see lots of prints in the gallery (see list of forum features to the left of this window).

I selected TrevM's library last year after having several near total failures with every other lib I found. The main problem being that OpenSCAD grinds to a halt when so many thread features are added. I notice that Daid's "camera mount" example only has 4-5 thread turns. It would be interesting to see how it performs for a more realistic case, e.g. the first test in this topic. Of course some metric parameters would have to be defined first.

That's fine. There's nothing proprietary in what I sent you, I just made a few test calls to TrevM's library. If OpenSCAD is displacing the threads outwards by 0.4mm then that would certainly explain why the body of my bolt now has threads protruding through. And if the threads are unsupported, then certainly that could cause blobby prints. Oh, when when you talk about "achieving the same effect" by increasing the body diameter, I assume the effect aimed for was to obscure the threads. So in other words you're saying that this M6 thread actually has a diameter of 6.2mm? Houston, we have a problem! (unless he's trying to compensate for shrinkage?).

I'll be interested to know if you can reproduce this with the new library, since the inherent speed in combo with a lower poly count ought to make it quite sweet to use! I have a feeling this whole problem might actually be due to a weakness in STL, mainly that it gives duplicate definitions of shared vertices, and these duplicates can be slightly different due to rounding errors, especially in ASCII STL (which OpenSCAD uses - inexplicably! All that precision in the modeling, only to throw it away in the render). I know that Cura tries to correct these problems, but perhaps it couldn't in this case - in which case it would see the perimeter of the thread as a series of disjointed segments. Yes, Cura behaviour may have been different in the past, but on the other hand it may have been a pure fluke that I got a fairly easy success last year, without too much digging. Though I note that I also ended up using that ISOThread_20120823 library, perhaps because it was the latest at the time. It's a shame that OpenSCAD doesn't support exporting in OBJ format, which doesn't have duplicated vertices. p.s. Certainly this application doesn't need a high segment count. As soon as you thread the two parts together the plastic will be smoothed out anyway!

Well, they were perfectly functional for the application I had in mind, which was to live outdoors without rusting, but not have to bear much of a load. I'd say that they could compete with brass in strength terms, and outlast zinc plated steel. Plus I can make them any size I like.

Ok, now that I see two sets of pictures together I do see another difference, which is that the new library uses many more polygons than the old one (rounder cylinders). I always had a "high res" selection in OpenSCAD ($fs=0.4; $fa=2;), and it looks like either the new lib honors this, or the new lib still overrides, but to a higher quality setting.

Ok, maybe not. I reran the OpenSCAD build step with the old library, no other changes. The thread height problem corrected itself, but otherwise I don't immediately see a substantial difference in the two sets of images. One very obvious change is that the new library is WAY faster than the old one.

I just did, and the parameters are what you'd expect from the above discussion. The actual print speed seems to have been 50mm/s. I downloaded the new version of trevm's library, and I have to say that the threads look rougher to me. He seems to make the thread out of lots of little prism shapes, and I'm seeing gaps between the separate prisms... which Cura probably won't like at all. In fact, a picture is worth a thousand words, so here's two pictures: the STL, and then a closeup of the threads in Cura. The height of the threads seem to have changed slightly too, i.e. they are now protruding from the plain part of the bolt. I'll redo this with the old library and see if it was like this before.