I recently bought this piece of rubbish on Ebay: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=130185718374&ssPageName=ADME:X:AAQ:US:1123
It is a 40W CO2 laser engraver which supposedly speaks HPGL. After many hassles (such as the unit constantly resetting itself, and the software unable to control the unit, both solved by replacing the shonky parallel cable supplied with the machine), I have now managed to get it working, but unfortunately, it doesn't work as an HPGL/2 printer, so I can't drive it directly from Windows. This means that I have to use the godawful Moshidraw software that came with it, which, as a CNCZone.com member puts it, is barely a step up above an Etch-a-Sketch. The version that shipped with the unit could not even start (it GPFs trying to access unallocated memory), but I found a slightly newer version at http://iehk.net/download/dl_IE300_01.html. It is still a pretty lousy product, but at least it starts.
What I really want to do with it is cut vectors, unfortunately, the Moshidraw software can only import HPGL files, so importing directly from CAD or drawing packages is out of the question. After some data massaging, I created a sample file in the format it likes, and loaded it as an image into Moshidraw. What happened next is beyond belief:
When Moshidraw imports HPGL files, it does not import them as vectors, instead, it renders it to a bitmap and loads the bitmap. When cutting the file as vectors (as opposed to raster scanning), it then traces (poorly) the bitmap and cuts the resulting vectors!
Of course, this is grossly inaccurate, and the poor tracing routines result in messy output that bears little resemblence to the original.
A couple of others have dealt with this situation by attacking the hardware. One option is to replace the controller with one which recognises step/direction pulses for the stepper motors, and also passes additional IO lines for home/limit switches, and laser control (use a transistor or triac rather than a relay to control it though!). This can then be controlled with Linux EMC or Mach3. Another is to replace the controller with the controller from a pen plotter. Another person has replaced his controller with the control board from a Roland plotter.
I am taking a different approach, and am attacking the software. Moshidraw outputs a restricted subset of HPGL. These are the commands that Moshidraw outputs:
In order to generate a suitably simply HPGL file, I installed a generic HPGL/2 print driver under Windows, and set it to output to a file. The output of that file can then be run through hp2xx to convert it to simplified HPGL. Its not quite right as it uses floasts instead of integers, and sends a lot of PA; commands. Running it through sed removes the unnecessary data.
hp2xx -m hpgl -f- test.prn | sed 's/^SP1;SP0;SP0;SP1;SP1;/IN;VS12;SP1;/; s/PA;//g; s/\.[0-9]*//g;' > output.prn
The result is something that matches Moshidraw's PLT file output.
Unfortunately, it is still not quite enough. Outputting this file to the engraver causes it to reset continuously, as does outputting a PLT file generated by Moshidraw itself! My guess is that there is some scrambling going on. I don't think the PC is bit-bashing the IO lines on the printer port to give step/direction pulses, as the engraver continues to work if it is unplugged during engraving.
My next step is to snoop the printer port on the PC and try to make sense of the results.
3 March 2008 Update:
I have given up trying to snoop the data. The software is accessing the printer port directly, so I am unable to use Portmon to snoop the traffic under Windows XP. I have tried running the software in VMWare, so I can grab the data in Linux, but the software can't see the USB dongle used for copy protection (who would want to spend money copy protecting a steaming pile like Moshidraw I don't know).
I have picked up a 3 Axis CNC control board on Ebay for < USD$100, and have just finished hacking it into my engraver. All I need now is the right cable to connect up the parallel port, and I can use Linux EMC instead! *yay*
24 April 2008 Update:
I had issues with the laser staying permanently on when trying to drive it from the parallel port. As it turns out, the laser expects 0V for on, and +24V or high impedance for off. I built a small transistor switcher to allow the parallel port (0V - 3.3V) to toggle the line between 0V & 24V, and it now works properly. As a bonus, the software can generate a PWM signal for the laser, so I now have power control of the laser. This means you can reduce the laser power as the head slows, so you are always using the same power density.
Some time not much later:
I realised I never finished the story on this one. Having replaced the CNC controller, I was drawing more power than the original PSU could supply, and it promptly gave up the ghost. I ended up replacing the PSU with a laptop power supply, capable of supplying 24V @3.5A.
I also took the opportunity to connect the earth lead of the power lines to the chassis, which resulted in my RCD tripping with some regularity. I noticed that the fase was installed on the neutral line, rather than live (so the machine would still be live if the fuse blew!), and at this point, I decided to redo the 240V wiring in the machine. I stripped out all the thin (like headphone wire!) wiring from the machine, and rewired it using 10A rated cables (actually, gutted IEC cables). After having done all this, the machine finally worked safely and reliably.
13 June 2009:
I used my laser to burn a Darwin Fish into my phone tonight. I probably could have got the alignment a bit better, but everything is there.
16 August 2009
I came across Imajeenyus' site tonight, it looks like he has same good ideas for improving the machine. I'll have to find some time to implement them!