joebrown.org.uk

Converting a Proxxon MF70 Milling Machine To CNC – 4

A Simple Thumb Drive G-Code Delivery System

Updated with File System Source-Code & example of logging 15th April 2012

This post in one in a series. Other posts you may be interested in are as follows:

At the start of this series of posts, I said I did not want a PC to control my Milling Operations, so some local delivery method of supplying the gcode files is required. Having said that, the system is ‘open’, and a simple XON/XOFF terminal program running on a PC can be used if required. G-Codes can also be typed in on a terminal keyboard, though this method could prove tiresome with even moderately-sized circuit boards. It is, though very useful for simple tests.

Whilst deliberating the problem, I first considered the Vinculum, from FTDI, but naturally (for me) would have preferred a PIC-based OTG (on-the-go) system. I had been carrying on email conversations regarding this with Gert Bouland in Holland, and he had suggested the Elektor USB Logger project (from December 2011) as one possible candidate. Gert subsequently kindly sent me a fully-built board, complete with PIC installed. I downloaded the logger firmware into the device, connected it up to the serial port of the Mill Controller and established that it worked. I then set about demolishing most of the original source-code, and developed the simple File System I describe below.

Before doing that is would be useful to briefly describe the original ‘logger’ hardware as presented in Elektor. If you haven’t already got a copy of Elektor December 2011, I recommend you purchase one, and read the full article by Thomas Fischl, if you intend to follow my route.

The schematic for the Elektor logger has been reproduced below:

The Elektor USB Data Logger - December 2011

The schematic shows a PIC24FJ64GB002 connected as a USB ‘host’ to the USB type ‘A’ socket. Interface (via the internal UART) is made by a dedicated set of peripheral pins to the 2-row 10-pin header.

Four connections are brought out in this way, sufficient for RX,TX and RTS,CTS if required. My application uses only RX and TX, handshaking being achieved with the software protocol XON/XOFF.

Circuit operation is simple, with a one-button/one LED (not shown on diagram) user interface.

On power-up, if a thumb drive is present, the unit will self-configure a baud-rate from a ‘config.txt’ file on the thumb drive, then start logging characters received on the RX input line. When desired, logging can be stopped by hitting S1, and then the thumb drive can be removed, and a file ‘LOGGING.TXT’ can then be accessed by plugging the drive into a PC.

Use of the logger hardware for providing access to gcode files can be made with no changes to the hardware whatsoever – but I added a reset switch between MCLR and GND – a necessary addition I felt.
Update 15th April 2012.
I have removed the setting of the baud rate from ‘config.txt’, and also removed any support code for this. My application uses 19,200 Baud as a ’standard’, so I’ve hard-coded this in ‘main’.
I also added 2 LEDS to the hardware, one to signal when XOFF is in operation (which is most of the time), and one toggled on a byte send to the Mill Controller. These LEDs are connected to RA1 and RA0 respectively. (see source-code for operation of these LEDs)

Milling of circuit boards will require access to three types of files:
1. A drill file.
2. Top-trace routing.
3. Bottom-trace routing.

Using the gcode-producing facility on Eagle files produces different names for each file, but I wanted to keep the system as simple as possible, and most importantly, avoid long filenames. I plumped for three filters for the three file types above:

*.ncd – drill files
*.nct – top trace files
*.ncb – bottom trace files

Furthermore, these are known only within the file system itself – I see no need to propagate fixed alpha strings into the Mill controller, so that the Mill controller only knows of files of type 1,2 or 3. That means, when you decide on a different naming convention, only one change to one set of software needs to be done.

We need the following facilities on the Mill Controller and File system then:

Ask the file system to give a list of files of a given type, 1, 2 or 3.
Ask the file system to send the contents of a file, line by line.
Additionally, the file system should recognize a signal for temporary halt (XOFF), and when to re-start sending the file (XON)
Finally, the file system should recognize an abort signal. (CAN)

Currently, because of the limited scope of the Mill Controller keypad, most of the ’special’ facilities are accessed as so-called functions. In the table below, I have described the actions for each of these in turn, with appropriate reaction by the File System.

Function No.	Purpose	File System Action	Result
50	List files in group 1, one at a time.	File system searches on drive, and presents 1st file to Mill Controller (if found) from group 1	Filename displayed on Mill controller LCD
51	List files in group 2, one at a time.	File system searches on drive, and presents 1st file to Mill Controller (if found) from group 2	Filename displayed on Mill controller LCD
52	List files in group 3, one at a time.	File system searches on drive, and presents 1st file to Mill Controller (if found) from group 3	Filename displayed on Mill controller LCD
53	Fetch next file in list.	File system searches on drive, and presents next file to Mill Controller (if there is one) from current group.	Filename displayed on Mill controller LCD
54	Execute current file.	File system presents contents of current file to Mill Controller, line by line.	Lines of gcodes executed by Mill Controller.
55	Abort current operation	File system aborts current operation, closing any open files.	Action on Mill Controller halted.

Software handshaking, using XON and XOFF is carried out transparently, by the software.

