Change Wheel Programme from MEW

Here is a very simple Change Wheel programme by Mike Aireton (originally published in MEW 277) that runs on my PC using Micromite Basic for DOS.

You can download MMB for DOS for free and it runs very well on my Win 10 laptop. It's a standalone .exe file so just fires up as required from a desktop icon and it's a very convenient, easy to programme resource to have available for a dummy like myself.

I generally use Notepad++ to edit small programmes. Just copy the text below into Notepad and save it as ' MEW277.BAS ' - then you can load the programme by typing LOAD "MEW277.BAS" in MMB.

You'll find the download at the bottom of this page

Micromite Basic (DOS)

Try it, you may find it useful.

Regards,

IanT

'
' Change Wheel Calculation
' by Mike Aireton - from MEW 277 Feb 2019
'
Cls
Input "Input required TPI ", W
Input "Input deviation ", Z
'
X = W + Z
Y = W - Z
'
For A = 20 To 75 Step 5
For B = 20 To 75 Step 5
For C = 20 To 75 Step 5
For D = 20 To 75 Step 5
'
If A = B Then GoTo SKIP
If A = C Then GoTo SKIP
If A = D Then GoTo SKIP
If B = C Then GoTo SKIP
If B = D Then GoTo SKIP
If C = D Then GoTo SKIP
'
' Assumes 8 TPI Leadscrew
'
If A*B*8/C/D < X And A*B*8/C/D > Y Then Print C;" "; D; " "; B;" ";A*B*8/C/D
'
SKIP:
Next D
Next C
Next B
Next A
'
Print "DONE!"
End

Edited By IanT on 02/07/2021 09:59:14

For historical reasons, BASIC isn't my favourite language, though it should appeal strongly to anyone brought up on ZX-Spectrum, BBC or any other Home Computer from the heyday of 8-bit computing. BASIC isn't a good choice as a beginner language today, and - of the alternatives - I recommend Python.

In his other post Ian announces Micromite BASIC is available for the Raspberry Pico, undoubtedly good news for BASIC writers who want to develop on a microcontroller. However, as the Raspberry Pico arrives off the shelf with Python, it's worth showing what Ian's program looks like in Python, especially as it provides a simple demonstration of a Python feature BASIC struggles to emulate.

First, this is Ian's program in Python. (Any mistakes are mine!)

Very similar to BASIC, but note the syntax is cleaner. There's no need for the STEP label, or the list of NEXTs at the end. The print statement shows off a format string: value is output to 3 places of decimals.

One improvement to the Python version by making it more general is using the range() statement to generate a list of availableGears, which all the for loops share. Reads a shade better I think.

That's not the best bit. BASIC for loops are limited to numbers, whereas Python's for can iterate several different objects, such as lists, sets, ranges, dictionaries and other containers. Helps solve a real-world problem: the gear-set my lathe has doesn't match the simple number sequences generated by BASIC's for statement. No problem in Python because I can list them:

availableGears = ( 20, 30, 45, 50, 60, 70, 75, 80, 85 )

And it would be easy to add 63 or 127 or any other gears wanted.

Although it's not difficult to code for odd sets of gears in BASIC by indexing them from an array, it's more work and opportunity for mistakes. Python makes working with lists as easy as working with ranges. Substituting a list for a range is a simple example, but Python's ability to apply the same pattern to nested containers of different types is very powerful.

What's wonderful is anyone who fancies a go can try both to find what suits them best.

Dave

Well Dave, when I first learned Basic some 40 years ago, I guess it was a beginners language for me.

If I was some 40 years younger and wanted to learn a programming language, then I'm sure Python would be an excellent choice. But I don't need to learn anything new, as I'm quite happy with MMB because it does everything that I need within a very convenient/affordable embedded package (e.g. MMB + PIC32 = Micromite).

I'm sure that Python is superior in many respects but (from my point of view) it lacks one essential feature - I've never learned it. Why do I need to learn another programming language, when I already have one that works just fine for my needs.

I'm also sure that most Pico owners will use the supplied s/w tools to programme it but if I ever need to upgrade from the PIC32170 chip, I now have an affordable migration path. I'm not really concerned what others will do with the Pico - just that I can now use it without any further major investment in my time.

