How to get your Hardware Supported By LightBurn

High Level Considerations

• LightBurn supports both Windows and macOS. As such, we strongly prefer that any device support be implemented directly in LightBurn without the use of external, proprietary libraries.
• As a general rule, we do not implement UI changes that are specific to one brand of hardware. As we support a wide variety of hardware types, it is far more important to keep a unified interface that is flexible enough to work with everything.

Hardware Expectations

• LightBurn assumes that any machine has the capability of referencing its axes, whether through homing switches or sensor-less homing. Machines without this capability are not recommended for use with LightBurn.
• LightBurn will not be responsible for monitoring and reacting to safety equipment installed on any machine. It is always safer to have controller firmware respond to these events directly and then throw an error code in the communications response stream, which LightBurn can react to by stopping the stream. LightBurn itself cannot be responsible for the safety of the machine.
• For LightBurn there is a soft limit of 32 layers per job in the UI. We are able, in certain circumstances, to output more than 32 separate layers/cut options if the hardware supports it. For GCode devices this is a non-issue, but some DSP devices are limited in this respect. Although this is an upper limit in the LightBurn UI, you should see this as a lower limit for your hardware, should it have a specific number of available layers/cut banks/etc. We expect all controllers to support at least 32, and we have the ability to output many more, for example when generating Material Test grids.

Connections

USB Connections

• Controllers should present to the computer as either a standard serial device (USB CDC ACM) or libusb/winusb compatible device.
• Devices that require the use of a proprietary driver will not be considered. All communications must be possible directly from LightBurn and/or MillMage via one of the protocols noted above.

Network Connections

• Controllers should use a simple TCP socket connection that streams ASCII characters, just like you would with a simple serial connection. Effectively telnet but without all of the control characters.
• HTTP/Websocket/UDP/etc protocols will generally not be considered. There are far too many ways to implement these options so it is simpler to unify on a basic text stream. Especially for GCode based devices this should be trivial.

Protocols

GCode Protocols

• For GCode-based devices we generally prefer communications protocols as close to GRBL as possible. The receive/response pattern as well as all status request commands should be the same. See here for more: https://github.com/gnea/grbl/blob/master/doc/markdown/interface.md
• Alternatively, we also support Marlin and Smoothieware communication styles.
• The GCode itself (aside from status request/responses) can be generally whatever suits your needs best. We have a GCode templating system that will allow you to specify the exact format of GCode needed for your device, via variable replacement. Please see our Custom GCode documentation for more information: https://docs.lightburnsoftware.com/CustomGCode.html

Binary Protocols

• If a binary protocol is absolutely necessary, as for DSP devices, there is unfortunately no standard communication protocol we adhere to. Each binary protocol we support is different. You will need to provide us with specific and detailed documentation, in English, for how to build the binary data stream for your device.

Providing Binary Protocol Documentation

If LightBurn Software agrees to pursue custom code development to support your particular hardware, we will require strong documentation and cooperation to do so. We may request the following, but not limited to:

• Example hardware for all possible SKUs that would need to be supported.
• Complete protocol documentation detailing all supported commands and hardware control options. This should provide:
  • 100% coverage of all commands we would be required to implement.
  • Input (vector) and output (your binary protocol) examples for a variety of common scenarios — basic vector moves, fill moves, raster/image operations.
  • Specific details on configuring the hardware itself such as operation modes, controlling accessories (air, exhaust), etc.
  • Specific details on any layer/color system — number of supported layers, control of cut options per layer, etc.
  • Specific details on any controller UI options, such as embedding previews to be displayed on the controller LCD.
  • Details for any immediate mode commands supported, such as jogging, pulsing the laser, framing, querying or changing hardware settings, etc.

Encryption

If your hardware implements some form of protocol encryption, you will need to provide us with any relevant encryption implementation and key details, for which we will gladly sign an NDA.

We take this very seriously and understand the need for encrypted communications to protect IP.