Program to Calculate all Possible Lathe Thread Pitches

Some while ago I became suspicious of one of the thread pitches quoted in my Warco WMT300 handbook, the 3mm pitch thread was wrong by close on to 15%, and (embarrassingly) I discovered that 10 years after getting the lathe, it hadn't been delivered with all the wheels it should have been - I didn't check when I got the lathe, just counted the wheels without opening the wrapping plastic - and it did have unexpected duplicates. This meant that I couldn't cut half the metric threads in the lathe manual. After enquiring as to the price of the wheels I needed (after 10 years I couldn't reasonably ask for them to be supplied FOC), and gulping loudly, I decided to write a spreadsheet to check the accuracy of the pitches in the manual and try to work out wheel combinations to make up some of the other threads for nothing instead. The manual threads were fairly consistent in being 1.59% in error, except the 3mm pitch which had a 70 tooth wheel instead of 63, which was the cause of the pitch error. After a good deal of trial and error I found alternatives for most of the metric threads I wanted, but it stuck me that it was more error than success & there must be a better way of doing things.

You may be aware that every screw cutting lathe can actually cut a lot more threads than the manufacturer usually specifies in the handbook, and with pen making I wanted quite a number of non-standard threads. After the hours trying, I had proved trial & error was not a viable method, as it took too long to find the pitch I wanted, so what I really wanted was a method of quickly calculating every possible pitch, searching through the list and selecting the ones I want. So.. how to do it?

Well, I wrote a program that used the brute ignorance & force method to try every possible combination of wheel in the lathe and calculate the pitch for it. The program is pretty simple and does not check if the wheels will actually fit in the available space (it would require too much detail about gear module, distance between shafts etc to be entered, to be worth programming for a program that really only runs once per lathe), but it does check every theoretical combination and allow the user to try them out quickly & easily. There are usually many alternatives giving the same pitch, so if one combination won't fit, another probably will.

It turned out there were quite a few combinations for my lathe - the 755,160 possible combinations led, due to duplication of wheels, to about 230,000 distinct different combinations producing around 30,000 different pitches (I'm guessing, I haven't counted), and I found I was able to get thread pitches from 0.0708 mm to 5.185mm (358 to 4.898tpi). At the 1.5mm pitch range I particularly wanted, there are 356 different combinations to try that all produce exactly 1.5mm pitch to 14 decimal places, and then a further thousand or so giving a perfectly viable error of less than 1%.

So, what has this to do with the ME forum?

Well, I thought other people may be able to use the program. It is certainly applicable to the Warco WMT300/1 & WMT300/2 Combi's and all other badged alternatives of the lathe (Clarke CL430/500M, Chester Model B, Sealey SM27). It is also applicable to every single lathe that uses 4 gear wheels with a drive train similar to that shown schematically in the diagram below:

The program directly applies to the Seig SC2, SC3 and SC4. With a bit of thought it could probably be applied to the SC6. It also applies to the Warco Super Mini, WMT500 Combi and WM150. It may apply to the WM180 with thought.The program does apply directly to the Chester Centurion 3 in 1 & long bed Centurion, Conquest Lathe Super & Superior, DB7, DB8 and DB11. It applies equally to many Grizzly & US badged lathes with the same drive train layout.

The program window looks as below (with all the data for my Warco filled in):

I have added a 2 page help file accessed through the 'Schematic and Help' button, made the data entry a bit easier than when I initially wrote the program, and programmed in two different output formats for the available thread pitches. The program can output to a PDF or CSV file for further manipulation in a spreadsheet. The PDF file can be quite big, so do not be surprised if there are 1000 pages in it, for my lathe and rather odd wheel combinations, I get 2991 A4 pages at 76 combinations per page, and a file size of 125Mb. On opening the pdf file, Adobe Acrobat Reader states that there is an error in the pdf file and 'repairs' the file. It speaks with forked tongue - it doesn't; it just wants to convert it from the uncompressed version 1.3 file format to a more recent and verbose compressed format and thereby slow the opening and responsiveness of the file (I had to know the v1.3 pdf format inside out before I could programme the unit to create a pdf file, and I know it's right - no other PDF reader objects to the files created by the pdf code I wrote).

You can download a zip file of the program here:

http://www.chestnutpens.co.uk/downloads/ThreadPitchProgram.zip

[continues]　

The program is a self contained 32 bit Windows program that should run on any version of Windows from Win95 onwards and should also run under WINE on Linux. I have tried the program on Win7 (64bit) and WinXP (32 bit), and it definitely works on both operating systems. The zip file includes a readme file, the help file, executable file, and calculation unit source code (so you can check that the code does nothing nasty to your machine if you want to). The program creates a file in its own directory called 'data.ini' to keep the gear wheel sizes and pdf file preferences for next use. If you have any of my CNC programs and put the program in the same directory, they will all share the same 'data.ini' file, keeping the clutter down.

Instructions for how to use the program are given on page 2 of the help file. Please note that the program can take a while to run, and Windows occasionally gets bored, looses focus and the program does not update the progress indicators. Just leave it to run, if there is a problem it will exit cleanly and tell you what happened in the box at the bottom, but if it seems frozen, that's simply a symptom of Windows not knowing how to cope with a calculation intensive task and it behaving like it has the attention span of a goldfish.

I hope you find it useful when you need an odd thread pitch, loose a wheel or simply want to play.

Regards,

Richard.

Hi Richard,

I downloaded and tried your program, for some reason it outputs zero (0) pages in the PDF file?

Thor

If you go to this page of the "Lathes.co" website you can download a program called NthreadsP.exe that should do what you want. I use it with my Chester DB-10G lathe and it normally finds a combination that will produce the thread I want.

Les.

Edited By Les Jones 1 on 14/09/2017 18:06:27

