Welcome to the CNCZone Driver Group Project.
My name is Aubrey O'Callaghan and with YOUR permission I am going to Project Manage this project.
What is this project all about?
A large number of CNC Hobbiests use Micro$oft Window$ as the Operating System platform for thier hobby.
The reasons are many and include "My computer already had Window$ on it", "My CAD package is Window$ based", "I find Linux overwhelming" and so on.
Because Window$ is a "multi-tasking" (or more accurately "Time-Slice") operating system, it is always doing things in the background that the person behind the keyboard OR the program busy executing has absolutely no control over. The same is true of Linux in its standard form.
What this means is that if the application needs to send data (a step instruction in our case) to a port (Serial, Parallel or USB) at a precise millisecond in time, the operating system may be doing something else and the data will arrive AFTER it should at whatever is connected to the port in question.
The effect is that the step instruction/s are delayed and when the operating system returns access/control of the port to the application, there is a que of instructions waiting.
The operating system then quickly fires off the que to the port with no regard to the timing intervals that the application wants them to be.
The result is that the stepper motor driver board connected to the port tries to execute the step instructions as fast as they are being recieved. Sometimes this does not matter but more often than not, something goes wrong!
Motors with a slow reaction time will simply skip a step - Result: Accuracy shot to hell.
Motors with a fast reaction will move at a ridiculously fast rate which can result in broken tools, gouged workpieces and bad finishes to name but a few.
Many of us have put a lot of time, effort and money into our mills.
Many of us have built our own mills from scratch and are justifiably proud of our achievements.
Many of us are starting to get just a little bit Pi$$ed off that our mills are not operating correctly.
The motor driver boards are blamed for not moving the motors correctly. Put in others (at a cost).
Then the GCode to Step packages are blamed for not sending the driver boards the signals correctly. Get Another Package (at a cost).
Then the motors are blamed for not stepping correctly. Replace them too (at a bigger cost plus much work).
Eventually we either decide to live with it or chuck the whole lot in the dumpster and go watch TV.
All because the operating system on the PC is not sending the signal to the port when it should.
Now don't let the Linux hardcore tell you differently, the STANDARD Linux installation does this too. For example, the "EMC" application needs to run on a specially prepared Linux installation for it to run as good as it does. Like many, I have tried Linux but from a users point of view I find it painfull.
So, Where are we now?
On the one side we have got our favorite CAD package where we spend hours designing bits and pieces.
On the other side we have the axis movement motors on our mill.
In the middle we have an operating system that wont do what it should PRESISELY when it should, and a CAM package that is trying to step the motors but cannot do so presisely because the operating system has its own agenda.
On this side of the keyboard there are you and I who are getting seriously upset because things are going wrong.
What do we need?
Apart from a stiff scotch, we need something that will efficiently work around the Micro$oft operating system timing inconsistency problem. Easy to say, NOT so easy to do!
Broken down into tasks, it looks as follows:
We have our PC running Window$ and our favourite CAD package.
We need an application to read the GCode file and generate a step file.
This file MUST include timing references so that the time between steps is defined IN THE FILE.
The commands in this file MUST also be able to do a whole bunch more than only step motors.
ie. Tool Change Operator pauses, LCD display text, Auxiliary Switching (coolant, vacume, clamping etc) and so on are to be catered for.
BUT the step file is still on the hard drive of the PC!
Now we need an application to read the step file and send it (in a controlled fashion) to the port of our choice.
OK. So whats on the other end?
A couple of PICs and some memory.
Doing What and How?
Receiving the step file from the PC is the INPUT PIC.
Its job is to receive the data and store it (in bulk) to a set of memory chips.
When all the memory is populated INPUT PIC flags CONTROLER PIC that the processing can start.
CONTROLER PIC tells OUTPUT PIC to use the first memory chip and to start the execution.
[Process Loop Start]
OUTPUT PIC reads each command from the memory and executes it
When all commands in the current memory chip have been executed, OUTPUT PIC tells CONTROLER PIC that it is finished.
CONTROLER PIC tells INPUT PIC to re-populate the used memory from the PC
If there are unprocessed memory locations then CONTROLER PIC tells OUTPUT PIC the address of the next memory and the process continues at [Process Loop Start]
Else there are no more steps/instructions and the process terminates - JOB DONE!
Sounds Simple doesn't it! - Yea Right.
But if it is broken down into sections and tasks and each goes thru a "Request For Comment" stage, the overall requirements, inputs and outputs are decided on and it is eventually distilled down to the final design (PCB Design, Step Command Format, PIC program structure etc etc) I think it can be done. It will be "interesting" but it can be done.
What kinds of skills do we need?
This is the difficult one to define!
Visual Basic or C++ for the GCode to StepCode conversion app and the stream to port app (maybe the same app??)
PIC Programming and circuit board design for the Main Controler array
People who have a good knowledge of motors, stepper motors, feedback circuitry and loops etc for the bits that actually talk to the motors.
Large amounts of breadboard and parts to see if the designs work or goes pop.
"Kind Words" and "Moral Support" experts to help us all thru the more problematic bits.
As this will be a group effort and I forsee that many things will be "borrowed" from the open source resources out there, this entire project should be open source. Credit should be given where credit is due whether it is a person designing a circuit or a site/project where we got ideas and solutions, ALL SHOULD BE GIVEN CREDIT.
If any member of CNCZone feels that they are willing to become a part of this effort, please add an entry on THIS forum with the heading "Volunteer" and list your particular areas of expertise so that we can build up our "Project Contributor" listing.
I will be opening a "PROJECT COMMENTS" thread for general comments as well as a "REQUEST FOR COMMENT" thread where general ideas, requirements and discussions can be posted.
PLEASE DO NOT POST GENERAL COMMENTS TO THIS THREAD! It should only contain the "Project Contributor" names and skills.
Thanks for reading this entry.