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