Hi Richard.

After a brief tussle I have it working with wine. Initially same problem as Thor, but on the second attempt it fired up OK. Something to do with populating data.ini on first use?

Dave

Dave, same experience as you, except with data.ini populated I get lots of PDF pages, but all are empty.

Thor

Edited By Thor on 14/09/2017 18:27:53

That is one problem I have never had. It's amazing how people come across problems that seem baffling and shouldn't happen.

Could you try with outputting to a .CSV file?

The other option I can think of is, have you put in a 'final ratio'? Needs to be 1 if no other value is put in. A final possibility is is a font selected from the three options. It should default to 'Helvetica' but may not.

If that doesn't work, could you post the contents of data.INI, so I can try it myself?

Regards

Richard.

Edited By richardandtracy on 14/09/2017 19:49:19

Hi Richard,

I have sent you a PM with the .INI file. I have also tried your program on a computer running Windows 10, the result won't display in Edge (just get an error message), but I can view the result in FireFox?

Thor

After a brief tussle I have it working with wine.

Dave,

Was that red or white? Or maybe the wine caused the typo?

As a result of Thor's .ini file I discovered that it did not respond well to decimal commas being used in the input. I have changed the program to include a text parse to convert any inputted commas into decimal points.

While looking for the source of Thor's problem, I did notice a silly bug in the pdf output if no initial gearbox was specified where I had misplaced a closing brace so it didn't include a statement it should have done. I have corrected that.

To prevent the apparent problems of data.ini not being present, I've included a really basic one that works in the zip file with 5 tooth numbers in it. If the teeth are not in your list, delete them and add the ones you want.

I will try to get the modified file uploaded this evening.

Regards,

Richard.

Thor,

I don't know why the PDF file won't work on 'edge' - though it's one I've not heard of.

Possibly the file format is too old.

I deliberately went to a pdf format as early as possible for several reasons. I hoped for maximum compatibility (therefore early format) and my mind goes completely to mush when I try to understand how run-length, variable byte length zip compression works in a file. Apparently the byte length supported by the pdf zip compression can be between 9 and 12 bits, and varies as the stream progresses before re-setting to 9 bits when the 12 bit bytes cannot contain the encoded data. Unfortunately the pdf spec I read had been written by someone who didn't seem to understand it well (or understood it too well) and I couldn't get head nor tail of the explanation. All pdf formats after v1.3 use compression in the object data streams, but it's optional in the 1.3 format. Because I don't understand it, I opt out.

Regards,

Richard.

Edited By richardandtracy on 15/09/2017 10:07:18

Something to do with the way our minds work when we write. I always check my forum posts before hitting the send button. Despite checking beforehand, reading my own post after it's gone public often reveals obvious errors. What the Flip is going on? I have the same problem with proof reading and even more so with software. I seem to read what I think I said rather than what's actually there, my mind automatically correcting the mistakes so I don't see them.

It's quite interesting to experiment with deliberately mangled text. Ti semes msot poeple acn reda wrdos prvoided thye hvae teh rihgt lettres. Humans are good at pattern recognition, but it seems to create serious blindspots. I think the problem is most severe with software because it contains loops, conditions, sequences, interfaces, coupling and structure as well as spelling. Even worse, most programmers have to test their own work, so the testing may also be unconciously biased to skip conditions that would flush out the bug.

The most amazing thing to me about software is that it works at all!

Dave

PS. A thought about the 'Windows Hanging, be patient' issue. It's because the operating system expects GUI programs to be interactive and thinks they've crashed if they spend too much CPU time in background . I'm not familiar with VCL but I expect it has a function that allows code to check the event queue. If you call that function periodically during a long calculation, Windows (and Linux) will know that the GUI hasn't crashed, thus avoiding the 'Not Responding' warning. You don't have to handle the events.

Thanks Richard,

I will try your new version of the program.

Thor

Dave,

There is a function applied to each form (read 'Window' )    in the VCL library, and it's the 'Refresh()' method built into the TForm object, which I call up every 10 pdf pages or so. Amongst other things it sends Windows a WM_PAINT message to trigger a redraw and halts the process to flush the message buffer. But somehow Windows forgets this.

I will admit that I am a 'hobby' programmer, and it has taken me a good few years to get to the limited programming capability I have. Due to the lack of programming finesse I have, I tend to err of the side of brute ignorance & force to get things done. (The programming equivalent of using a sledgehammer for all jobs requiring a hammer.)

Regards,

Richard.

Edited to kill a rogue emoticon

Edited By richardandtracy on 15/09/2017 11:00:27

You are too modest Richard!

I've not done much GUI programming and most of it was simple. Although I've delved into GDI, OWL, Qt and others my training was in X-Windows. I know what I know is superficial.

Anyway, there's a real problem with using any of the Frameworks, which is seeing the wood for the trees. Deciding what to use may not be at all obvious until you're thoroughly familiar with it and that's hard work cubed. Reasonable to expect that refresh() and WM_PAINT would do the job; I guess they don't because they're output activities whilst Windows still 'knows' that input events are being ignored.

Dave

New version can now be downloaded via the same link.

Regards

Richard

Thanks Richard, I have downloaded the new version and will test it.

Thor

Hi Richard,

Thanks for posting a new version. I have done a bit more testing, and still get trouble when using PDF output, the CSV format seems to work Ok.

Thor

For some reason I can't yet identify, the pdf output does not always work. I shall work on it, but as I have no idea of what the cause may be, the solution may be difficult to come by. So, in the mean time, can I suggest that you try the pdf output and if it doesn't work, resort to the csv output.

Regards,

Richard.

May help?

Sometimes PDF is configured to open automatically in HTML. Sometimes it is blocked completely and needs a manual over ride from the computer user to create/open PDF in a non html environment