Motion Control Technology
Lynton Manufacturing Service
This system enables a standard P.C for use as a dedicated C.N.C machine controller .
Let me take a paragraph or two, by way of introduction, to explain some of the reasoning which formulated the objectives and dictated the hardware requirements for the system design.
My company has, for many years, specialised in sub-contract C.N.C machining. The machines, although dated continue to produce good quality work , however, the programming and editing facilities of the controls were seriously limited. The cost of machine replacement was prohibitive, so I began to explore the options available for upgrading the controls.
To overcome the limitations of my existing controls I established methods of off-line programming using 3rd party CAD packages and a parametric programming facility which I had created. Part programs were then uploaded to the control as a list of thousands of 3D co-ordinates, this made line by line editing impractical, and as a result all programming and editing functions of the control became redundant. The only function the existing controls were now performing was the signal processing. Most modern C.N.C controls provide elaborate front end programming packages and certainly charge for the facility. I was looking for a more modest solution and have always questioned the wisdom of using a CAD/CAM system at the controls while an expensive machine stands idle.
My office PC provided all the computing power I needed for part programming, so it occurred to me that by adding the signal processing interface to a PC the existing ‘machine controllers’ could be by-passed completely. Unfortunately amalgamating the programming and machine control functions into a single PC was sacrificing the independent programming facility I wanted to preserve .
The system therefore needed to include a simulation mode which could be run on a desktop PC to develop programs before they were sent to the machine controls.
Although at this sage I had not decided the build a control, the first objective of my design had been established.
1:- It would be a PC based controller.
Trying to purchase a PC based control interface which I could adapt to provide the working environment I envisaged proved difficult.
All affordable ‘software’ applications seemed to be dedicated to stepper motor technology and the ‘closed-loop DC servo controls’ were supplied as complete motion systems, packaged in pre-programmed integrated circuits (DSP’s) , and assembled as PC Plug-in cards.
These effectively offered little more versatility than any of the stand-alone controllers and the only way to achieve a simulation mode was to install a duplicate controller card in the office PC, a very expensive luxury.
I was impressed with the approach and enthusiasm displayed by the stepper system designers and users who were encouraged to
‘have-a-go’ and convert their own machines to C.N.C.
My machines were driven by DC servo motors and I did not want to replace these with stepper motors. I had noticed that many users having built stepper motor driven machines were keen to switch to DC Servos and some manufactures were supplying drive amplifiers to facilitate the conversion. These amplifiers are designed to accept the stepper ‘pulse & direction’ commands, plus the encoder feedback signals and then close the DC servo loop internally.
Using this method to achieve DC servo control seemed expensive, all the costs related with servo drives were incurred, yet most of the advantages were being sacrificed. The control remained ‘Open-loop’ and the encoders did not provide a true and independent Digital Readout display.
Many C.N.C conversions do render the machine less user friendly than the operator might like, as above, the D.R.O facility is omitted,
making it difficult to achieve any manual positioning of the slides.
I have described my design as a ‘Modular approach to C.N.C’ but it could be better described as versatile. A practical machine conversion should offer a good variety of operating modes, so versatility would be another objective.
My system must include the following modes of operation - Simulation, Manual, Semi-Automatic, and Full C.N.C. I had now decided to build my own controller and all my objectives had been established.
2:- It would be a ‘Software’ Closed-loop DC Servo Control.
3:- It would be comparable in price to the popular Stepper Technology.
4:- It would be Versatile
Let me take a paragraph or two, by way of introduction, to explain some of the reasoning which formulated the objectives and dictated the hardware requirements for the system design.
My company has, for many years, specialised in sub-
To overcome the limitations of my existing controls I established methods of off-
My office PC provided all the computing power I needed for part programming, so it occurred to me that by adding the signal processing interface to a PC the existing ‘machine controllers’ could be by-
Although at this sage I had not decided the build a control, the first objective of my design had been established.
1:-
Trying to purchase a PC based control interface which I could adapt to provide the working environment I envisaged proved difficult.
All affordable ‘software’ applications seemed to be dedicated to stepper motor technology and the ‘closed-
I was impressed with the approach and enthusiasm displayed by the stepper system designers and users who were encouraged to
‘have-
Using this method to achieve DC servo control seemed expensive, all the costs related with servo drives were incurred, yet most of the advantages were being sacrificed. The control remained ‘Open-
making it difficult to achieve any manual positioning of the slides.
I have described my design as a ‘Modular approach to C.N.C’ but it could be better described as versatile. A practical machine conversion should offer a good variety of operating modes, so versatility would be another objective.
My system must include the following modes of operation -
2:-
Objectives 1&2 had ,to a certain extent, identify the required hardware. It was going to be a PC based software application which used the computers CPU to perform the servo loop routines.
Two major limitations of to-day’s standard PC, for this type of application ,became immediately apparent. A Servo Motor Controller would make ‘REAL-TIME’ demands on the computers operating system and this is not a facility available with any of the standard WINDOW’S multi- tasking operating systems. Also, the Plug-&-Play technology utilising the USB port restricts the I/O interface options available for ‘industrial’ use.
Computing technology has evolved rapidly in response to the demands of multi-media applications. Giga-bytes have replaced kilo-bytes as the standard specification, and processor and bus speeds have multiplied to accommodate the requirements of solid modeling, 3D graphics and vast databases, but all this comes at a price, and is superfluous for the rather snail-like process of motion control.
The type of PC, the operating system and the interface needed to be carefully selected to suit this project and must also be available at an affordable price.
Reclaiming 1st generation Pentium machines proved a very cost effective solution, people were paying to have them taken away and they provided all the computing power necessary for this application. They also made use of the 16bit 8Mhz ISA bus thus providing a simple and effective solution to the I/O interface. The downside of this solution was that these machines were obsolete and the thought of developing software for outdated machines was less than encouraging. However, not all computer manufactures had fully committed to the multi-media revolution, there are competitively priced alternative systems available which are ideally suited to embedded control applications.
The PC104 Computer system offers the full PC architecture with an ultra compact footprint of just 100 mm x 114 mm, a basic configuration is available with a 486 processor and utilises a 104 pin stack-through bus which is compatible with the 16bit ISA bus.
It was the PC104 system which I selected as the host computer for the L.M.S motion control project , but also retained the option for older redundant PCs to be converted into dedicated machine controllers
Summary:-
A: Is a multi-tasking Operating System required for a dedicated application? ----- ----- No.
B: Would the system require mega-bytes of memory? -----------------------------------------No
C: Did I want a relatively expensive ‘super’ computer, under-utilised, and stuck
under a bench in the workshop? --------------------------------------------------------------- No. ( and I needed 1 for each machine, 3 in total)
D: Is there an economical alternative to the Multi-media PC?---------------------------------Yes
E: Is there a ‘REAL TIME’ operating system which is compact, fast, and efficient ? -- Yes.
F: Is it free? ----------------------------------------------------------------------------------------------- Yes.
The MS-DOS 7.1 operating system is in the public domain. It is capable of ‘real-time’ interfacing and can be installed on any PC .
For my prototypes and to prove out both configurations I installed MS-DOS 7.1 on reclaimed 1st generation Pentium machines and on a new Vortex 86 PC104 cpu module.
Selecting the interface turned out to be a compromise. Using the parallel port to replicate the stepper system designs may have been a possibility, and would have resulted in the ‘software only’ solution I was trying to achieve. The analogue outputs however would have been formatted as PWM signals and then decoded externally, but more critically, the incoming encoder signals could not be monitored continuously resulting in a possible loss of positional data and this was totally unacceptable.
The use of some additional electronics was inevitable.
Plug-in interface boards provided a solution to both problems. There are plenty of proprietary boards available with analogue outputs and that are capable of decoding and monitoring quadrature encoder inputs. Unfortunately the cost of these boards was beyond the project’s budget and writing software drivers to accommodate a variety of 3rd party hardware was another unacceptable complication.
A single multi-function interface board to provide both the Digital-to-Analogue conversion and continuous encoder monitoring was my preferred solution. I was confident that a P.C.B, using readily available DAC’s and counter I.C’s , could be designed which would be economically viable.
The software and the Multi-function interface board would form the complete package.
The interface board could be supplied as a tried and tested assembly or as a bare PCB + a component list as a self-assembly option.
Two major limitations of to-
Reclaiming 1st generation Pentium machines proved a very cost effective solution, people were paying to have them taken away and they provided all the computing power necessary for this application. They also made use of the 16bit 8Mhz ISA bus thus providing a simple and effective solution to the I/O interface. The downside of this solution was that these machines were obsolete and the thought of developing software for outdated machines was less than encouraging. However, not all computer manufactures had fully committed to the multi-
Summary:-
A: Is a multi-
The MS-
Selecting the interface turned out to be a compromise. Using the parallel port to replicate the stepper system designs may have been a possibility, and would have resulted in the ‘software only’ solution I was trying to achieve. The analogue outputs however would have been formatted as PWM signals and then decoded externally, but more critically, the incoming encoder signals could not be monitored continuously resulting in a possible loss of positional data and this was totally unacceptable.
The use of some additional electronics was inevitable.
Plug-