A code snippet from the software main loop running inside the file system, should give some clarity to one side of these transactions:



		if (deviceAttached) // stick inserted in orifice?
		{
			// check for incoming data from Mill Controller
			if (rx_in_index != rx_out_index)
			{
				// there's a char
				ch = rxbuf[rx_out_index++];
				if (rx_out_index == BUF_SIZE)
					rx_out_index = 0;

				switch (ch)
				{
					case XOFF : // stop sending to controller
								stop = 1;
						break;
					case XON : // re-start sending to controller
								stop = 0;
						break;
					case STX : // start of text command
								for (cmd_index = 0; cmd_index < CMD_SIZE+1; cmd_index++)
								{
									cmd[cmd_index] = 0x00; // zeroise command buffer
								}
								cmd_index = 0;
						break;
					case ETX : // end of text command
								ExecuteCmd(cmd);
						break;
					case CAN : // cancel current sequence
								if (myInputFile != NULL)
									FSfclose(myInputFile); // close any open input file.
								tx_out_index = tx_in_index = 0; // cancel anything buffered
								stop = 0; // cancel any current XOFF

						break;
					default: // place char in cmd buffer
								cmd[cmd_index++] = ch;
								if (cmd_index == CMD_SIZE)
								{
									cmd_index = 0; // CMD BUFFER FULL
								}
						break;
				}
			}

			if (tx_in_index != tx_out_index) // if there's data for the Mill Controller, send a byte of it
			{
				// there is stuff to send to controller
				if (!stop) // not stopped by previous XOFF?
				{
					// output a char to UART
					while(U1STAbits.TRMT == 0); // wait 'til last sent
					{
						unsigned char ch = txbuf[tx_out_index++];
						U1TXREG = ch;
						if (tx_out_index == BUF_SIZE)
							tx_out_index = 0;
					}
				}
			}
			else // no data? Are we executing a gcode file currently?
			{
				if (myInputFile != NULL)
				{
					// then get next line to send to UART
					if (!FSfeof(myInputFile)) // check for end of file
					{
						chsread = freadln(line, BUF_SIZE-1, myInputFile); // read line until CR/LF
						if (chsread != 0)
						{
							for (i = 0; i < chsread; i++)
							{
								SendBufferedChar (line[i]); // place line in TX output buffer
							}
							SendBufferedChar(CR); // Mill g-code interpreter needs these
							SendBufferedChar(LF);

							// debug - log it as well
							Log(line);
							LogChar(CR);
							LogChar(LF);
						}
					}
					else // end of file, so close it.
					{
						FSfclose(myInputFile);
					}

				}
			}			

		}

It can be seen from the 1st section of code (the switch and case statements), that commands from the Mill Controller are split into two groups. Those that manage the flow of data between the Mill Controller and the File System, and those that respond to commands regarding the file system itself.
The 1st group is reasonably self-explanatory, the second may not be immediately obvious. A file-system command is sent from the Mill Controller bracketed with STX and ETX – in other words each command must begin with the control code STX and finish with ETX. The command is assembled, byte by byte received in the buffer ‘cmd’, and only when ETX is received is an attempt made to service it. This is shown in code snippet 2, below.
It might prove useful to point out that ‘ext_strs’ is an array containing the 3 filters previously discussed (*.ncd, *.nct, and *.ncb)



///////////////////////////////////////////////////////////////////////////////
//
// Execute command for Mill controller
//
// Set up execution of a command
//
// commands are simple:
// a letter possibly followed by a number in some cases
// Example sequences:
// "D1" : search directory for drill files (extension .ncd); response: if none found return 'NAK'
//        else return ACK then STX and retrieve and send the filename and extension . then ETX
// "N" : retrieve and send next filename found; same as for "F". If list exhausted, return 'NAK'
// "E" : retrieve and send each line of the (current) file (name in rec) (terminated CR/LF) in sequence;
//       response: do this until instructed to stop with "CAN" or told to halt (temporarily) with XOFF etc.
//
// The control code 'CAN', if received, will stop execution, cancelling any sequence, and close any open file.
//
void ExecuteCmd (char * cmd)
{
	int n = 0;
	int attr;
	switch 	(cmd[0])
	{
		case 'D' : 	// need a number specifying file extension
			n = atoi(cmd+1);
			attr = ATTR_MASK;
			filefound = 0;
			if ((n > 0) && (n < 4)) // accept ONLY 1 - 3
			{
				filetype = n - 1; // (lookup array is zero-indexed)
				// do Findfirst
				if  (FindFirst (ext_strs[filetype], attr, &rec) == 0 )
				{
					SendByte(ACK); // success , got a name
					SendBufferedString(rec.filename);
					filefound = 1;
				}
				else
				{
					// none, indicate failure
					SendByte(NAK);
				}
			}
			else
			{
				filetype = 0;
				// number not acceptable
				SendByte(NAK);
			}

			break;
		case 'E' : 	// begin sending current file contents to controller
				if (filefound == 1)
					myInputFile = FSfopen(rec.filename, "r"); // open the file
				else
					SendByte(NAK);
			break;
		case 'N' : 	// send next (or subsequent) filename for filespec given in N command
				if (FindNext(&rec) == 0) // yes, there's another
				{
					filefound = 1;
					SendByte(ACK); // success , got a name
					SendBufferedString(rec.filename);
				}
				else // no more? then tell Mill Controller so.
				{
					filefound = 0;
					SendByte(NAK);
				}
			break;
	}
}

