Sheetcam revised post - please test

What is the recommended post for QTplasmaC using hypertherm 65 using the tools table from them.

Butt not yet using the RS485 connections

I am using the original F post

snowgoer540 wrote:

rodw wrote:

It's not the magic comment. Its the comment after setting some of the hole cutting variables.
 

Magic comment/g-code command, to me they are the same, # commands get called magic comments in the docs as well (even if I'm biased because I'm probably the one who put that there ).

Not even close. When you use
You are using a gcode named parameter.
ref: linuxcnc.org/docs/devel/html/gcode/overv...ml#_named_parameters

It would not be unreasonable to expect the filter correctly processes valid gcode. Its a bug!

You can use whatever post processor you like or you can write your own which I did in the beginning. I think Phil removed links to the one he wrote so getting a full featured post processor distributed with sheetcam is worthwhile.

It would be interesting to extend the post to change the velocity slow down based on the hole/arc diameter as some of the sheetcam rule sets in use do. But I just wanted to implement the plasmac default features.

Clive wrote:

What is the recommended post for QTplasmaC using hypertherm 65 using the tools table from them.

Butt not yet using the RS485 connections

I am using the original F post

I don't think there is any functional difference between the Sheetcam post and the one you are using. There are two main differences I can think of:
1. The Sheetcam one more closely follows the Sheetcam paradigm. Spotting is moved to drilling operations so there is no need to use a specific Centre Spot tool for it. This was a carry over from a CandCNC post I modelled my original work on.
2. By default, Sheetcam passes all of the cut parameters to Plasmac using a magic comment so Sheetcam is the master of all cutting parameters to avoid data redundancy and the need to sync sheetcam to Plasmac if you make a change. Changing a variable in the Sheetcam Post makes it retrieve the Plasmac material based on the tool number the same as what you have now.
3. the Sheetcam post is part of sheetcam! The previous post was really unofficial as it was on the forum here, not part of the Linuxcnc distro. To me this is the correct model.

I personally think 2. is a big positive issue, you only should have data stored in one place to avoid it getting out of step.

Good points Phil. I was actually wondering if it was worth building out the plasmac hole processing to accommodate tiered hole processing based on the hole rules from SeanP on another forum. I shared screen dumps of the Plasmac versions of these  a long time ago so I guess thats the kind of thing you are talking about. There would be an enable flag and and arrays holding the hole diameters and velocities.
I got as far as reading the Lua docs about arrays this morning but have not looked at the Sheetcam onArc method to see if its feasible. I think it is.

I have not been using hole slowdowns often but recently I enabled the Plasmac defaults and it did make a difference. Long term I want to have an enhanced filter to apply more sophisticated hole adjustments. I may get there one day.

Hey Rod,

I updated to this post on the new machine running QTPlasmaC.

The only problem (re:user errors) I'm encountering is that since the rain I keep getting power outages in the shed (not asscoiated with this) and when I restart and get everything aligned again, I can only start from the beginning of the job. Previously I would be able to enter a job at the beginning of any cut.

The error I get is attached, along with the first 30 lines of gcode.

I think I may just need to get the toolset loaded into QTPlasmaC, however I am still adjusting these in sheet cam as I learn the machine anyhow it runs.

   

Thanks Phillc54.

So only workaround is to go to an old pp and choose the material in QTPlasmac?