Developing a new Lasercutter Driver

First, you should set up your environment like described in https://github.com/t-oster/VisiCut/wiki/Development:-Getting-started

Then you should read the example driver code in order to understand what steps are needed:

https://github.com/t-oster/LibLaserCut/blob/master/src/com/t_oster/liblasercut/drivers/SampleDriver.java

The general steps to write your own driver are:

• Find out the Connection type of your Lasercutter (Serial,USB,Ethernet). Ethernet es the easiest to implement and to sniff (for protocol identification)
• Identify the protocol your Lasercutter uses. You can try to use serial/parallel or ethernet sniffing tools, look at the software that comes with your cutter or ask the vendor of your device. Common protocols are G-Code and PCL.
• For uncommon protocols, try to find existing source code or (reverse-engineered) documentation. In complicated cases it may help to write a script that decodes the lasercutter file format.
• Use a LibLasercut driver which is nearest to your device as Base. You can look at the source of the drivers here https://github.com/t-oster/LibLaserCut/tree/develop/src/com/t_oster/liblasercut/drivers
• Develop your driver and submit a pull request to get it into VisiCut https://github.com/t-oster/VisiCut/wiki/submit-a-fix-or-feature.

To keep the driver code maintainable, the following checklist is highly recommended:

• Is there is a protocol documentation, reference implementation or similar? Then please add a link in the code. Maybe you even wrote a parser program that can read the lasercutter format? Even better, you can put it in the "utils" directory.
• Check for unused imports, unused variables and similar warnings that are shown in any reasonable Java IDE (NetBeans recommended). Sometimes the warning messages are quite aggressive, so use common sense to judge if a warning is really relevant for code quality.
• Read comments - are they correct or just accidentally copied from somewhere?
• Are difficult parts of the code explained properly?
• Try to avoid commented-out code, better delete it completely.
• Avoid copying code from elsewhere. If you need to copy longer parts, please discuss if there is a possibility for refactoring and reusing.
• println() statements for debugging should at least be commented out, and should be completely removed if they are not interesting. Currently, visicut does not use a special logging facility -- this can be improved in the future to have a special function for debug log messages.
• Have a look at the resulting lasercutter XML file in $HOME/.visicut/devices and check that it does not contain "junk" variables, but only user-adjustable laser properties. It should not contain fixed constants (e.g. DPI_TO_MILLIMETERS conversion factor) or temporary variables (e.g., current position of the laser head). To fix this, change the variable definitions for the fields of your Laser device class:
  • Make constants static final
  • Make temporary variables transient
• implement the saveJob() method so that "save to file" can be used for testing. Check if it works correctly by using VisiCut's "export laser code" menu entry and looking at the file.
  • Then, it is automatically checked that any future change to LibLaserCut will not break your laser driver or change its output for a simple test pattern (see AllDriversTest ). Even if your device does not support reading from file, you can still write a simulated communication to the file so that it can be used for debugging.
• Test your driver for all operations (cut, engrave, engrave3D) and non-standard DPI. For unsupported operations, ignore these and raise a warning message.
• Finally, add your device to the list of supported hardware

While this may look somewhat bureaucratic, please understand that we want to support new drivers forever and not have to drop or rewrite them in the future.