As you will see from the above, everything is kept simple and brevity is considered virtuous. I’ve left my comment field intact on the above which describes examples of use. Note that only 3 ‘commands’ are needed or used by the Mill Controller:
‘D’ followed by a group number 1,2 or 3 asks for the ‘directory’ listing of the group specified. (starting with the 1st file found)
‘N’ tells the file system to send the next filename in the group.
‘E’ tells the file system to send the contents of the file, line by line.
You can quickly relate the lettered commands to the function numbers given in the table above.

A discussion of the gcode interpreter itself will cover the Mill Controller aspects of commanding the filesystem, and this will form a later post.

With acknowledgements to Elektor Magazine and Thomas Fischl, for the application, and warm thanks to Gert Bouland for his kind support in providing ready-built hardware.

Links. The Elektor article on the USB Data Logger can be found here: http://www.elektor.com/magazines/2011/december/usb-data-logger.1992177.lynkx

Updated 15th April 2012 File System Project & Source-Code & example of logging are here: http://joebrown.org.uk/images/MillTable/MillFS_15_04_2012.zip and here: http://joebrown.org.uk/images/MillTable/LOGGING_15_02-2012.TXT

Print This Post

Google – Stop f***ing asking for my mobile number when I sign in to GMail

No, you aren’t getting my Mobile number.

If you persist in asking me – I will close my gmail account.

Print This Post

Converting a Proxxon MF70 Milling Machine To CNC – 3

Controlling the MF70 Spindle Speed

Updated 28th April 2012 with Eagle Schematic and Printed Circuit Board Design.

This post in one in a series. Other posts you may be interested in are as follows:

I’ve already mentioned that I’ve attempted to automate as much as is possible, so as to avoid tedium and the inevitable problems with repeatability when human intervention is involved. It would be useful to define required Tool speed alongside the tool definitions, so that when a tool is selected by gcode, the speed suited to the tool and work is automatically selected and implemented.

Hardware

The MF70 comes equipped with speed control based, to put it bluntly, on a lamp dimmer. As a picture is always worth at least a thousand words, I’ve included my impression of the MF70 speed controller in the schematic below.

Author's impression of Proxxon MF70 Speed Controller

The circuit is ubiquitous, but I’ll glance over the operation.
Control over the firing angle of the TRIAC is managed by the 500K pot, together with the associated capacitors, assisted by the DIAC, hence altering the effective voltage across the bridge rectifier which supplies power to the DC brushed motor. The circuit is popular because it is cheap, and relatively problem free, the only mechanical component being the 500K pot.
Proxxon have marked the dial on the speed control knob in a range from 5000 to 20000 rpm. I have not checked this, but indications are that though a little rough, the calibration is adequate, given that the control over speed using a pot in this way is not linear, with greater incremental increases in speed as the knob is rotated clockwise.

Given my very healthy respect of mains-level voltages, and un-isolated ones in particular, I originally intended leaving things exactly as they are, and affixing a geared model-control servo motor to the side of the motor casing. I subsequently decided that this would end up as a mechanical monstrosity, which was difficult to keep free of metal swarf, and promising myself to be ultra careful, decided on interfacing directly with the electronics of the motor controller itself.

I haven’t ‘played’ with TRIACS in any serious sense, my experience pre-programming days was solely with Thyristors, so some time has been spent reading Application Notes. Not much has changed though, and the simple requisites for phase control are the determining of the zero-cross point in the AC supply, and the production of a GATE_ON signal after a pre-determined delay, depending on speed required.
Below, the Blue trace shows the zero-crossing pulse, (note that this occurs every 10ms here in the UK, where we have a 50Hz supply) whilst in red the ACTIVE LOW Triac control signal is shown, well delayed until just over 8ms after zero-crossing. The reason why the Triac control signal is ACTIVE LOW will become apparent in the next schematic.

Phase Control of Proxxon Motor @ approx 5000rpm

Now contrast the above oscillogram with that below taken at a speed of 20,000 rpm.
Here, the ACTIVE LOW Triac control signal is triggered at around 5ms after zero-crossing, thereby turning the triac on much longer, hence delivering more power to the motor.

Phase Control of Proxxon Motor @ approx 20,000 rpm

As well as controlling the speed of the motor, our additions should cater for turning the spindle motor on and off, as well as allowing for original manual control, and probably most important, shutting off spindle motor power when the BIG RED SWITCH is hit by the user, as mentioned in the 1st post on this subject.
Last, but most certainly not least, control signals should be isolated from the mains voltages on the existing speed-control board.

So a shortlist of requirements so far:

Detection of zero-crossing of the AC supply.
Generation and provision of the TRIAC gate signal.
Emergency shut-down.
Provision for manual control.
Complete isolation of mains-connected electronics from controlling electronics.

I came up with the following:

Proxxon MF70 Milling Machine Automated Speed Controller

Don’t be put off by the apparent complexity of the above – look at each part individually.

First, the ‘original’ speed controller is retained on the right of the diagram, with only 3 small changes:

