From Chris Bourne:
There are Meccanomen who have designed excellent interfaces for their own
models. Maybe one of them can take it a step further and make their interface
user-friendly for all of us, and put together a package which MW
could supply.
Nigel Haslock
There are two distinct issues here. The first is the simple controls, i.e. switches and motor controls. The second is the programming of sequences of actions and the respones to sensor states. For the first issue, check out the prices of radio control equipment, particularly servos. Then contemplate how many servos you would need for your favorite model. Add in the consideration of the size of the model needed to house the equipment. It seems to me that you are looking at a 6 set or larger to build a model big enough to control and then needing to spend as much again to get the control gear.
I have been pondering the creation of a control language. The ideal would display a 3D model of the model which would go through the motions as you stored the commands. Even so, there remains the mechanics of controlling the servos and reading the sensors. You could go for an on-board computer that you downloaded the program to, or you could go for a direct control from your PC. Either way you need a block of custom electronics to convert computer signals to servo controls. No doubt this has been done before but how much will it cost. My conclusion is that such a system will be too expensive for the mass market. I'd like to be convinced otherwise though.
Frank Haymes
I think that we need to define what we need from an interface and the software to run it. We need to specify the number and type of outputs(i.e. motors, electromagnets, lamps, etc.) and the number and the type of input(i.e pots, light sensors, tempsensors, switches, etc.). Next we need to specify the type of interface. I think that a standard Comm port(RS 232 serial) is the best. Then we need to decide what the software will do. We would need both a "can" program to run the interface and the software drivers for those who want to write their own software. I am thinking about building an interface that would control 2 motors, have 4 digital output, 4 digital input, and 4 analog inputs. This would connect to my computer by the Comm port. I would then write the drivers for both DOS and Windows. I would like to have a target price of 100USD.
From Colin Hinz
If you intend the "box" to be merely an electrical translator (RS-232 logic signals into motor signals, sensors converted to RS-232) then I'd hazard that this isn't really enough. I'd advocate stand alone operation, with the computer hook-up only for configuration. Otherwise you make it essentially impossible to use on mobile models. Also, control at least 4 motors...many devices have more than 2.
From Chris Bourne
Spanners, there is no mass market. There is us. We are the market. If we try to focus on selling to a mass market, it won't happen. If we focus on providing ourselves with a package at cost (or cost + MW's margin if Geoff wanted to distribute) then it might happen - and indeed we might find, having done it, that Meccano takes an interest and takes it on board. Pigs certainly won't fly if you don't give them wings. RS 232 is fine. It would be nice if the system ported easily to a Mac as well :) I think that many of us don't much want to cart the computer system off to a meet as well as the model, but others would not mind.
So a system that can do both would be great - that is, a basic system which controls through the port, but which can expand to include storing those commands on a small card which is part of the model. Is it possible to do both with the one system?
What would your outputs and inputs enable you to do? It sounds like two motors and 8 sensory inputs would be plenty for a basic system. Can you describe a few model concepts and what they'd be capable of with such a system to give us a better idea of what it would mean? What do the digital outputs do if they don't go to the motors? Could they be routed to other parts of the computer as well as to the model? For example, could one send information to a Basic program running in parellel, like, for instance, a simple chess program which then sent information back through one of the digital inputs, to trigger the next move.
The language has to have a simple core to it which we can all use and understand, and which doesn't need any other software to run it than is freely available for all possible platforms so you can include it on the disc. You could have more complex frills for more complex operations as a subset.
From John Stark
I agree that Meccano (the company) are unlikely to provide us with a genuine "Meccano-brand" computer interface, but, as Chris said, many Meccanomen have developed their own or have experience with various off-the-shelf items. What we do need is a standardised interface that we can purchase. This opens the way for any of us to use it and for the preparation of model plans using it that anyone can build. This, to me would be consistent with true spirit of Meccano - such a computer interface could become a defacto standard part. If we all work with the same interface, then our collective wisdom will enable us to make more progress than if we try to persue our own solutions independently. Which electronically-unchallenged Spanner/s out there is/are prepared to develop such a unit or recommend a cost-effective off- the-shelf item that we can purchase? Perhaps it would be enough just to define the specifications of such an item (e.g. how many things can it control, analogue or digital etc.)? I know Dick Smith Electronics in NZ (and Aussie) sell a kitset parallel port interface that might be suitable. Also I've seen (in the back of Australian PC User Magazine) adverts for Fischer-Technk computer control kits. These look quite impressive (to a novice like me). Anyone had any experience with these? Could they be easily adapted to Meccano?
From Fred Culpepper
There has been much discussion in the last several days on thematter of computer interfacing for models. There are two threads here which are becoming mixed. These are the use of a PC or other computer for the control of a stationary model and the use of an on-board microprocessor for mobile models such as robots and wheeled vehicles. In the case of the stationary model to use the PC, then the problem being faced is an adequate interface between the PC and the model itself. Going back a few years when the personal computer was in it’s infancy, the manufacturers (Apple for example) had game ports mounted on the mother board. The apple allowed four resistance sensitive inputs, three push-button inputs, and four annunciator outputs and a sync. connection. These were all TTL compatible and thus became useful to those who were trying to use the Apple to control some “outside device.” Some third-party suppliers produced and sold interface boards and boxes for use with the personal computer. Lego-Dacta used this approach some years ago with its control box working from Apple to control the several models it could build. These were extensively used in the schools to introduce students to the concept of computer control. There were numerous interfaces available for other brands of computers. The “Fearless Spanner” might enjoy building his own interface. It is not as difficult as it might seem on first glance. There are manybooks available which can provide the needed information. I have used and recommend to others the book, “Controlling the World with your PC” by Paul Bergsman. This book is available through Mondo-tronics, Inc. See: www.robotstore.comThe on-board microprocessor is another topic. I have tried several,but feel the most convenient to use is the Stamp by Parallax. There are two models available which I discussed in an article onDr. Michael Adler’s web site. See: http://users.actcom.co.il/meccano/
Currently, I am rebuilding a “Turtle” constructed in 1974 and operated by relays and photo cells (Electronics Set) and converting the control to the Stamp. Its primary function is to replicate the following of a tape line on the floor which the original Turtle performed. However with the additional attributes of the Stamp, all sorts of gadgets and gimmicks will be added to the new Turtle. Perhaps one day I can show it at one of the exhibitions. In the mean time, I will be supplying Dr. Adler with photographs of the construction of the new Turtle with descriptions of the circuitry, etc. I will be sure to include the program I will use to make the Turtle perform. Meanwhile, if I can answer any questions you have on the use of the Stamp, please feel free to raise the question by e-Mail. I don’t claim to have all of the answers - but I can probably find the answer for you.
From Chris Bourne
Thanks for this and all your other efforts to spread the word about computer control of models. We may all be asking for something impossible without knowing it - the idiot-proof (or almost idiot-proof) system where all the hard work, mediumwork, and most of the easy work, is done for us! If there was only one 'packaged' system for Meccano, I feel it ought to be an on-board system because that's obviously the most flexible - you don't have to transport a computer system with maybe lots more power point requirements along with your model. And clearly you can use an on-board system with a static model. I think what we want is to lose the requirement of reading books about electronics and programming etc which are not about Meccano and which are daunting and instead be able to buy a package which includes:
1) The on-board unit with suitable holes/housing to be bolted into a model
2) The cables
3) The software which would include:
i) The basic software you get with the Stamp, naturally ii) A library of ready made Meccano-friendly routines with short explanations
4) A Meccano friendly booklet to go with it - perhaps expanding on Fred's existing articles and going a bit further, and explaining the nasty unfriendly jargon terms. This should also include a simple model whichdemonstrates some simple functions and thus forms a 'hands-on' tutorial.
5) Any special parts like insulated strips/washers which would be necessary for installing the unit.
6) A small selection of 'sensor' parts - photo-electric, pressure pad, etc- again drilled for Meccano use. This is what a lazy and fearful character like me feels is needed to 'bridge the gap' and make it friendly. It may be that it's just too much to ask, but if Lego could do Mindstorms...?
From Fred Culpepper
>Thanks for this and all your other efforts to spread the word about computer control of models. We may all be asking for something impossible without knowing it - the idiot-proof (or almost idiot-proof) system where all the hard work, medium work, and most of the easy work, is done for us! If there was only one 'packaged' system for Meccano, I feel it ought to be an on-board system because that's obviously the most flexible - you don't have to transport a computer system with maybe lots more power pointrequirements along with your model. And clearly you can use an on-board system with a static model.>
My personal feeling after years of experience in this field is that the on-board microcontroller is the way to go. Of all the microchips that have come my way, the Stamp seems to be the easiest and friendliest to use for the requirements of Meccano modeling.
>I think what we want is to lose the requirement of reading books about electronics and programming etc which are not about Meccano and which are daunting and instead be able to buy a package which includes: Not wanting to read - shame on you Spanners (Grin!) Don't think you are unique - I have experienced that with my students for years and years. But you know, when you really want to learn something, you will find reading about it to be real fun! So let's look at your "wish list"....
1) The on-board unit with suitable holes/housing to be bolted into a model OK - that is easy to accomplish.
2) The cables Cable for programming the Stamp from the PC comes with the Stamp
3) The software which would include: i) The basic software you get with the Stamp, naturally ii) A library of ready made Meccano-friendly routines with short explanations That's no sweat. We can all pass on programs that work when we finish out models. I will volunteer (I get myself into trouble with this) to write some "Basic" sub-routines for Stamp and Meccano for those who need a helping hand. Mostly, the subrountines needed are to operate a Meccano motor, a stepper motor, or a servo motor. By the way, the Stamp will also generate sounds.
4) A Meccano friendly booklet to go with it - perhaps expanding on Fred's existing articles and going a bit further, and explaining the nasty unfriendly jargon terms. This should also include a simple model which demonstrates some simple functions and thus forms a 'hands-on' tutorial. Michael Adler and I have been discussing just such an activity. Let's see what develops.
5) Any special parts like insulated strips/washers which would be necessary for installing the unit. Don't know of any at this time.
6) A small selection of 'sensor' parts - photo-electric, pressure pad, etc - again drilled for Meccano use.OK - again this is no problem. Why not supply Radio Shack part numbers andgive instructions for adapting to Meccano standards? This is what a lazy and fearful character like me feels is needed to 'bridge the gap' and make it friendly. It may be that it's just too much to ask, but if Lego could do Mindstorms...?
From Stephen Jeavons
For those wishing to "have a bash", I noticed that the current edition of the Maplin catalogue has some interface boards..including relay boards which work through the parallel port. programed from Turbo Pascal or Basic. I haven't tried any of these but they look interesting.
From Colin Hinz
I think this can be accomodated. I wonder if the first part of the process might be to develop the user interface, and perhaps thisshould start by having a look at what works well in similar situations -- model train control and other R/C type models. Model R/R control can be fabulously complicated -- the MIT Tech Model Railroad Club is famous for introducing many bright minds to computers 40 years ago -- but I'm sure that elegant and simple control interfaces exist. Not all train fiends are computer geeks, after all.
1) The on-board unit with suitable holes/housing to be bolted into a model and it needs to be reasonably robust, mechanically and electrically. No, not artillery grade, but able to withstand batteries being put in backwards, inappropriate port hookups, and the like.
2) The cables Ideally, cables to hook up to most common sorts of home PC's. Having a USB port for iMAC hook-up would be a grand idea, but would inflate the cost and development effort immensely. Are there USB-to-RS232 translators around yet?
3) The software which would include: > i) The basic software you get with the Stamp, naturally > ii) A library of ready made Meccano-friendly routines with short > explanations
I surmise that these should be in the form of: - operate motor in one direction until limit switch, then stop. - operate motor in one direction until limit switch 1, then reverse until limit switch 2, then stop. - operate motor until user button is pressed. - operate motor only when user button is pressed. ...and so forth, where "user button" would be a big friendly pushbutton on the case of the unit, or connected remotely by umbilical cable.
4) A Meccano friendly booklet to go with it - perhaps expanding on Fred's > existing articles and going a bit further, and explaining the nasty > unfriendly jargon terms. This should also include a simple model which > demonstrates some simple functions and thus forms a 'hands-on' tutorial. The quality of documentation will make or kill this project.
5) Any special parts like insulated strips/washers which would be necessary for installing the unit.
6) A small selection of 'sensor' parts - photo-electric, pressure pad, etc - again drilled for Meccano use. Oh, this would definitely be a must. This is what a lazy and fearful character like me feels is needed to 'bridge the gap' and make it friendly. It may be that it's just too much to ask, but if Lego could do Mindstorms...? No, it's all doable and achievable. I think the major limitation is going to be cost, although it helps that Meccano is not a cheap hobby. I think if the complete package costs a few hundred dollars that's not going to be too unreasonable, if it works well.
From Chris Bourne
Repackaging an already-designed micro board has merit. In addition to the Basic Stamp products (which I have used with much success) there is also the MIT "Handy Board". The latter would have to have some manner of interpreter written for it -- I believe that off the shelf, it's programmed using a C compiler.
From Fred Culpepper
There has been much discussion on computer control of models. Apparently there is a definite interest. As I have read the responses to Spanner and from some e-mail from others, I am forming the opinion that what is needed is a "kit" of components composed of a shopping list (with sources for the components) which will work together for the desired results. I will be glad to work up such a "kit" based upon my experiences with theStamp, but I need to have some sense of just what Spanners truly want. Ihave suggested to Michael Adler that we conduct a survey of Spanners to determine this need in terms of functions the kit will perform. As soon as we know what outputs and inputs are desired and the scope of models to whichthe computer control will be applied, then making up the kit should not betoo difficult. Of course, the contents of the kit" must satisfy the anticipated needs and above all must be as economical as possible.As for programming the Stamp, I envision writing and publishing smallsnippets of code (subroutines) to perform the desired functions. These can then be joined together to program the stamp. For example, there would be a subroutine to direct the speed and direction of a motor. Another would be written for a resistive input such as a photocell or even a potentiometer.
The Stamp introductory package includes a cable to connect the Stamp to a PC on which the code is written. This cable permits the programming of the Stamp. Also, a carrier board is included in the initial purchase which mounts the Stamp and its connectors to the required 9v. battery and a socket for the cable. Parallax (manufacturers of the Stamp) are discussing a method of having the stamp work with a Mac.
I will keep Spanners up to date with the progress if there is sufficientinterest expressed in such a "kit".
From Graham Jost
Dear Fred and other clever-control oriented Spanners,
I am mightily pleased to see this thread develop. I believe that thesmart CONTROL of models is THE way to go for the future - much as I love to see, and build, and be proud of, steam engines and windmills purring silently away. The motorising of Meccano models was thefirst big (huge?) leap forward 80 and more years ago. Then came lights, flashing or sequential ditto, then the Elektrikit and Electronic sets to provide the rudimentary beginnings of something other than the precisely repetitious. With the electronic components - why, even a dash of feedback was possible - with marvellous consequences. Now with computer control we have the flexibility to begin to approach the sort of thing often exemplified by those welding automatons on car body assembly lines. (Not sure whether they have any feedback at all, but they're still wonderfully impressive somehow). And those of you who have been fortunate enough to see Gargantua and other programmed models at work must agree that these really are the most fascinating things to watch - are we subconsciously waiting for a tiny error to creep in to wreck otherwise perfect behaviour?!
There is no doubt at all that many/most/just-about-all-of-us need help to get started. The idea of a survey might provide the assurance to those of you who are prepared to help that your efforts are not to be wasted. If it really is possible to arrive at a single system (or maybe two) that is adequate for most purposes, affordable, and perhaps most importantly where one can go to seek advice when in trouble, then I think we might be onto a winner. I certainly hope so. Could I just add that, once such a suitable system is chosen, perhaps a model or two, which demonstrate the capabilities of the system, might be devised so that we could all build it on a stage-by-stage or week-by-week basis (eg) - as a hands-on tutorial exercise. Having done that once or twice, I would hope that we can each then be well and truly on our own independent way. Maybe such an exercise is unnecessary, but I think it would help me immensely at the beginning. Just a thought. (later) I see that Chris has already identified this matter at his para 4. Good. Please keep up the good work. I'm 101% sure that this is all heading in the right direction.
Graham. PS Yes, I would agree that an on-board or self-contained system is certainly to be preferred. In fact, I'd say mandatory. PPS As a start, would someone kindly tell me what a "Stamp" is - er - in this context? Fred, you see where some of us are at in this field - a very long way behind !!!!
From Rolf Johansson
Let me just express that I would be most interested in your suggestion for a basic kit, making it possible to make Meccano models programmable. Here are some (very basic) requirements, from my point of view*
Local programmable controller to be housed within model is preferred, i.e. model should be capable of performing without beeing attached to outside PC. * Controller has to be operational from same power source as motors for models, which is typically 12 - 14 V DC or 15 - 20 V AC from toy train transformer. (Separate batteries for controller acceptable.) *Posssible to program, load and debug controller over serial RS232C interface from PC running DOS or Win95/98. Simple programming interface and programming language. * Output of controller capable of driving/controlling at least two separate electrical motors: forward and reverse, ev also varying power. * Some four "binary" outputs of controller to switch lights (or ev relays)on and off. Final wish: Simplicity goes before advanced functions!
From Fred Culpepper
I am currently working on my first Meccano model using the Stamp. I have
used the Stamp previously with high school students in my capacity as consultant
to a local school division. This first Meccano model will be the rebuilding
of my 1974 model of the "Meccano Turtle". The original was controlled by
relays and photocells from
the electronic set. The motors were the standard Meccano motor with gear
box. I will retain the same basic design substituting the Stamp for the amplifier
and relay control system. This then would be the first application discussed
for the stamp: "Controlling the Meccano Motors ." This will be followed with
more advanced functions if there is interest in such applications.
From Arup Dasgupta
Many years ago I had the chance to work on a BBC Micro. The attraction of the system was that it had built in ports for controlling devices. I remember the BBC programme on the computer which was made around the BBC M showed a computer controlled robot arm which could grasp release, lift, etc. The programming language was very simple, being an extension of Basic. I believe the robotic arm was made from Meccano. Does anyone remember. It would be sometime in the mid '80s.
The BBC computer must be available at throw away prices now and could be a good candidate for static model controllers. Unfortunately, the ones available in India (under a project to introduce computers in schools) have all been junked.
From Peter Finney
Like many of you I have been giving this problem a lot of thought over the last few months. Functionality is important - the areas we should consider are:
1. DC Motor control - speed, direction, acceleration.. 2. Stepper motor control - speed, direction, acceleration rate, single step control. 3. Digital output - relays, lights etc. 4. Digital input - limit switches, configuration switches etc. 5. Anything else you can think of :-).
Now the problem is - a standard configuration which does all this, and has
enough inputs and outputs to meet any possible model's requirements, would
be much too complex, bulky and expensive. What
we need is a modular system consisting of a central control unit which includes
the main control microprocessor and the programming interface, and a series
of Input/Output modules which provide the interfaces to the 'real' world.
In some cases the IO units might need their own micro processor. To keep
the cost down the control unit might include some control inputs and outputs
so that it could work alone in simple models. The most important thing
is that the control unit and the IO units should have a standard interface
which would allow any reasonable number of IO units to be used in one model
under unified central control. A major advantage is that once the interface
design is established - anyone can design a new IO module to work with it.
This concept is familiar to anyone who works with computers. There are a
lot of design approaches which could achieve these objectives - some more
expensive than others.
A related subject is remote control, even if the model becomes largely
autonomous, there will often be a need to have some external control - even
if its only start and stop. If you can put up with trailing wires for this
purpose - OK, but I feel that they often spoil the effect. What we need is
a remote control system which can interface to the control system through
an IO unit. Possibilities include Radio, Ulatrasonic and Infra-Red. There
are a lot of standard bits and pieces around which could be used for this
purpose. Finally - (at last I hear you
say) - we should consider the problem of power supplies. There is not a lot
of point in providing autonomous operation, with or without remote control,
if we have to have trailing power cable. I'm
considering using re-chargeable (non spill lead-acid) batteries for large
models. These are low-cost for a given capacity, and the chargers are not
expensive. The control system should be designed to run off a power supply
which could
have quite a variable voltage under load/discharge - some kind of power
conditioning module will be needed for this (not part of the main control
module, in case you want to run the control system from a dedicated supply).
I think there are enough of us with the necessary knowledge and skills to come up with the design of a modular system like this using a lot of 'off-the shelf' components.
From Trefor Edwards
My success to date has been with using the GadgetMaster(http://www.pcgadgets.com/) This takes a standard PC parallel output and it works fine. The disadvantage is that it needs a PC attached to it drive it,and it needs some software to drive it. The later I've written myself so that's no problem.
My next stage was to eliminate the permanent link to the PC. I decided touse a 8051 from New Micros, Inc. (http://www.newmicros.com/) (Prices start at $39.00) however it doesn't have a PC parallel port. I foolishly tried to make one myself, and have failed, so I'm going to buy one from New Micros ( NMIS/L-1055 $45.00).
This will then allow me to download a program to the 8051 via the serialport (in EPROM eventually), download a "control file" via the serial port to drive the parallel port which will then drive the GadgetMaster which willthen drive the stepper motors, and sense input signals.
However New Micros do a whole range of add-on cards which would be ideal for Meccano control,
However, this still requires a PC connected to the 8051 if any change needsto be made to the "control file". However, there are plans published on the WEB for a serial IR which would be ideal. Dennis Clarke has some interesting stuff (http://www.verinet.com/~dlc/botlinks.htm). But this side of it is still only in my dreams at the moment. I just don't have the time... I'm a novice at this and I've have limited success. So what are your thoughts on my approach?
From Chris Bourne
Those who recall with pleasure old BASIC Interpreters - and I am one - can find emulators for many of the old machines knocking around the Net which can be downloaded. I don't know how far these go in allowing control of external ports though.
There are freely available BASIC interpreters. I use Chipmunk Basic when Iwant to write a program (a rare aberration on my part) which is freeware. It is very similar to the early BASICs I grew up with and was indeed written with that in mind.
Of course an old Spectrum of the rubber key variety would be great forcomputer control applications where computer and model are linked together as it was so small - I am thinking of the early rubber key varieties. For US readers who were there at the time, this is the Timex 2000 in a caseabout half the size.
The point of the project though is surely to avoid the use of even a BASICinterpreter if possible. The ideal interface for our purposes would be like filling in a form - selecting from options like 'MOTOR 1' and 'LIGHTSENSOR' from a menu, and then filling in the boxes as to the conditions under hich devices are turned on and off, eg, select MOTOR 1 if LIGHT SENSED. For those who can handle a bit of programming, new forms can be compiled or bypassed altogether in favour of code which creates morecomplex decisions.
From Gareth Tuttiett
I still use a 1984 Dragon64 with two standard PC 3.5" disk drives. It uses Microsoft Basic (hardly any different from Qbasic). I use the OS-9 operating system (Unix sub-set) and a Wordstar like wordprocessor. All in 64kb! Still useful and I can read Dragon disks on the PC and vice versa. Old definitely, out-of-date certainly, but lots of fun! Mind you I do have 2 pentium Pcs too! And talking of old 386s, I've got one in perfect working order!
Old PCs are everywhere at tiny prices - even free sometimes. Certainly a good source of computer hardware to comtrol Meccano models.
From George Turner
Check out FutureBasicII. I've used it extensively over the past twoyears and can guarantee that it is vastly superior to MS's QuickBasic, which used to work OK on the pre-68030 Macs. In addition to supporting modernBasic (i.e., no line numbers, no need for GOTOs {SELECT CASE, block IFs,etc}, and capable of subroutine and function naming), it is can interface with and control everything on the Mac with full access to the ToolBox routines, and the Apple Event Manager. You can even create your ownextensions to the operating system. And, best of all, the Basic source code can be compiled and packaged for distribution to others who have Macs. It's a bit pricey at $200US but you get a lot of documentation and other tools --it's good value for the money. (This software was recommended to me by the Mac Users' Group when I sent out a note lamenting the disappearance of Basic as a standard item with a computer purchase.)You can get product info from the Web site at <www.stazsoftware.com>
From Peter Finney
I seriously think FORTH would make an excellent control language for Meccano - but there is not much hope of persuading anyone else :-(. I still have the complete source code for a very powerful FORTH system I wrote for the PC about 10 years ago. It all fits on one floppy (including editor and in-line assembler) and runs very fast on the original IBM PC. You can imagine how fast it is on a Pentium!
From George Turner
Peter, Michael, and Spanners...After thinking about FORTH for the first time
in a great many years as a
result of Peter's comment, and after looking at Michael's comments andquestions,
I thought I'd check and see if the language is still alive and up-to-date.
Using the Lycos search engine on "forth", I found the "FORTHInterest Group"
at http://www.forth.org/fig.html.
FORTH has always been an anti-establishment type of language, propagated
by programmers at the grass roots. As a result, there are numerous compilers
available, both commercial and Freeware. All platforms are supported -- Mac,
Windows95, Windows98, Windows NT, Linux boxes. It seems that ANSI standards
have been developed, and a lot of work has gone into proper programming style
and documentation -- good source code should be almost readable English (or
actually any other language, since words are defined by the user). It seems
that anyone interested in FORTH can download a Freeware compiler and some
documentation and get started right away. But the really good news is the
use of FORTH for robotics. From the FIG homepage, select "FORTH compilers".
Then select "Lego Mindstorms port". Created for Mindstorms/Robotics hobbyists,
this is a FORTH compiler for the RCX called pbFORTH -- i.e., programmable
brick FORTH. Interesting links from this page are... 1) NQC (not quite C)
used to get firmware into the RCX; works on Mac, Windows, Linux boxes); 2)
RCX Internals (a complete reverse engineering of the RCX, including pictures,
description of components, and op code);3) RCX Robotics (robotics applications,
available peripherals, and so on). Although I am new to this topic, there
appears to be a wealth of info on FORTH and robotics that would make at least
a good starting point for the Meccano application. I believe all of Michael's
questions are answered. (Because I wanted to send this note out as soon as
possible, I haven't had a chance to download any of the material for review,
although I did look at the 3 aforementioned interesting links -- but I will
do so over the weekend.) The Lego hobbyists have apparently chosen FORTH
as their control language to replace Lego's off-the-shelf firmware. It seems
that all of the above is Freeware, for the advancement of the FORTH Interest
Group. But membership is encouraged, and some links are restricted. Peter,
your mention of FORTH might have revealed the mother lode on this topic.
From Peter Finney
FORTH was invented over 20 years ago by Charles H Moore. He was a professional astronomer who was looking for a method of automating the operation of an optical observatory. He wanted to be able to control all the functions of the observatory including all the motions of the telescope(s), opening and closing of the dome shutters, camera operation etc. The problem was that in those days the computers available were very puny affairs and what was worse, the available software was very primitive.
Moore wanted to be able to do three things:
1. Interface easily to lots of different input and output signals.2. Develop software easily and rapidly without having to go through a complex process of code writing, compilation, object code linking, debugging etc.
3. Finish up with a language with semantics (ie subjects, object and verbs) which fitted his problem. In other words he wanted to be able to issue a command like "shutter_open" and see it happen (nice thought - eh?).
After several misfires he came up with FORTH- the fourth attempt :-) - the computer he was using had an operating system which could only understand commands with a maximum of 5 letters! (This restriction disappears inside FORTH of course :-).
It is possible to get FORTH implementations which run on virtually any computer or micro-processor you can think of. FORTH is VERY easy to port to any computer which has an assembler. Assembly language is used to create the kernel of the FORTH system - the rest is then defined in FORTH - a bit llike pulling yourself up by the bootstraps. As I mentioned in my original posting - I developed my own system for the PC (over a few weeks in 1987). Naturally I think my system is SUPERB , but there are plenty of public domain versions around. In case anyone thinks that FORTH is a dead language - there are sevral internet discussion groups devoted to it, as well as powerful commercial systems.
Relevance to Meccano - 100% - this is and always will be primarily a control language. It would be very easy to interface it to any interface hardware you like via any PC interface (serial/parralel/game port for example {or all three at once}).The details of the physical interface would be hidden from the 'end' user - who could develop a control language to suit his model.
For example if you were controlling a walking dragline (5 motions) you might see commands like:
right slew
10 wait stop slew
This could cause the machine to slew right for 10 seconds.
Or:
start walking
10 wait
stop walking (walk for 10 seconds)or:
50 5 up hoist (hoist up at 50% full speed for 5 seconds) stop hoist etc - (use your imagination).
FORTH can either be an interpreted language (which does not need to be compiled - like BASIC). Or it can have an 'incremental compiler' which compiles FORTH commands and objects as they are entered. Either way looks the same to the user - except that the incremental compiler results in a programme that runs faster. (My system is incrementally compiled).
If all that seems to good to be true - there is a downside. FORTH uses a 'strange' syntax called reverse polish notation. In general terms all values are entered before the operands. The values are 'pushed' onto a stack - the operators 'pop' them off the stack and 'push' the results back onto the stack. (Anyone who remembers using some of HP's pocket calculators will recognise this). For example if we had in BASIC:
PRINT 1 + 2 (This prints 3 on the screen)
the FORTH version would be:
1 2 + . (notice the '.' - that means print!)
This is interpreted by FORTH as:
1. push the value 1 onto the stack 2. push the value 2 onto the stack 3. pop the top two values off the stack and add them together; push the result onto the stack 4. pop the top value off the stack and print it out
In case you are thinking that '.' is a pretty strange print command - you may well be right - but don't forget in FORTH you get the ability to define your own language - like this -
: printnumber . ;
which defines a new command 'printnumber' which has exactly the same meaning as '.' (which still works - by the way).
hence the above example could now be
1 2 + printnumber
with exactly the same result.
This is how you build up your own control language from primitives.
The original FORTH system allowed you develop your application by 'compiling' it from 'screens' which each had up to sixteen lines of up to 64 characters (the numerate amongst us will have recognised that this is 1024 characters OR 2 to the power 10 - as Dogbert would say 'a nice round number'). The reasons for this need not concern the student - except to say that it had to do with available terminals and computer storage efficiency. The 'screens' are stored on the computer disc. Any number of screens can be linked together to build an application. FORTH comes with a special editor (written in FORTH of course) to edit the screen texts.
Modern FORTH systems allow the FORTH text of an application to be interpreted or compiled from a text file like any 'normal' language. 'My' FORTH allows either or both at the same time (if you get my drift).
I suspect you are all exhausted by this by now (those who are still with me). I'll finish by saying I am willing to make 'my' FORTH system for the PC available to anyone as 'user supported' software. (FORTH for the Mac exists ). Anyone still listening?
From George Turner
Your background info on FORTH should go a long way towards demonstrating how ideally suited the language is to controlling motors, solenoids, shutters, etc -- especially since this was its reason for being. The following is something I remember from my initial introduction to FORTH, in the early 80s, and is for the benefit of Spanners who might not be familiar with the language...
You start the project by building simple words using the standard vocabulary, then gradually build up more complex words based on what's already been defined. The following is a rather trivial example that demonstrates the procedure and the elegance of the language (hope there are no coding errors as I haven't programmed in FORTH for years)...
First define a word to print a single asterisk...: Star." *";Then define a word to print any number of asterisks...: Stars 1 DO Star LOOP;
Then if I write and run: 10 Stars I get 10 asterisks on the screen.
Peter, in the Meccano crane example you provided, you had the program fragment... 10 Wait This is similar to the above DO/LOOP structure for drawing stars, except that the body of the loop in your example is a 1 second time delay.
Use of the stack and reverse polish notation is a bit daunting at first. owever, after I had been programming in FORTH for a while, I decided to keep all my definitions in a loose-leaf notebook. I made a stack diagram for the input, every step within the definition, and finally for the output. The diagram was basically a stack of blocks with a couple of letters in each block (or an arrow pointing to it) to denote the contents. I'm not sure I'd say the reverse polish notation is the downside. I think keeping track of the stack is the downside, which is why I decided to keep the notebook. You did not mention that if you put more on the stack than you take off, or vice versa, the consequences are unpleasant -- as in using assembly language.
In the meantime, I've looked some more at the FORTH Interest Group site and have found links leading to tutorial documentation in MS Word. So, not only can you download an excellent compiler for free, you can also get complete documentation for free.
Compiled by Michael Adler
| return to previous page |