Taper tolerances

My son just showed me the official engineering symbol for this. Make two large UU connected together. Then put an arrow through it --->. The term is called, "dead nuts", VBG

karl

According to Wes :

Well ... considering how Morse tapers are supposed to work, I would consider them the most critical -- perhaps a half thousandth in the total working length of the taper.

I would consider the R-8 and the 5C to be a lot less critical -- since the taper of the collet itself will change as it closes, and it is held in place by a drawbar. (The same applies to a Morse taper *collet* instead of a solid shank tool with a Morse taper which depends on the grip of the shank in the socket for holding properly.

Enjoy, DoN.

The answer is, tighter than I can measure.

I had one R-8 that tended to stick in the mill. After much head-scratching (it measured the same as the others) and looking for wear spots (I didn't really want to get my mill spindle full of Prussian Blue...), I figured where the problem HAD to be. I chucked the offending R-8 into the lathe, gave it a spin and hit it with some emery cloth for about two seconds. It took off enough so that the collet now fit perfectly. And I still couldn't measure the change.

Jerry

:) I never learned that symbol in colledge

Wes

Duh. College. Sorry to all those English profs turning in their graves.

Wes

"The Kid" had to explain it to me. The UU is your nutsac. the arrow killed it. Hence, "Dead Nuts". He designs all the fixtures for production CNC machining after writing the programs at his company. When he wants the fixture craftsman to pay special attention to this detail, he includes the symbol. Its guaranteed to get a call from the shop and then a laugh. Plus that detail gets made just right.

Karl

Had a similar experience concerning electronics PCB assembly, many years ago - before that went to China. Production kept putting a certain transistor in the board backwards. Inspectors rejected, boards were reworked, & more bad boards kept coming out. Finally, the inspector wrote on the reject slip, "TR44 AAF". Nothing more. No-one in production had ever seen "AAF" before. Not the foreman, not the manager, not the ... So finally, they had to ask the inspector himself (in a different section, naturally). Translation: "AAF" = "A**e About Face". Much hilarity all round, & the point finally sank in.

I'm going through the current topics to hopefully suggest a way to tag valid RCM traffic.

Add RCM: on the beginning of the title line - BEFORE the obligatory OT?

Hang tiugh - keep posting.

Cavelamb

According to cavelamb himself :

*Don't* use a colon. Outlook Express certainly converts every two letter group followed by a ':' at the start of a "Subject: " header to "Re: " (It thinks that it may be an equivalent of "Re: " in some other language.) I don't know for sure what it does with three letter groups, but try something else to make it stand out -- enclosing it in square brackets "[]" is probably a pretty good one -- and do the same with "OT" when you need to add it, so OE won't turn it off for you.

I've set up my killfile (using trn as a newsreader) to reject anything with "sci.crypt" in the headers, since the vast majority of this is an attack on that newsgroup, and every one of these has that newsgroup name in the cross-posting list in the "Newsgroups: " header. It takes a while for the newsreader to process it all, but it does clean things up nicely. It is best to move the search for "sci.crypt" to the beginning of the killfile, so it can clean up the most before your other killfile entries have to wade through it.

Good Luck, DoN.

Ok Don, Copy that about the colon useage in IE. I use netscape, so what do I know...

If [RCM] can work mo betta I'm all for it.

Nice youe reader can clean up YOUR feed, but we need to find something that will work for everybody or you'll ne talking to yourself. :(

[ ... ]

I don't (and can't) use OE, but I've seen the effect where someone started a thread marked as "OT:", and I don't see any of it until I hit the first followup by an OE user, whereupon the thread map shows a bunch of "already read" articles preceding the one which I saw.

It is more likely to keep going once you start it, at least.

The real trick is how many people's newsreaders have killfiles which can look at the headers -- and in particular at the "Newsgroups: " headers. For everyone who can (and who learns to do it), the junk simply goes away -- as I don't see any *valid* cross-posting between sci.crypt and rec.crafts.metalworking, so everything which gets killed is good riddance.

I know that the killfile in some of the newsreaders is quite good, while others are pretty useless.

FWIW, I timed the killfile this evening. 8 minutes and 51 seconds to clean up rec.crafts.metalworking from the cross-posted garbage. The people in sci.crypt have a lot more problems, because they are getting cross-posted garbage from a lot of different newsgroups, so they could start out by killfiling anything from rec.crafts.metalworking, then soc.religion.quaker (or whatever the correct name is), then others as they identify them.

Of course, newsguy seems to be doing a good job of killing most of the garbage. I was told that rec.crafts.metalworking had 25?? articles in it, but the killfile only had to deal with about six hundred. I don't know whether that is newsguy's work or whether there is a good cancelbot working to help clean it up. Of course, that cancelbot does no good for any news server which ignores cancels (as many do, thanks to the abuse of them which has happened over time).

Good Luck, DoN.

I don't even notice the time slrn takes. Maybe 1/2 second. This on a 1.5Ghz machine, so certainly no speed demon... that's on ~42,000 articles.

I wondered whether they were being killed at the server since I have it set to filter anything posted to 5 or more groups. Checked the news log though...

$ bzcat news*bz2 | grep metalworking | grep "too many groups" | wc -l 20

Nothing significant there.

This is what a slrn filter looks like... matter of fact, it's the exact format and location as a Pan filter. Who knows. Maybe other readers also use this format at ~/News/Score

%BOS [rec.crafts.metalworking] Score: =-9999 Newsgroup:.*sci\.crypt %EOS

According to Steve Ackman :

Hmm ... this machine is a dual 450 MHZ UltraSPARC, but the limiting factor is how long it takes to get all the headers downloaded multiple times -- plus something like perhaps twenty more times to scan the entire body for certain things. I avoid doing the full scanning as much as possible. But I do have 427 total lines in the killfile, and it is a separate pass for each of them.

These things went a *lot* faster when I was running my own local news server. :-)

Does your system download and cache all of the headers prior to running the killfile?

Hmm ... I was using the scoring back when I was using strn, but it was even slower than the killfile.

Perhaps I should look into slrn.

Enjoy, DoN.

That certainly sounds like an expensive filtering method.

I've been using leafnode since... I don't know when. I wouldn't do it any other way.

Hmm... I'm not even sure. I just keep slrn up in an xterm all the time. When I hit "g" the new articles show up. I don't know the specifics of the process.

After I hit K and create a new slrn filter, it asks, "Apply scorefile now?" and of course I hit "y" and that's when it took like 1/2 second. 100 or so article entries gone.

Oops! That filter worked on the ones (not really many in the scheme of things) I saw yesterday, but when more showed up today around that filter, I decided to do it at the server. Applyfilter is part of the leafnode package.

$ echo "^Newsgroups:.*sci.crypt" >> /usr/local/etc/leafnode/filters $ sudo applyfilter rec.crafts.metalworking

Now THAT took 9 minutes... but the server is only on a 750Mhz CryixIII so half the clock of the machine slrn runs on, and much less L1/L2 than the AMD has.

Obviously. It's the best newsreader on the planet. ;-)