1. The connection between the DIAC and TRIAC has been severed, and flying connections taken to contacts on RELAY 2.
2. A flying lead has been added to A2 of the TRIAC, which connects to resistor R6.
3. A flying lead has been added to A1 of the TRIAC, which connects to capacitor C7.

A phase-control signal PHASE_CONTROL supplies ACTIVE LOW pulses to the opto-isolated TRIAC MOC3020, whose supply and snubber are connected as mentioned in (2) above, and whose output is taken from pin 4, via RELAY 2, to the TRIAC, whenever RELAY 2 is activated.

A zero-crossing detector circuit comprises R9, BR2, a zener diode, R10, LED2, C7, R11 and a 6N137. This generates a positive-going pulse every 10ms, ZERO_CROSS, which is opto-isolated from the mains supply.

A spindle motor ON/OFF circuit is comprised of Q1, D1 and RELAY 1. An ACTIVE HIGH on MOTOR_ON, will turn on the spindle motor if the Manual/Automatic switch (top-left of schematic) is set to ‘Automatic’.

Most importantly, the ‘Controlled 5V+’ supply comes from the ‘+5V supply to motors’ shown on the BIG RED SWITCH diagram in 1st post of this series. This ensures that when the user hits the ‘PANIC’ switch, not only will the X, Y and Z stepper motor supplies be cut, but the spindle motor will also be deprived of power.

Note I’ve shown the relays in their ‘de-activated’ state, which would be so if the Manual/Automatic switch was set to ‘Manual’, or the user has hit the PANIC button. In this state, the original Speed controller can be used, switching on the supply using the original (and retained) switch.

A suitable printed circuit design in Eagle is now available. Component & foil sides look like this:

MF70 Spindle Control from PIC Microcontroller - Component Side

MF70 Spindle Control from PIC Microcontroller - Foil Side

Software

As mentioned above, the relationship in AC control, between time and speed is not linear, and I had no wish to make exact, and complex calculations in software. Instead I decided on allowing the use of the ‘S’ gcode to select spindle RPM to the nearest 1000, in a range 1000 to 20,000 – a little better than the 5000 to 20,000 allowed by the original controller. The plan is to parse the input speed gcode, then divide this by 1000, to give an index into a look-up table containg effective phase-delays (TMR0 counts), the contents of which could later be tweaked with the use of a tachometer.

So the look-up table will look similar to this:


const rom unsigned int phaseval[] = {20000,21000,22000,23000,24100,24450,24750,25000,26000,26750,27500,28000,28500,29000,29500,30000,32000,35000,38000,41000};

G-code speed parsing like this:


		if (gcode.present & GCODE_S)
		{
			int temp;
			// accept 1000 - 20,000
			// convert to 1 - 20
			// and look up tmr0reload in table
			// rough? yes, but later, calibrate with tachometer
			temp = gcode.S / 1000;
			if (temp > 0 && temp < 21)
			{
				temp = phaseval[temp-1];
				// tmr0reload is volatile so disable interrupts
				INTCONbits.GIEL = 0; // low priority/peripheral ints
				INTCONbits.GIEH = 0; // enable high priority ints

				tmr0reload = temp;

				// re-enable interrupts
				INTCONbits.GIEL = 1; // low priority/peripheral ints
				INTCONbits.GIEH = 1; // enable high priority ints
			}
		}

And the interrupt system which processes the zero-cross signal and generates the PHASE_CONTROL signal:


