Plasmac filter errors on G90/91

I get an error when opening a file QTplasmac filter does not support G91 relative moves and errors.

When using the sheetcam postprocessor, the filter says G91 is not supported yet its used in the docs for hole spotting.
linuxcnc.org/docs/devel/html/plasma/qtplasmac.html#qt_spotting

In Sheetcam generated gcode, this is rejected:

Why?

I am in the process of rebuilding the program in case its been fixed in the last week.
I also get a python error on line 35 of the filter. duplicate component name dummy

Note that in Sheetcam, there is no longer any requirement to use a custom tool name. Any drilling operation generates the spotting code.

It would be great if this could be resolved. M3 clearance holes are a bit too small to cut with a plasma!

Surely we should be allowing relative G91 code. We certainly need to support it between M3 $2 and M5 $2 to allow a tiny move for spotting.

That code loads fine here as does my spotting test code. Is there other code in the file that may be causing it?

You possibly have #<holes> = set to a value other than zero. That will cause this issue as the filter was never set up to calculate holes as relative coordinates.
If that is the case then set #<holes> = 0 before any spotting.

Holes is likely it.
But we are not calculating holes at all. We are spotting which is a totally different operation, with a different spindle even.
The filter is rejecting it based on the state of an unrelated operation. 
The G91 should be allowed to pass through if spotting.

I think Line 784 in qtplasmac_gcode_src.py should say something like:

Why have holes set when not doing holes?
 

Depends on the size of the hole. If you do an outside offset in Sheetcam it correctly has hole cutting applied to any hole it finds.  But if you add another layer for holes you want to spot and apply a drilling operation, the code is correct but you get prevented by the filter.
 

I really don't understand that reply.

Why not let SheetCam do it all.

It does.
Sheetcam assumes #<holes> is a global setting so only sets it once in the file.

Here is one of the files.

Unless I missed something spotting has no connection to <#holes> in the documents. I used to be able to do this.

rodw wrote:

It does.
Sheetcam assumes #<holes> is a global setting so only sets it once in the file.

I meant why not have SheetCam do all the hole code, that is what I do.
I did use #<holes>way back when I was doing manual gcode but then I bought SheetCam so it could do all the code.

Unless I missed something spotting has no connection to <#holes> in the documents. I used to be able to do this.

I don't know how, nothing has changed in regards to #<holes> that I can remenber.

Well we identified a long standing bug and it looks like there is a simple fix.

Its really up to the user to decide how to use  the available features.
The sheetcam hole processing I shared on this forum earlier includes some pretty advanced features and need manual setting up by the user in his tool set, so to my mind, its easier to just let Plasmac do it. I stopped doing the Sheetcam method a long time ago.

It actually makes you wonder how many people use spotting and hole cutting features if it not ben flagged before.