Sheetcam revised post - please test

Guys, I found that the current Sheetcam post processor for Plasmac did not send the kerf width to PlasmaC so the cut recovery was not working.
I have also added a section to configure and enable the hole cutting mode in PlasmaC.

I've published the post on the sheetcam forum where it belongs. It would be good if any Sheetcam users here could test this and post up any feedback on the sheetcam forum

You can download the post from here
forum.sheetcam.com/viewtopic.php?f=5&t=8651&p=29440#p29440
Please post any feedback there too.

To implement, edit the post to set the hole cutting parameters use defaults are coded in now.
If you don't want to use hole cutting, set autoholes=false
Note that the dimensions for hole diameter and overcut are defined in mm and if you are using thos imperial dinosaur units, they are converted to inches before being inserted.

Any changes will be published on that thread. When I look at it now, there is no need to use an autoHoles variable as it can be selected using holeMode so expect a change.
 

Yes, Actually on further testing, this is unearthing some bugs in the Qtplasmac input filter.

1. If a variable like #<h_velocity> is set and there is a gcode comment on the same line, an error occurs parsing the number
2. if holes and magic comments are in the file, there is a python error. Commenting out the magic comment, removes the error

 

I think the filter needs to use a different name when creating the instance.

Can you share a copy of phills post? If I am playing with post processors, I might as well get it right!

So the displayed error I think I am going to put down to being a result of the comment on hole processing numbers leaving QTplasmac in an inconsistent state and causing the second error. Its gone after a restart.

But the bug on on comments is confirmed. Try loading the attached
 

I found a copy of Phill's post so don't worry about that. Some features are implemented but I think the move of the spotting code to the drilling method broke some stuff. It looks like there was only one line missing so I'll test more

Is this what you wanted to see?

I did not enable reporting per cut.
What is the use case for that?
You could have 1500 or more cuts on a full sheet.
Surely nobody sifts through all that code

It's not the magic comment. Its the comment after setting some of the hole cutting variables.
It looks like there is a string to float conversion happening but the number AND the rest of the line is being parsed causing an error
Its 100% valid gcode the filter is erroring on. It should therefore parse it correctly.

The reason I wanted to add comments to the hole cutting variables was so the generated gcode was more meaningful to the user.

I think I will leave the post processor as it is now as Les has copied it for inclusion in his next release. In any case, the sheetcam report provides the data you are looking for at the part level.