Web interface fun

After a good look at what web frameworks were available for python I came to the conclusion that cherrypy was the est option for what I wanted. Its small and lightweight and easy to work with and doesn't seam to mind too much about the parallel process required to keep the machine well looked after. To generate the pages, I started with Mako but I didn't like the fact that when variable it was expecting wasn't passed to it it would throw an error. Therefore I moved to Jinja2. Much better.

So far  have the basics covered; connecting and disconnecting and initializing the machine, uploading and selecting files and choosing which one to load as well as a simple self updating page that sits in an iframe tag that shows the position of the machine.

So we are getting there...

Well that sounded easier in my head

After much reading up on Django, which is a very nice web framework indeed and I can see why it has taken off, I have found one small problem: Web server are meant to serve many users. Although this is blindingly obvious it does mean the django doesn't like the idea of a process running in the background and then call on it from time to time. I am sure it's possible and i can think of a number of messy ways that might work but I have yet to work out how to do it neatly. I see now why lasaur used bottle. Maybe I'll look at that route....

A slight change of mind.

While I have been fiddeling with pyGTK I have found that debugging can be a bit of a problem as the GTK backend seams to handle errors silently and doesn't like pyscripter breakpoints. Further more, one of the things i want to add later is networkability so you can control your machines using a lan or over Wifi. I have been wondering for a while about how best to do this and then I came across this. And loe and behold that's what they have done. Their system works on the bottle web server and lots of javascript. I think we can go 1 better here and use Django and html5 and then for the icing on the cake, WebGL to provide a 3D representation of the program we are running and the machine it is running on.

There are actually lots of advantages to using a web interface. Its portable across systems, since all you need to use it is a machine with a browser. The user can be any distance from the machine they are using. It can be made to look like any other system with a bit of coding and a css script.

Books have been ordered. Tutorials are being read. Threading code is being rewritten. Soon something good should be produced.

More hardware

Just as I get the CNC router to make it's first movements I found a bloke selling one of those cheepo Chinese lasers engravers on ebay. I thought it was worth a punt as it was an auction and had the potential to go for less than a new one, especially as it was one with a parallel port connection and had a fault that stopped the laser from turning on when the controller told it to. so £500 new, i got mine for £390 inc postage. Woooo!! The fact that it is parallel and the controller didn't work dosen't bother me as I want to put a new controller in it anyway so now I  have yet another project.

I have posted some pics here of my initial investigations. It's not going to be long before someone gets hurt by one of these as they are VERY badly designed, but they do give you all the complex bits of a decent laser engraver so so long as you know what you are doing and modify it correctly it can be made to be safe.

THESE THINGS ARE LETHAL. DO NOT BUY ONE OR FIDDLE WITH THEM IF YOU DON'T KNOW WHAT YOU ARE DOING. IF FACT EVEN IF YOU DO KNOW WHAT YOU ARE DOING IT WOULD STILL BE VERY EASY TO GET SERIOUSLY BURT OR BLINDED OR SET ON FIRE.

Why are they so bad? Well let's see;

1. It's a Class 4 in there and there are no interlocks, no beam tubes, no key switch and no emergency stop button. also missing the big yellow "Class 4 Laser Product" sticker. (admittedly if it had all that stuff it could probably be Class 1 laser product as everything would be enclosed.)
2. The cutting compartment has vents in the sides and holes in the bottom so there is always the chance that a shiny thing could send the beam out one of said holes and set something near by (or not so near by) on fire or blind or burn you.
3. There is no laser supervisor system. A 40W laser needs looking after. You need to make sure the pump hasn't died or a pipe clogged and than the cooling water is actually cold. You need to make sure the power that its drawing is not above the damage threashold. You need to make sure that the flying optics are in flight, if not it will just start a fire (like if the firmware crashes and stops the motors moving but doesn't turn off the laser.) Its also nice to know how long the laser has been on and at what power so you can schedule tube and optics replacements when they come to the end of their life
4. The work area is pathetic. The optics fly over a much larger area than they give you to work in, I can only assume its space to accelerate.
5. The case is massively too big for what's in it. (Although that does mean that there is room for all the things it is missing)
6. The cooling system is a bucket of water and a fountain pump that they have modified with hot glue to fit the pipe they are using.
7. The extractor fan is just a ceiling fan but not a good fan, probably the worst one i have ever seen
8.  Electrically they are abysmal:

• Mains and low voltage wiring not well separated (although better than some I have seen)
• Wires going through burred holes in steel with no grommets,
• No real isolation barrier for the controller
• Front panel controls connected to rectified mains!!
• Laser current meter connected in series with laser, which operates at 22kV!!! (OK, on the low side but if anything goes wrong with that big ceramic ballast resistor...)
• The fan and pump both have American plugs and are designed to run from 240VAC, not a good combo.
• The laser is turned on and off by a 24V signal going to an opto-isolator but that signal goes through a connector with pins right next to the signal pins at rectified mains potential so not that well isolated.
• The laser PSU is built around a TL494 on which they change the current by fiddling with the potential on the timing resistor, very odd.