InterruptHandlerHigh ()
{
	if ( INTCONbits.INT0IE == 1 && INTCONbits.INT0IF == 1)		// test for RB0 edge interrupt - ZERO-CROSSING
	{
		// clear INT0 interrupt flag
		INTCONbits.INT0IF = 0;

		PORTBbits.RB1 = 1; // drive phase control HIGH (OFF)

		TMR0H = tmr0reload >> 8;
		TMR0L = tmr0reload & 0xff; // reload TMR0

		INTCONbits.T0IF = 0; // clear TMR0 interrupt flag.
		INTCONbits.T0IE = 1; // enable TMR0 interrupt
	}

        // TMR0 interrupt
        if (INTCONbits.TMR0IE == 1 && INTCONbits.TMR0IF == 1) // test T0 rollover
	{
		INTCONbits.TMR0IF = 0; // clear TMR0 interrupt flag
		INTCONbits.T0IE = 0; // disable TMR0 interrupt

		PORTBbits.RB1 = 0; // turn phase contol ON
	}
.
.
.

A photo album exists showing my experiments in the development of the prototype speed controller. This can be viewed here: http://cullercoats.joebrown.org.uk/#53.22
I’ve also embedded a Shockwave viewer of the album below. The photos are best viewed full-screen.

Datasheet/Application Notes. I have provided copies of the following PDF documents for your convenience:
6N137 – opto-coupled Schottky Transistor
Opto-coupled TRIAC MOC3020

Suppliers: Everything I used here was available at my local friendly Electronics Store ESR. The relays were actually 6volt units – they run quite happily on 5volts.

Update 28th April 2012
The Eagle schematic and board files are here: http://joebrown.org.uk/images/MillTable/SpindleControl.sch and here: http://joebrown.org.uk/images/MillTable/SpindleControl.brd

Print This Post

Converting a Proxxon MF70 Milling Machine To CNC – 2

The User Interface

This post in one in a series. Other posts you may be interested in are as follows:

My layout is shown below. It may not be as intuitive or informative as the layout on a PC display, but contains everything I have found necessary for control of the Mill. (and previously the DRO’s on my other Milling Machine and Lathe.)
I should stress here, that this is an overlay – i.e. a plastic-faced, easy-to-clean front which has a cut-out for the LCD display on the left, space for ON/OFF switches and Edge-detection LED below that, and on the right, covers over a set of TACT switch buttons, which protrude slightly through the container front.
It is cheap and easy to make. (I laminate mine after printing the design on paper) It is also easy to change, should you want to alter the colours, wording, and even position of the legend, after changing the switch layout. (and detection in software if necessary) First and foremost then, it is adaptable.

Let me now describe briefly how the above is used to control the Mill functions.

Jogging an axis. Any axis can be jogged a pre-determined distance (number of stepper-steps) in both directions of travel. For a single jog, the relevant jog key is depressed and released, and for continuous jogging, a press-release then press and hold. The jog keys are the and on the same line as the axis you wish to jog.
Setting Absolute Zero for an axis. This is a common operation, and so has been made as easy as possible. First of all the pad is pressed, then the axis , , or , is required. You then have a choice of methods you can employ to set the zero:
1. Press again, to select the current position of the axis you have selected as the new Absolute Zero. Or:
2. Start entering a decimal value using the numeric keys, (optionally preceded by) an optional decimal point at any position, and complete entry of the number by pressing the pad. Or:
3. Press the axis key again to select setting the absolute zero by edge-detection. Then using the and pads co-responding to the axis you are setting, jog the axis until the tool hits the work. A flashing ‘E‘ will be displayed alongside the relevant axis display on the LCD, until the edge is found. The tool will auto-retract when an edge is detected, and the position at which the edge was detected will be stored as the Absolute Zero for that axis.
Setting a preset value for an axis. This is also a common operation. First of all the axis for which we want to set a preset is pressed: , , or . You are then invited to select a preset number 0-9. When this is done, you then have a choice of methods you can employ to set the preset value:
1. Press to select the current position of the axis you have selected as the new preset value. Or:
2. Start entering a decimal value using the numeric keys, (optionally preceded by) an optional decimal point at any position, and complete entry of the number by pressing the pad. Or:
3. Press the axis key again to select setting the preset value by edge-detection. Then using the and pads co-responding to the axis you are setting, jog the axis until the tool hits the work. A flashing ‘E‘ will be displayed alongside the relevant axis display on the LCD, until the edge is found. The tool will auto-retract when an edge is detected, and the position at which the edge was detected will be stored as the selected preset value for that axis.
Selects between the use of Absolute and Incremental co-ordinate values.
Selects between the use of Imperial (inches) and Metric (mm) method of measurement.
Is used to clear a number, or cancel an operation if one is in progress.
Is the multi-purpose entry key for a wide variety of operations and data entry. This will be discussed later, with each function detailed in a table.

Implementation

Currently, and as has been briefly mentioned above, the keypad is implemented as a matrix of low-cost, but robust, TACT switches. The rows of which are driven low in turn, by 4 outputs from PORT D of the PIC Micro-controller. The values of each column is tested in turn by 5 inputs on PORT A of the PIC Microcontroller.
Schematics of the keypad and controller board are given below:

MillTable Keypad Matrix Schematic

Mill Table Controller Schematic using PIC18F4620

Worth mentioning here, is that the ‘gaps’ on the 1st column of the keypad schematic, can be regarded as ‘phantom’ keys. Use of this is made in implementing the edge-finder, which occupies the ’slot’ immediately above S20 on the keypad schematic, and is thus activated by RD5 and detected on RA0. Special code is executed every time the keypad is scanned, to test this location 1st, and it therefore takes priority over every other key.

Print This Post

Converting a Proxxon MF70 Milling Machine To CNC – 1

Overview

This post in one in a series. Other posts you may be interested in are as follows:

This project has been driven by a desire to free myself from the lengthy, expensive, fiddly, and extremely dirty, business of producing printed circuit boards. (PCBs)
The name, and it’s acronym have already become a misnomer in forward-thinking British Schools and elsewhere, where the production of circuit boards is being done by a wholly mechanical process, rather then photography and etching with acid. This process has been given the title ‘isolation routing‘, and the waste product – a mixture of copper and circuit board substrate – be it SRBP or fibreglass, is far easier to reclaim and recycle than the disgusting result of etching copper with Ferric Chloride solution, or it’s even more noxious alternatives. As important is the question of quality and repeatability – readers of my posts may remember several occasions when I complain that my home-made circuit boards do not live up to expectations, especially in winter when my ‘chemical’ lab (a walled-off section of my garage) is cold.

There were several constraints on my project, not the least of which was cost. I could not afford a CNC milling machine capable of the accuracy required, nor lash-out on expensive suites of software to drive proprietory drivers.
Secondly, I do not want a PC in my workshop, they are a liability, prone to crashing, and limit choices too much.
Thirdly, I wanted to make use of software tools I already have, in my case the Eagle Editor, plus tools that as well as tried and tested, were available free on the Web.

My modus-operandi is relatively straight forward:

Select a small, reasonably-priced Milling machine and convert it to CNC i.e fit stepper-motors to each of the axes X, Y and Z.
Design and construct MOSFET driver boards for the stepper motors using readily-available and reasonably-priced components.
Design and construct a controller-board that accepts as it’s input a text-file containing G-Code instructions, and which generates control signals to the stepper-drivers as it’s output.
Use Eagle as my circuit-board design tool, and use the plug-in ‘pcb-gcode.ulp’ to convert the Eagle files into G-Code drill and routing files.

Note that there’s nothing particularly novel about my list above, all of these things have been done before. Further, almost each of the stages mentioned can be substituted by the purchase of a commercial equivalent.

Difficulty and Facilities
Anyone contemplating treading a similar path to mine will probably wish to avail themselves of the short-cuts a commercial offering might bring, due either to their lack of facilities or feeling that their skill-set precludes parts of the path I have chosen.
I have to be honest here. I have a well-equipped engineering workshop (my garage has no room for a car anymore). It will be possible to do the mechanical conversion of the MF70 to CNC without the use of a lathe, but more difficult.
The electronics, though relatively trivial, needs to be produced to a reasonable standard – after all, it will be driving machinery. So you must be able to solder correctly, and follow a circuit diagram and printed-circuit layout.
What you don’t need, is any software-engineering skills, though if you did, these would be useful for customising the code.
Oh yes, you will need to brush-up on your understanding of g-codes, as you will probably want to edit in some small way, the files produced after running pcb-gcode.ulp in Eagle.

It would be useful to point out that this post is only the first of many on this topic. I will attempt in this post and all others that follow, to explain everything I’ve done, so please be patient. Email requests for information not yet presented may be politely ignored, though comments and queries on what has already been presented are welcome. There is a photo album which will be updated from time to time, and this can be found here: http://cullercoats.joebrown.org.uk/#49.81
so that your question(s) may be answered by referring to it. A Shockwave viewer to the album is embedded below. Photos are best viewed full screen.

A Photo Album documenting the experiments whilst developing the Spindle Speed Controller is also available here: http://cullercoats.joebrown.org.uk/#53.22, and a Shockwave viewer to this album is embedded below.

Mission Impossible?

“Good morning, Mr. Phelps. Your mission, Jim, should you choose to accept it..”

The art of the possible is to break down a complex task into it’s constituent parts, analyse these, deciding on inputs and outputs from each task, and devising a solution to attain this. So as a taster, let’s look at what we have to deal with as an output of the circuit-board design process:

High-Voltage Op-Amp PCB

High-Voltage Op-Amp Board - drill layout only

For my example, consider only the drilling process of the holes shown on the rightmost picture above.
Running pcb-gcode.ulp in The Eagle editor will produce some files, in amongst which is the drill file – containing a list of g-code instructions to perform the drilling operation. The file isn’t very big, but even so, I’ll list only the 1st part of it which shows all relevant g-code content we need to process.


N01 ( This gcode generated by C:/Program Files/EAGLE-4.16r2/ulp/pcb-gcode.ulp )
N02 ( Copyright 2005 by John Johnson. See readme.txt for licensing terms. )
N03
N04 ( This file generated from the board C:/Program Files/EAGLE-4.16r2/projects/Line mixer/HV_OpAmp_Discr.brd )
N05 ( This file generated 12/03/2012 07:02:59  )
N06
N07 ( T01 0.600000 )
N08 ( T02 0.812800 )
N09 ( T03 1.016000 )

N10 G21
N11
N12 G90

N13 M05
N14 G00 X139.7000 Y86.3600 Z193.0400
N15 M06 T01  ; 0.6000
N16 G00 Z0.5080
N17 M03
N18 G04 P3.000000

N19 G00 Z0.508000
N20 G00 X-11.1125 Y94.2975
N21 G01 Z-3.0480 F127.00
N22 G01 Z0.508000
N23 (R0.5080  P10.000000)
N24 (G00 Z0.508000)

N25 G00 X-16.1925 Y86.3600
N26 G01 Z-3.048000
N27 G01 Z0.508000
N28 (G00 Z0.508000)

N29 G00 X-20.3200 Y93.9800
N30 G01 Z-3.048000
N31 G01 Z0.508000

N32 M05
N33 G00 X139.7000 Y86.3600 Z193.0400
N34 M06 T02  ; 0.8128
N35 G00 Z0.5080
N36 M03
N37 G04 P3.000000
N38 G00 Z0.508000

N39 G00 X-10.1600 Y85.0900
N40 G01 Z-3.0480 F127.00
N41 G01 Z0.508000
N42 (R0.5080  P10.000000)
N43 (G00 Z0.508000)

N44 G00 X-10.1600 Y92.7100
N45 G01 Z-3.048000
N46 G01 Z0.508000
N47 (G00 Z0.508000)

N48 G00 X-12.7000 Y85.0900
N49 G01 Z-3.048000
N50 G01 Z0.508000
N51 (G00 Z0.508000)

N52 G00 X-12.7000 Y92.7100
N53 G01 Z-3.048000
N54 G01 Z0.508000
N55 (G00 Z0.508000)

I’ve added line numbers to the original file, so that I can refer to these in what follows. I have also broken the text in to meaningful chunks, each chunk performing a discrete mini-task.
I’ll briefly discuss some of the above, leaving the reader to fathom the remainder, using a good g-code reference. In the following, please ignore the bracketed code in the text.

First of all, two aspects of the above may have occurred to you as a little strange, the first being that some of the X-coordinates are negative, the other that the Y-coordinates have a large offset applied to them.
The first phenomenon results from Eagle insisting that my board is drawn upside down – and yes it is, my track is on the ‘top’ of the board. The second is easy, in my layout I cropped the board from it’s original Euro-card size to the top left corner, rather than the bottom left. (mea culpa) This will be clearly seen if you load my board into your Eagle Editor.

N13 thru N18 represent a tool-change sequence – a set of instructions to the controller to effect the loading of a tool – tool number 1 in this case.
The M05 instruction on line N13 tells the controller to switch off the spindle motor
The G00 instruction on line N14, instructs the controller to move the axes to the X, Y and Z positions given, so as to effect easy change of the tool.
On line N15, the M06 instruction, followed by the tool identity T01 indicates that the controller should load Tool 1, in this case a drill 0.6mm in diameter.
Line N16, a G00 instruction tells the controller to lower the tool to a position 0.508mm above zero, where zero is the surface of the workpiece.
The M03 instruction, on line N17, tells the controller to switch the spindle back on.
On line N18, the G04, followed by a pause period P3.0, tells the controller to wait. (until motor comes up to speed)

The above sequence will be repeated every time a tool change is required.

Now following the above, there is a drilling operation:

On line N19, the Z-axis is lowered to 0.508mm above zero – yes, this is probably superfluous, but I didn’t write/produce this code!
The G00 instruction on line N20, tells the controller to move to the position X-11.1125, Y94.2975.
Line N21 is the drilling operation. G01 instructs the controller to lower the tool into the work for a distance of 3.048mm, at the specified feed-rate of 127mm per minute.
When this is complete, line N22 instructs the controller to raise the tool back to 0.508mm.

The above action is repeated for each hole required in the board, with tool-changes when hole diameter changes.
The codes I have emboldened above, plus one or two more for setting absolute/incremental mode, and dimensional units inches/millimeters, are all that are required to drill a board.
I am not intending to provide a reference here, so you should discover for yourself exactly what is meant by the above-used codes, paying particular attention to the difference between G00 and G01.

At this point, a good exercise would be to load up the small HV_OpAmp project, and viewing the board, cursor around the design comparing the coordinates with those given in the drill file above.
Downloads
I’ve copied the HV_OpAmp board and schematic files here: http://joebrown.org.uk/images/MillTable/HV_OpAmp_Discr.brd
and here: http://joebrown.org.uk/images/MillTable/HV_OpAmp_Discr.sch
Also a copy of the drill file produced by pcb-gcode.ulp here: http://joebrown.org.uk/images/MillTable/HV_OpAmp_Discrbd.nc
Links
The pcb-gcode.ulp software is available here: http://pcbgcode.org/list.php?12
One example of sites dedicated to PCB Isolation Routing: http://www.brusselsprout.org/PCB-Routing/

Reality – a hard or soft landing?

In the above I refer to the controller at almost every other phrase. Put simply, this chap/gal/entity is an ideal controller – one who will interpret and carry out the instructions given in an safe, precise and expeditious manner, in other words carry out the operations in both spirit and substance.

Of course in the real world, there will be some instructions which cannot be carried out by the machine, without some human intervention, so that our controller refers to the machine/man meld.
In practical terms then, the controller will actually be somewhere between simply a human automaton, sitting in front of a manual milling machine equipped with DRO, reading the above file, and twiddlling the knobs, to a fully-blown automatic monster, in which every operation is fully automated.
My project aims for as much automation as is possible, given the constraints discussed above. On the MF70 CNC conversion discussed, the only operation in which there will be human interaction, once a g-code file execution is taking place, will be in the tool-change process, and this will be made as simple as unloading the current tool and fitting the one indicated.

So the execution of g-codes is conditional on the facilities available on the system running them, but there are also other matters to consider. Taking the apparently simple instruction of turning on the spindle motor, M03 in the above code. How fast should we run the motor at?
If the spindle motor will only run at one speed on your machine, then do you really care? As an engineer though, you should be matching the spindle speed to that required for correct operation with the tool diameter, and the material you are cutting – anything less will lead to less-than-perfect results.
So satisfactory execution of your g-code will rely on your correctly pre-programmed information taking regard of these parameters.

Again, I have tried to program as much facility into the controller to automagically select the correct speed, given tool diameter and materials, but bear in mind that the first (and currently only) aim of the project is the small-scale production of circuit boards. Source-code will be available for those who wish to extend and/or modify any functionality.

Command, Control, & Safety

Before beginning this project I trawled the Web for ideas. In most of the home-brew designs offered, it appears to be expected that the human be a constant spectator to milling operations, ready to intervene when ’something goes wrong’. The designs offer very little in the way of elementary protection against the self-destruction of stepper-motors for example. This project implements limit-sensing and also edge-sensing as aids to safety and security. The edge-sensing should be considered an essential, as without it, tool-changing will be boring and tiresome.

Stepper Control

Control of each of the stepper motors is via a MOSFET driver board, Parking & Sense Board and ancilliary wiring. Although these items are separate, they should nevertheless be considered together as an aid to understanding.

MOSFET Stepper Driver V2.00	There is really not much to say about this circuit. It simply converts the TTL voltage-levels from PIC controller, into a high-current drive for each of the 4 phases of a stepper motor. Requirements of each MOSFET are a very low R_DS, and a Gate-Source turn-on voltage of less than 4.5volts.
Stepper Wiring	The 4 phases from the board above should be connected to the corresponding inputs here. GND is self-explanatory, but Sense, Normal & Park have the following significance. Sense should be regarded as an output from the wiring, and reflects the state of the 5volt supply to the motor. This is taken to a sampling node on the Parking Sense wiring shown below. Park & Normal are two distinct 5 volt supplies, only one of which will be active at any given time. Both these lines are output from relay contacts on the Parking/Sense wiring below. The two micro-switches form the limit switches on each axis e.g. Left & Right on the X-axis.It will be seen the the ‘Normal’ supply is made available to the motor, when these switches are not activated, and the ‘Park‘ supply when one or other of the switches are activated i.e. at the limit-of-travel of an axis. A fuse protects the motor windings from stall currents.
Parking & Sense Wiring	Under default conditions, the line PARK_ON from the PIC controller is LOW, so that the MOSFET is switched OFF, and hence the relay is de-energised. Motor supply in these circumstances is available via NORMAL. Consider the following scenario: One of the limit-switches on the above wiring has been activated. We can follow the path of the 5volt supply from it’s source on this wiring, via the ‘NORMAL’ route and discover it broken by the activated switch. ‘SENSE‘ will fall to zero volts. This negative-going signal is filtered by R3 and R4 and given to a control pin on the PIC Controller via /LIMIT. What happens next, depends on what the context of the operation being carried out was. Most importantly it is worth noting that if the controller took no action, power has been removed from the motor, so it will not stall when a limit is reached. Special provision is made here for the case where an axis has been ‘deliberately’ driven to a limit – such as a parking position. Should it be pertinent, the PIC will activate the PARK_ON line to the small MOSFET relay-driver, hence switching the 5volt supply to PARK. Referring back to the stepper wiring above, there is now a path via the activated limit-switch and control of the situation is re-asserted by the controller software.
Edge Finder Wiring	Although very important in enabling the automation of tool height measurement, and lateral position with respect to the work, the Edge Finder has an important safety and protection role also. Attempting to drive a tool downwards through work whilst the spindle is not revolving will inevitably result in the tool shattering and/or the Z-axis stepper stalling, or worse – both. The thought of high-speed steel tool fragments flying about is not one to be taken lightly, and should be avoided at all costs. A simple interlock between spindle on/off and the edge finder should proscribe against such an event happening. The MF70 motor housing is earthed, so that the tool-tip will also be earthed, whilst the table is isolated i.e. currently not connected to anything. Conveniently then, using the arrangement on the left, we can arrange for the opto-isolator transistor to turn ON, when the tool tip touches the Mill Table and/or work.
Motor Supply Master Switching	There is no doubt that the ability to quickly, and with minimal force or dexterity, break the supply voltage to a motor, has saved many a limb, if not life. Even though the forces available are pipsqueak compared to a standard Mill or Lathe, I strongly advise the fitting of some form of PANIC button, one that is easy to find, and requires just a touch to activate. The POWER ON button, by contrast, should have minimum profile, and require reasonable force to activate. Here I have shown the simple scheme I use. A small micro-switch acts as the PANIC button, its actuator being a large red knob, conveniently sited, whilst the ON switch is a standard low-cost, low profile indented push-button. If control of the motor-supply is to be implemented, then the 5V output from this circuit should form an OFF function for this also. I discuss control of the MF70 motor unit at a later date.

To be continued
This post, and the several to follow, will be edited and amended as I make further information ready for publishing.

Pages

Applications

Blogettes

bottom-feeders

Connectablogs

Database design

Electric Guitar Projects

Electronics

Every Picture Tells A Story

IB50 - Bureaucratic Bullshit

Leslie Speaker Emulation

Letters, Read Just One Last Time

Living with DISH (D.I.S.H)

MIDI

Music

MySQL

Other Links

PIC Microcontrollers

Popular Music

Post-Economic Meltdown

Printed Circuit Board Isolation Routing

Proxxon MF70 CNC Conversion

Radio Amateur

Remedies For Troubled Souls

Retro Gear

Sister Site Links

SMD

Songs For Broken Voices

Stories

Svetlana

The Occasional Diarist

Workshop

Categories

A Simple Thumb Drive G-Code Delivery System

No, you aren’t getting my Mobile number.

If you persist in asking me – I will close my gmail account.

Controlling the MF70 Spindle Speed

The User Interface

Implementation

Overview

Mission Impossible?

Command, Control, & Safety

Translate It!

Music To Have Your Teeth Out By

Stories

Bipolar - Helpful Links

The Occasional Diarist

Categories

Archives

Electronics

MIDI

PIC Microcontrollers

bottom-feeders