OctoPrint sends gcode commands to the printer firmware and that firmware usually buffers them while it turns them into steps for each motor. This buffering could cause timing issues because there's no direct link between the gcode commands and the laser commands.
For example, the sequence (assume the laser is off):
G0 X100 Y0, laser on, G1 X100 Y100, lazer off, G0 X105 Y0, lazer on, G1 X105 Y100, lazer off
would draw (burn) two parallel lines only if the laser commands are executed after each gcode command is actually completed by the firmware (and before the next gcode command is started).
If the plugin I mentioned above is used, this sequence becomes (for example):
G0 X100 Y0, OCTO101*, G1 X100 Y100, OCTO100*, G0 X105 Y0, OCTO101, G1 X105 Y100, OCTO100
and now we are depending on the firmware to execute the OCTO commands after each gcode command is actually completed by the firmware.
- I'm using two different OCTO commands but it could be one command with parameters.
So as you noted, the latency of the plugin needs to be determined. Either by experimentation, examination of the source code, or a discussion with the author.
You didn't mention any details about the firmware that drives the printer. If it is, for instance, Marlin, there is a Marlin gcode command, M400, which could help with the timing but again, determining how this changes the timing needs to be determined probably by experimentation. Again if the firmware is Marlin, M3, M4, and M5 are already defined for laser control. Whether or not that's relevant is for you to determine.