There are probably a few more things to add but I can't remember them all, it's just that bad. It wont be long before trading standards clamp down on these things which will probably be for the better but hopefully someone will do safe one at a decent price soon (there are these and these but the price is still a bit high)

So what am I going to do?

1.  Interlocks. I like to have anything that can blind me or set me on fire with an invisible and non dispersing ray of light locked away when in use. It's just a good idea. While I am at it, a key switch and stop button.
2. I need to baffle up all the vents so nothing can get out and weld up all the left over holes.
3. The optics need cleaned and aligned.
4. An air assist needs to be installed.
5. A pair of alignment lasers need to be added.
6. A new power supply
7. Rewire everything.
8. Replace the current meter with a hall effect current sensor around an appropriately insulated wire.
9. Replace the twiddly pot for current setting with a dig-ipot and ensure it is opto-isolated from what ever controls it.
10. Opto-isolate the inputs to the laser PSU
11. New control board.
12. Supervisor board.
13. Fit all the cooling in the case. I am thinking of something similar to a liquid cooling system on a computer (laser tube should be dissipating around 300W in heat so should be doable)

After all that is done, then I have for some time wanted to write something similar to this as I have a Cameo and although a little annoying at times and massively bloated the functionality of the software is quite good and some thing like that would be excellent for 2D and 2.5D CNC machining. I have experimented with pygame but the lack of GUI was annoying, and VB but the lack of speed was equally frustrating so hopefully something built in pyGTK will do the job.

Progress thus far

If you think about it a CNC machine is a simple thing. just read the contents of a file, parse the data and execute the commands. Yeh right!!

After reading in the file you need check it for errors and just to be annoying two different dialects of Gcode will consider each others commands as errors, for this reason most machine implement their dialect. Then you have to translate any commands you think you might come across but know that your machine won't accept. then feed those comands to the machine and allow the user to say at any moment "STOP!!" and then maybe "Whoops, my mistake, carry on...." and the problems continue.
Now most programmers will recognize this as the art of programming, but none the less it can be quite down heartening when you find another hole to patch up.

So what have I actually done then?

Well...

For the CNC machine, I have simply plonked and Arduino UNO in the control box and wired it to the stepper drivers and limit switches.  Then I spent a good month of spare time writing C to control it and debugging with a n AVR Dragon (if you cut the little track in the solder jumper just behind the USB socket it works well, but I haven't worked out how to get the chip out of Debug-Wire mode yet)

The basic structure of this code is 3 files; a main code file, a library for working with ring buffers used by the serial port and a file containing all the global variables and #defines. Not the best structure but it works and is quite navigable with code folding. First we initialize everything, then home the axes, then drop into the main loop where we tell the hast we are ready for a line, get that line, then process the M codes and then the G codes. all the serial coms are done with interrupts as is the step timing which uses a timer interrupt to get the steppers to move at the right time.

For the host machine I have been playing with pyGTK. I tied using Glade to design the GUI but when I imported it and run it in pyscripter I couldn't get it to close gracefully so I did it the old fashioned way by defining sizes and position of controls.
 My initial plan was to use a separate thread to be the host controller and handle coms with the machine and let the main thread just keep the GUI alive, however I need to work on my use of Queues and thread control as many of my attempts ended up with the control thread blocking and then still waiting to quit when the app closed. So for now all the coms are handled by a routine called every 100ms  in the GUI. The GUI is also very basic for the moment but there are a few useful methods in the Programme class that can be used to get your machine to do almost anything. Still need to get acceleration done and put some backlash compensation in there but that's for the future.

code produced thus far

Slight change in direction

This project died for a bit while I modified the z axis to be floating. Now that's done I can get back to work.

So since new year i have been working on two aspects of this project

1. Port Rewrite the code for the Arduino in AVR studio.
2. Write a new PC control app in python

The reason for the first action is that Arduino is good but for a project his size the lack of debug capabilities just makes it useless and no code folding means you need to scroll through lots of code to get to the bit you want to read. (the main file over 1200 lines long now) The main stumbling block to this was the Arduino libraries like the ones for the serial port and buffer needed to be rewritten. but that's all done now. I have also changes the data structures that hold all the global variables for the programme. with the removal of a jumper trace I found I could use and Atmel Dragon to debug the code on chip using DeBugWire.

The second action was brought about by the Raspberry Pi. if I write the control app in python then I can put it on a Pi and with a small monitor I have a cheap high powered CAM and GUI on my machine. The latency and timing jitter for a multitasking operating systems makes running the stepper driver straight from the Pi a no starter (a problem I came across years ago when I tried something similar and converted a Boxford Duet controller to a PIC18F4550 and use VB to calculate the steps and timings).  So the best solution is to have the fast computer (Pi) do all the fancy stuff and then just tell the uC (Arduino) what to in terms of lines and arcs and at what speed. this means that the machine need only implement G0,1,2 and 3 as well as a few others and a handful of M codes making the coding much easier and then things like G53 and G54 or G90 or G20 all get dealt with by the python host controller.

So its all getting somewhere and I shall post some pics/code in a few days, all being well.

progress

Right. Whith some more work we now have this:this

improved everything. takes in mesurements in mm and spits out movement.

just need to do some acceleration and give it a good test.