With respect to the MEW gear-change programme, Mike Aireton chose to write it in Basic and I don't think I had to do very much (if anything) to get it to run on my PC using MMB. I used the programme recently to quickly remind myself about a gear combination I needed for my EW and I thought others might find it useful too. No algorithms required, no advanced computer theory - I just typed it in and it worked. Simple

Regards,

IanT

Dave, before you write off MMBASIC as a poor choice for beginners - or anyone else - have a look at the language, especially its built-in maths functions. It's not BASIC as you knew it...

Also, the eminently affordable (cheap!) Micromite/Maximite range of hardware, for which MMBASIC was developed, makes practical computing and interfacing to the outside world (eg process control) possibly more practicable and easier to learn than (most?) other systems.

Intriguing! I didn't know BASIC, in one form or another, is still used.

My initiation to "confusers" was in a scientific establishment that used locally-written BASIC programmes to run electronic test-equipment. Many of the instruments were made by Hewlett-Packard, which published its own version of the language allowing expressing the operation settings as simple character strings.

In later years the scientists for whom I worked, started using LabView instead for that purpose.

However my work had taught me MS 'Excel' to a moderate level, hence I produced charts for various threads on machines like my EW 2.5" lathe with its 8TPI lead-screw and change-wheels from 25 to 65 (I think) X 5.

It was thus easy though a bit laborious to juggle the wheels in the table to obtain least errors for odd-number inch, BA and metric pitches, with the error calculated and displayed for 1 turn and 10 turns. This is for cutting short threads - studs, piston-rod ends, steam-fittings and the like - not long control screws.

Probably, someone with advanced speadsheet skills could make it do the juggling automatically. Nevertheless I have the tables, allowing prints for laminating so I don't have to run the computer every time.

The main points are:

1. Determining and closing the accuracy limit by number of turns. It is surprising how close I could calculate many standard but non-octal threads with the limited wheel range; within fair tolerance. I accept finish-profiling by die a slighly shallow-cut thread anyway, though for these threads the modest pitch correction brings slight thread-thinning with accumulating error. Hence 10 turns as the likely practical maximum, enough anyway for most applications.

2. Producing a printed table of pitch / tpi, wheels and error; for laminating for ready reference.

'

