CNCZone Driver Group Project

[aubrey]

Hi Everyone,
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.

Lastly:

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.
Best
Aubrey

[ger21]

One quick note. CAM software doesn't control machines, it creates G-code from CAD files. Your talking about writing Controller software and building hardware for it.

[aubrey]

Originally Posted by ger21 One quick note. CAM software doesn't control machines, it creates G-code from CAD files. Your talking about writing Controller software and building hardware for it.

Thanks,
Oops - Fixed (but I am sure you know what I was trying to say)
Best
Aubrey

[VigilanteDesign]

you are talking about some kind of data-cache/-buffer?!

[daedalus]

I dont mean to knock your project, but Isnt it already done in Gecko g101? And that has integrated support comming in mach3, probably the most used windows package around.

Im sure you could build something much cheaper, but mach3 support is a nice feature to have.

[pminmo]

I too don't want to discourage. First problem I see is lack of machine feedback. i.e. it's nice to see the cutterpath on the screen as the machine is doing it's thing for a visual comfort level and awareness. So to include that makes the task grow. Ultimately a PC has all the bells and whistles that a machine controller needs. I suspect the effort is better spent in delving into shutting down windows services to just bare essentials.

On the open source side, if anything I would advocate the creation of a data stream protocol defining syncronization of hardware with a basic command set that could utilize USB, firewire, tcpip.....

Or could be an embedded G-code state machine spewing out parallel port information on the other side to be compatable with existing hardware.

[VigilanteDesign]

Why not have the controller-software running on a stripped linux and controlled via ethernet by a "real PC" with all the CAD... ?
You could send the G-Code via console batch script to the linx or something like that, should be quite comfortable.

[t3kno]

It sounds like a real time version of linux is what you're looking for. Linux really is the best choice for this type of application, Winders was never meant to be a real time OS.

[ataxy]

could this be what you want
http://www.atelierrobin.net/p41.htm

ARCNC100 features

6 axis: x,y,z,a,b,c step and direction outputs and limit inputs
Accepts standard G-Code input files
Pulse rates up to 4.7 MHZ on all axis simultaneously.
Very clean and stable pulse train with cycle-cycle jitter < 13ns
Variable duty cycle step outputs
6 quadrature encoder inputs (A,B,I)
4 analog outputs
4 10 bits analog inputs
16 digital outputs
20 digital inputs
Runs from a single unregulated power input from 6-26V DC
Mini-ITX form factor main board directly connects to our custom FPGA logic and motion control IO card via fast ethernet.
Total Dimensions: 6.7"x6.7"x3"
Standalone operation (runs G-code completely independent and disconnected from PC )
User customizable via tcl/tk ,Python scripts or C/C++ user programs.
Main board is I586 compatible PC. Users can develop custom applications on their standard desktop PC and then copy to ARCNC100 via ethernet.
Standalone PLC co-processor for running ladder logic
Supports very large G-Code files (only limited by CFcard, up to 4 GB)
Can run/edit/save/open G Code files standalone (without PC)
Ethernet connectivity for file download from PC
MS-Windows PC, Mac OSX and Linux ARCNC software to edit/download GCode files to the ARCNC100
256 MB of flash storage (CF card included) upgradable to 4 GB via standard CFFlash card (same used in digital cameras and MP3 players)
User interface: PS2 keyboard+mouse connector and VGA video output connector.
Compatible with popular stepper motor drivers from Geckodrive, Rutex , Xylotex, DeskCNCand others.
Price for ARCNC100 hardware/firmware and PC/Mac software to edit/copy files to ARCNC100: $599 US for qty 1. Please email us for quantity pricing.
Runs EMC 2.x headless (no keyboard/monitor) in a compact format.