OpensourceLasercutterdriver
This Wiki describes the design of a an Open Source laser system. Both the software and hardware are described. The intended audience of this information is fellow designers and potential users of such a product.
Contents |
Goal
Development of an Open Source driver for laser cutters and a matching Mainboard, Firmware and PrinterDriver using existing technology where possible, to:
- Provide an open source solution to control laser cutters and laser markers
- Provide "low entry level" access to laser cutting and marking equipment
- Provide a complete work flow to allow novice users to use the tools and make stuff without having to know the intricate details of format conversions or laser process and machine particularities
- Standardize the hardware and file formats used, in order to simplify the exchange of designs
- Tap in to the infinite pool of bright minds and allow them to participate in the creation of new ideas and products based on this technology.
Rationale
The development of the reprap and other open-source 3D printers has made 3D printing affordable for the masses. It triggered a development spur that produced various new technologies and products. While theoretically almost any 3D shape can be manufactured by an additive process like 3D printing (or optical 3D lithography) there are many shapes that may be better created using subtractive techniques like turning, milling, or cutting. For one: The original material properties are not compromised in the final product, and there is a larger selection of materials (polymers, cardboard, wood, metals, etc.). Laser cutting is a relatively simple technology that allows one to create accurate structural elements from sheets, with a typical thickness of 0.1 to 10 mm (thinner and thicker possible with some materials and lasers). Sheets can be stacked, or assembled in 3D to make anything from a coat hanger to full size cars. This makes this tool a makers must have!.
Typically, (CO2) laser cutters cost 10 to 100 K$ and are not accessible to the average user. Cheap CO2 laser cutters are available (from China) in the 1 to 5 K$ range but they often hampered by software limitations and limited flexibility.
This project is even more ambitious and drop the price even lower and make laser cutters and markers available in the 100 to 1000$ range (YMMV) depending on the laser used, and the parts you may be able to rescue from the local scrap-heap.
Background
This project was started with the coincidence of Peter Brier meeting Jaap Vermaas on the DDW 2010 festival in Eindhoven, and having a old industrial marking laser available (rescued from the scrapheap). Jaap runs a mobile [fablab] and has various tools (including a 3D printer and professional laser cutter) in his lab. Fueled by the experience of various other fablabs with their laser tools he came up with the idea to upgrade these with new hard and software, and have something to make the marking laser do something usefull. I (Peter) have over 10 years of professional experience in the design of Laser and Inkjet printing equipment, so we discussed the idea over a cup of coffee when Jaap picked up the industrial laser in Eindhoven. There was interest from the [ProtoSpace] fablab, that owns a number of laser cutters. They where kind enough to host us. Siert and Jelle from protospace joined our efforts. They own a laser system that is up for a Brain Transplant. This became our ProtoSystem.
General requirements
- The hard and software should be based on open-source tools and existing designs as much as possible.
- It should behave like a network printer. Independent of the operating system (windows, Linux, Mac)
- It should "just work". The average user should be able to use the system like an ordinary printer and print his designs.
- Be able to work "stand alone", independent of the controlling computer.
Design Choices and Proposed workflow
Any drawing program
Any drawing program (which in Open Source terms means we test with Inkscape and GIMP) should be able to issue a print command. We don't want to change the program, neither do we want to design laser cutter-plugins to print from specific programs. But any program will have a print dialog already. So, we need to handle output to the laser as if it was send to a printer.
Linux and Mac OS use CUPS for their communication with printers. A PPD file defines the printer and it's possibilities. Windows understands the PPD format, using the CUPS for windows driver.
Configuration for cutting should be set in the printer dialog (advanced tab) options for your printer device.
Postscript as input
Use Postscript as the input format, augmented with additional (pre-configured) data that defines the equipment and material characteristics. There are many tools to generate postscript, and most operating systems provice a "generic postscript printer driver". Postscript can contain bitmap and vector data.
Interpreting a postscript file is not trivial (it is a complete programming language), but fortunately there are tools available for this task. Most noteably "Ghostscript". This includes a complete Postscript language interpreter and can have various back-ends to display or export the image. It's usual task is to render the postscript image on some (bitmap) canvas. It is possible to write driver inside Ghostscript to format the data in the appropriate format for our laser. However, there is another approach, that has been implemented by the pstoedit tool. This is to redefine the basic operators inside the postscript language (The Postscript language allows the program to alter the language!), execute the altered Postscript program via Ghostscript and have these new operators export the primitives to a file (lines, curves, bitmaps). pstoedit has various drivers to process these files and export them in various formats (G-code, SVG, DXF). The interface to the driver back end of pstoedit is rather straightforward (using C++), and one does not need to compile a large body of code (like Ghostscript). The standard Ghostscript version for your platform is used.
Communication based on standard protocols
The final system should operate "just like a printer". So we opt for the usual methods of transferring data to a printer: a socket on the "LPR" port (515). This receives the Postscript file and prints it. All the process related settings are in the postscript file. System related settings (e.g. maximum size, speed, etc.) may be in separate configuration file, or embedded as fixed values in the PPD file.
Use "standard" 32-bit microcontrollers (like the ARM7, ARM Cortex)
These are low cost and have sufficient resources (typical 50 to 100MHz, > 64k RAM/ROM, Ethernet, CAN, I2C, etc). There is a standard GCC compiler available. The usual 8-bit [arduino] used for 3D printers may not cut it in terms of processing and communication power when we send data to a fast scanning laser. The controller can be embedded in the equipment, and drive the motors, control the laser and peripheral devices, while communicating with the computer via Ethernet.
Note: The microcontroller is not sufficiently equipped to run postscript interpreter. This requires an embedded computer with at least 16mbyte RAM/ROM and considerable power (ARM9 or more, e.g. [Embedded Arm boards]). There is additional software on the PC that pre-processes the data for the laser system. This software is platform independent (LINUX, Windows, MAC), and may be installed on a small embedded linux board (PPC, ARM, i86). In this way: the equipment is completely stand-alone, not requiring any host software apart from something that generates postscript. The microcontroller may have local storage (USB or SD flash card) to store and replay designs. They are stored in "native" format, not postscript. For realy high speed laser scanning (> 10kHz, >1 m/sec) an FPGA may be required to correctly stream and time the data. This is outside the scope of this project.
Proposed workflow
- Any program sends drawing + laser cut settings (via ppd) to CUPS.
- Cups driver translates ps in vector info and raster info.
- Vector info -> gcode via pstoedit.
- Raster info -> ?? g-code extension 'print bitmap'?
- Vector info -> gcode via pstoedit.
- gcode via http/tcp-ip to queue in printer.
- Printer has control-panel options to choose the file to print and to set top-left origin, manual focus, bounding box(?)
Target system description
There are various possible configuration for LaserSystems.
The initial target system for this laser controller is a 5 to 50 W CO2 laser system, with 2D scanning (fixed focus) mechanics, driven by stepper motors. The system is equally suited for other small gas, diode or DPSS lasers. With some modifications to the control board (e.g. DACS instead of motor drivers) scanning optics systems can be driven with the same controller, although the maximum scanning speed of these systems may not be reached. Beam deflector systems are unlikely to be used in the targeted price range.
The system should be capable of performing all mentioned processes, with different predefined profiles. Selecting the correct profile for different areas of the design can be done using different colors or line widths in the design (to be defined). This will modify the laser speed, power and other parameters (like pulse/CW mode) for these areas.
note: Initial system will only allow to change P,V,F,DPI via PPD settings
Marking should be possible in "raster-scan" (bitmap) mode, where each pixel-location is either marked, or unmarked (binary mode) or optionally in using power modulation (grayscale mode) if the laser provides this. Power modulation may be implemented using PWM or analog (power setpoint) mode, depending on the capabilities of the laser.
The initial system will only provide binary mode (with global power setting, if available). X,Y, DPI and SPEED can be modified.
Some lasers require a "tickle" pulse. This keeps the laser "warm" when no pulses are generated, and provides "quick" startup. If there is an inevitable delay when starting the laser, a "pre-fire" pulse, or pulse-train may be required to prevent gaps to appear at the corners, where line begin and endpoints meet. This is a future enhancement of the system.
Future systems may include a focusing axis (Z) to keep the laser focused on curved surfaces, or to adjust focus automatically when subsequent layers are fused.
The control system should include I/O for additional peripherals (e.g. sensors, actuators, pilot laser, pumps, temperature controllers, shutter, start button, indicators, LCD display, SD card, etc.). The embedded software of the system should be able to control these peripherals independent of the host computer.
It should be easy to field-upgrade the firmware of the controller via USB, or Ethernet (serial connection as fallback scenario).
System Architecture
The initial system consists of an embedded module with a linux based front-end. This front-end can be used as a generic CUPS printer, or from another system (Windows, linux, mac).