I used a similar approach to create a feed-length table for the Denbigh H4 horizontal mill I am in the throes of putting back into use. This has a 6 tpi longitudinal screw (0.167" pitch), of all strange things, and it's anyone's guess what the dial markings mean! I suppose most horizontal milling is through-cutting, or to lengths that are not very critical.

I had already used the EW lathe to cut a metric, non-standard thread listed in none of the reference-books, with no die available, to fit a keg CO2 cartridge for a special purpose, so knew the possibilities. The thread was probably designed for commercial exclusivity; but might now be in one of the ISO-M Fine ranges.

I remember my first changewheel program on the BBC computer running at 2MHz finished at 3am.
Although the originator won't admit it Python is a kludge between Basic and Perl hence the similarity in the program and difference from eg C which was popular with professional programmers at the time. Unfortunately not carrying in the simplicity of syntax of Basic and handling of multidimensional arrays
The reason Basic then Python is popular for beginners and amateurs is entirely because it is interpreted and instantly available which is what we mostly need. Basic used to be bundled with Windows until it was incorporated into Excel where it is now used universally without people realising its origins.

Well, as you well know Baz, things have changed at bit since the BBC Computer was around! 

I run MMB (DOS) on a five year-old Intel i5 laptop and this little MEW programme will typically list out all the potential gear combinations in under 30 seconds.

So to my mind, the old arguments about interpreter vs compiler performance don't really make that much practical difference these days - given the huge processor power available for very little money.

For example - my little ( £3.50! ) 'Mites' run an order of magnitude faster than a typical 1980's 8-bit computer. They require only a single external capacitor to build a complete running 'system' and have much more I/O and memory available onboard than any 8-bit user could have dreamed of back then. As Kiwi Bloke has already said, MMB also makes interfacing to the real world very simple, not least because MMB makes 'debugging' so much easier.

MMB fully supports common protocols such as I²C, asynchronous serial, RS232, IEEE 485, SPI and 1-Wire. These are not someelse's 'Libraries' (to be tacked-on or included) - they are simply part of the language.

So whilst I appreciate that others have very different expectations, skills and views to mine, I have a good solution for my 'compute' problems that works well and is affordable! So whether Python is a 'kludge' (or not) doesn't really matter in reality. You can argue the finer points of that with Dave)   

Regards,

IanT

Edited By IanT on 03/07/2021 12:05:21

Edited By IanT on 03/07/2021 12:06:42

I'm not going to get involved in the 'which language is better' issue, but both the original Basic and SOD's python omit to print out the value for the first gear in the train, 'a'

I think the Basic should read:

If A*B*8/C/D < X And A*B*8/C/D > Y Then Print A," ", C;" "; D; " "; B;" ";A*B*8/C/D

and the last line of the Python should be

print(a,c,d,b, F'{value:.3f}'

or even better print("a = ", a, "c = ", c, £d = ", d, "b = ", b, "tpi = ", F'{value:.3f}'

The reason the originator wouldn't admit Python is a kludge between Basic and Perl is because it's not true! Rather, Python is well-designed and has benefited by correcting the poor features of early languages. Although the design is based on computer science, it's emphatically a practical language avoiding the pitfalls of pure teaching languages like Pascal.

I've written code professionally in assembler, various BASICs, C, C++, COBOL, FORTRAN, and a good few others, including 4GLs. In an R&D job I selected languages to suit various different projects. Although I've not written Pascal or Ada, I've studied both, plus Smalltalk, and several 4GLs.

I see computer languages as tools, not favourites. Like tools, computer languages have advantages and disadvantages. If this was 1980, and I was asked to recommend a beginner language, I'd certainly mention BASIC because - at the time - it was widely available in a shower of different dialects, and it was well supported by the media. A few exceptions back then: if the beginner was going to study computing at university, academia disliked having to un-teach BASIC bad-habits; likewise many employers didn't want BASIC programmers. Singleton programming at home on a one-user 8 bit microcomputer didn't match well with the grown-up requirement for developer teams sharing much more powerful multi-user mainframes and mini-computers.

There are many theoretical and practical reasons why BASIC didn't make the grade, as can be found by researching the subject. In practice, BASIC has fallen away. Like COBOL, it's become a niche language, no longer mainstream. It isn't 1980, it's 2021 and times have changed. This US list of 2021's top 10 languages is typical;

1. Python
2. Javascript
3. Java
4. C#
5. C
6. C++
7. Go
8. R
9. Swift
10. PHP

Coming up behind: DART, Kotlin, MATLAN, perl, Ruby, Rust and Scala.

No BASIC of any sort should be recommended to a beginner today. Visual BASIC is the top ranking BASIC still popular, it's 66th. Not much future or value in it.

BASIC is fine for hobby purposes if you already happen to know it. Not because it's a 'good' language, but only because it eliminates your personal learning curve. I agree that's a good reason, but strongly suggest being historically familiar with an obsolete computer language is a poor reason to recommend it to anyone else! Newcomers should think about what the language is for and look at the alternatives before making a decision.

Dave

C and C++ are both good for high performance low-level code - operating systems, spreadsheets, database engines, web servers, compilers and such, but complicated for beginners. This is partly because the language is designed to support massive programs developed by a large team, a feature that many BASICs don't do at all!

C certainly supports multi-dimensional arrays. Core Python doesn't have arrays at all, it comes with a clutch of more general data structures. Lists behave like arrays, and a list of lists is 2d, while a list of lists of lists is 3D etc. However, as lists are slower than arrays, Python supports true arrays via a plug-in module. numpy's mathematical features are far more extensive than any BASIC, and it's not the only module available.

I was fond of perl for a long time until Python overtook it, first with cleaner syntax, and then with

Edited By SillyOldDuffer on 03/07/2021 13:09:52

I do recommend BASIC for beginners, but only in a special set of circumstances. Until I retire later on this year I teach blind and visually impaired students and the ability of the code to be read by a screen reader is important.

Leading whitespace is ignored by screen readers so its use to block sections of code, as in python is difficult.

Improper punctuation such as full stops in the middle of statements or function names are also ignored.

As a result while those with a flair for programming can pick up the need for things that are not spoken to them, and many successful programmers are blind - using any or all of those languages Dave has mentioned, those just dipping their toes in for the first time find a traditional BASIC far easier to succeed in, in the first instance.

As a sometime C programmer IMHO it is obviously the best one to use - but after writing out the changewheel program in C I could not understand my own syntax

The best quote I ever read about the history of computing languages:

"Djikstra was a snob"

Neil

And the only computer language that irreparably damages the user's brain is F0RTAN 66.

What, my hero Edsger? Never! Neil is probably thinking of Count Sigismud Dijkstra, spymaster of the Kingdom of Redania, and later its regent after the death of the king.

Snob or not, Dijkstra influenced me:

'One must consider one's own past, the experiences collected, and the habits formed in it as an unfortunate accident of history, and one has to approach the radical novelty with a blank mind, consciously refusing to try to link it to what is already familiar, because the familiar is hopelessly inadequate. ... Needless to say, adjusting to radical novelties is not a very popular activity, for it requires hard work.' (From On the Cruelty of really teaching computing science  '

Dave

Edit: pesky smilies.

Edited By SillyOldDuffer on 06/07/2021 13:23:01

One of the worst Cobol programs I had the misfortune to try to debug had been written by somebody who thought he understood structured programming and contained several pages of nested IF... ELSE... statements making it almost impossible to debug.

One useful feature that is not used now is Decision Tables which make the logic of a problem clearer. In the early 1970s we used them in a system that enabled a list of equipment for a new coalface to be produced from a simple list of parameters such as length of face, type of supports etc. The logic was in the form of decision tables embedded in the Cobol source which was then put through a pre-processor to create source code. The decision tables were created by the user engineering department so they had control over them. Initially we used an ICL Cobol pre-processor but I converted them to IBM using a pre-processor obtained from the States and written by Grace Hopper! I also split the original large program (2 boxes of cards) into sections which could be compiled separately and then dynamically linked at run-time so making amendments easier.

Richard

Sorry I'm a bit late posting to this thread, but have only just signed up today.

Like IanT I learned Basic many decades ago (in my case 1982 I think) after purchasing a BBC B costing an unbelievable £399 at the time... So I am a bit rusty wrt programming and come to that a bit rusty concerning selection of change wheels too...

I currently have an old Windows XP desktop collecting dust & which is kept purely for the old version of TurboCAD I installed years ago. It also has MS QBasic loaded which has enabled me to run this MEW program successfully.

My query concerns the PRINT statement and the order in which the wheels are listed (including the missing A as noted by Duncan Webster):

If I recall correctly, when checking a proposed combination of wheels for an 8tpi leadscrew
tpi = 8 * Driven / Drivers

This would imply A & B are Driven wheels and C & D are Driver wheels.
If this is the case would it not be more logical to arrange the columns in the order A C B D followed by the check calculation?

Guidance on this would be much appreciated. Thanks.

Apologies for an error in the closing paragraphs of my last post:

.....If this is the case would it not be more logical to arrange the columns in the order A C B D followed by the check calculation?

Should have read ....in the order C A D B followed by the check calculation?

My request for guidance on this subject was a bit vague, and refers to the practical use of the program; in particular the input values of deviation to be used for typical small components produced on a 3 1/2" lathe.

Presumably manufacturing tolerances used in the various thread standards could be used, but are there any other reference materials which could be helpful?

Thanks

BB12 it depends on the use. So if you are making a bolt for fixing something using say a thin nut that will only engage 3 threads then a 1% error would mean the last thread of the nut is 3% out. If a fight fit it might jam, but if a loose fit only one turn of the thread is going to be in contact until the thread deforms for the other turns to make contact. It will fit but may not be as strong as you expected.
If the nut is a deep tapped hole with 10 turns in 'contact' then the end one is 10% out and jamming is more likely with a tight fit but with a loose fit it might still be strong enough for your purpose.

Chances are that unless particular about angle and tool thread form (inserts anybody?) the pitch is only part of the problems overall.

If you just want a program to use rather than worrying about BASIC etc;, look for NthreadP on Lathes.co.uk:

**LINK**

It works straight off on Windows machines and under Wine on Linux. There is another version for lathes with a screw cutting gearbox.

Russell

Thanks for your reply, makes sense to view each job in this way. I realise now that Nigel Graham's post was also indicating a similar approach; guess I was suffering with information overload at first pass through all the original postings!...

Re. the Tool/Thread form:
I was fortunate to attend a school where crafts were actively encouraged (we actually had a well equipped metalwork shop; those were the good old days!). Our metalwork teacher was pedantic about use of hand tools and tool grinding techniques. we had access to a shadow graph with templates etc. and those pupils showing sufficient skills were allowed to use the lathe etc.