Adapting a post-processor for Lasers

Introduction

The Laser Module enables both new tool types to represent lasers in the tool database, and also new laser specific strategies.

The laser module now provides independent records and variables for laser tools and toolpaths. Because these outputs have been separated from conventional router control, for most machines and controllers it should be possible to create a single Post Processor to work seamlessly with router or laser toolpaths, but please note that you may still need to ensure that the physical configuration of your machine is changed depending on the toolpath type.

Previous Post Processors will not work correctly with the Laser Module

Please note that many conversion kit manufacturers provided Vectric Post Processors before the release of the Laser Module. These used workarounds to allow some router toolpath strategies, such as profiling, to be used with a laser head. Post Processors created without explicit support for the additional features documented here will not work correctly.

There are generally 4 areas that need to be modified in a conventional Post Processor to extend it for Laser toolpath support.

  • Add support for a new Power variable, which will be used by the new laser strategies.
  • Add new laser-specific Post Processor Blocks to format laser toolpaths correctly for your machine and controller.
  • Modify any existing Post Processor Blocks to ensure independent power and laser-specific behaviour.
  • Add a flag to tell Vectric's software that this post now supports laser toolpath strategies.

The following sections deal with each area in turn and an example using the GRBL gcode controller is provided. These examples are from the grbl (mm & inch) post processor provided by default with Vectric's software.

Power Variable

Vectric's software will output the power setting for a laser toolpath in the range of 1-100%. We need to add a new variable to show how to format this setting for your particular controller. This is also the opportunity to scale the raw percentage value to the numerical range that your controller requires.

Example

For GRBL-based controllers, the power setting for a laser is typically aliased to the gcode spindle speed control command 'S'. In laser mode, the controller will respond to a spindle speed control change by adjusting the power of the laser instead. Although it can be set within the controller, the default setting for the maximum expected 'S' value - or laser power - is 1000.

For GRBL, therefore, we need to format the POWER variable to be a gcode 'S' command and scale its output value by a factor of ten so that it is in the range of 1 to 1000 (instead of the default 1-100).

The variable entry in the Post Processor reads:

VAR POWER = [P|C|S|1.0|10.0]

To break this entry down in plain English, we are saying that the POWER output from our toolpath should be used everywhere in our subsequent post definition file where we have the the variable [P]. But we should only only output a command as the POWER value changes (C). We will replace the [P] variable locations in our our toolpath output with the command 'S' (S). The power value should be formatted as a whole number with no decimal points (1.0) and should be multiplied from its default by a factor of 10.

New Laser Post Processor Blocks

To allow Laser control, there are new Post Processor Blocks available in the Post Processor. These are:

  • JET_TOOL_ON - Output whenever the toolpath needs the laser on
  • JET_TOOL_POWER - Output whenever the toolpath needs the laser power to change
  • JET_TOOL_OFF - Output whenever the toolpath needs the laser off

Example

In our GRBL example we haved added the 3 new block types. For turning the laser on, GRBL makes use of gcode M4 command (normally intended for spindle direction, but 're-used' by GRBL for laser support ). We can now make use of our POWER variable, defined above as [P], to provide the required power value. The JET_TOOL_ON block is thus:

+---------------------------------------------------

+ Commands output when the jet is turned on

+---------------------------------------------------

begin JET_TOOL_ON

"M4[P]"

For turning the Laser off GRBL makes use of the gcode M5 command:

+---------------------------------------------------

+ Commands output when the jet is turned off

+---------------------------------------------------

begin JET_TOOL_OFF

"M5"

Finally for setting the power itself then for GRBL we just output the power:

+---------------------------------------------------

+ Commands output when the jet power is changed

+---------------------------------------------------

begin JET_TOOL_POWER

"[P]"

Modify Existing Blocks

We also want it to be the case that when we perform a feed move then we also output the power, so to do this we update the FEED_MOVE blocks to include [P].

We have to do that for all of the different feed move types.

In addition, we need to avoid plunge moves occurring when the laser is on. For conventional milling or routing, we need the spindle to be on before a plunge move, but for a laser it is crucial that we only turn it on after we have moved to the correct Z level (this problem manifests as 'overburn' at the beginning of each toolpath segement). To ensure that we can correctly separate these requirements, we may need to remove any spindle commands from plunge moves, or other block types (some may have them in the header, for example) and break these out into explicit SPINDLE_ON & PLUNGE_MOVE blocks. This will ensure that these moves are only made for non-laser toolpath strategies and in the correct sequence.

Example

For GRBL this is a simple addition to the end of the feed move statement:

+---------------------------------------------------

+ Commands output for feed rate moves

+---------------------------------------------------

begin FEED_MOVE

"G1[X][Y][Z][P]"

Remember that we set our POWER variable to only output on change (C) so note that in the output for feed moves at constant power, only an initial, changing, power command will be included. For some controllers, the number of commands that can be processed is a limiting factor on the speed of toolpath and for laser images, in particular, this can be mitigated somewhat by not sending uneccessary commands whenever possible.

For the separate GRBL spindle and plunge control the blocks are:

+---------------------------------------------------

+ Command output after the header to switch spindle on

+---------------------------------------------------

begin SPINDLE_ON

"[S]M3"

+---------------------------------------------------

+ Commands output for the plunge move

+---------------------------------------------------

begin PLUNGE_MOVE

"G1[X][Y][Z][F]"

You'll note that GRBL uses the M3 to control the router or mill. Also note that the plunge move requires the ability to move the machine in X & Y in order to support ramping.

Explicitly Mark the Post Processor as Laser Capable

Lastly a Post Processor will require the new Global File Statement LASER_SUPPORT="YES" added to be available for selection as a Laser Post Processor within the software.
This is only added to Post Processors for general use once the Post Processor has recieved complete testing by the creator.

Example

LASER_SUPPORT = "YES"