Just installed 7.1.35 Dev Sheetcam. The CNC plasma is running on Linuxcnc with QTplasmaC interface.
There are 3 post processors listed from Sheetcam, which one to use for plasma cutting application? and if anyone knows the difference?
“PlasmaC”
“LinuxCNC Plasma”
“LinuxCNC PlasmaC”
Thanks
Andy
It would be best if you post in a LinuxCNC forum to do the research. My search scans were brief and I did not see a definitive answer with a post processor name.
Of the 3 you inquire about, I did compare them with a file diff program, and it appears the “LinuxCNC PlasmaC” version has the most features highest revision (0.5) number, then “PlasmaC”, then “LinuxCNC Plasma” in that diminishing order.
The first one has ‘holeMode’ and related vars for hole parameters. It also has what appears to be an improved GetFeedRate() function.
Regardless of what you choose, you certainly want to view/edit the file to conduct your setup.
Thanks for quick reply.
For now I’m settle down with “LinuxCNC PlasmaC”, but if I cut small holes less than 32mm in dia, After I loaded it into QTplasmaC, I got “error Radius to end of arc differs from radius to start”.
the post processor has these two lines:
holeDia = 32 -- Set the hole diameter(in mm)
holeOvercut = 4 -- Set the whole overcut distance(in mm)
I’ve changed them to
holeDia = 8 -- Set the hole diameter(in mm)
holeOvercut = 2 -- Set the whole overcut distance(in mm)
Now, if I cut holes in 10mm DIA, error message is gone.
Ok for now, hope this will help others.
Cheers
That’s interesting. That error reads like grbl error33 description.
My controller is grbl v1.1i. I would usually (but not always) get error33 while performing XY motion on true arcs, G2/G3, and always on leadin arcs cutting plasma process. I trouble shot the problem to grbl truncating residual steps of XY position when reading the position of all axes at end of a probe (G38.2) cmd. A residual step is a motion value less than your controller configs $100, 101, 102, STEPs/mm for XYZ respectively. grbl is hard coded to test for error33 to an accuracy of < 0.005mm. My machine is configured to 57 STEPs/mm, which is 0.0175mm/STEP, pretty coarse as most machines are 0.005mm/STEP. Thus my machine is virtually guaranteed to fail that test if motion is not evenly divisible by 0.0175 and the remainder value (the residual step) is lost during a probe position read. So if the next XY motion is G2 or G3 (the arc leadin of a pierce) it trips error33. The fix was to force gcode post of:
G0 X(currentX) Y(currentY) Z(pierceHeight)
as the cmd after the probe cmd. This not only moves the torch to pierceHeight, but also reloaded the residual step values of X and Y while causing no XY motion.
The morale of the story is, if you direct X for example to move to an absolute position evenly divisible by 1/$100, and then direct it to move less than 1/$100, there will not be any motion on the second cmd since it results in distance less than 1 full step. The controller keeps track of that residual step and adds it to the next motion distance in order to maintain absolute accuracy in chained motion commands.
Lou, LinuxCNC doesn’t have the same issue GRBL does. PlasmaC does however pre-process the g-code before passing it on to LinuxCNC. It appears to be an issue with that pre-processing. holeDiameter is passed directly to that pre-processor. Neither SheetCam or the post processor use that value for anything.
ok, good to know, thanks.
So PlasmaC preforms some magic to the gcode, interesting. I was wondering where the torch touchoff commands and parameters were, wasn’t sure if LinuxCNC had some way of using a subprogram or not for this, that’s why I went into the backstory on my machine’s case.
There is a strange thing that happens if you setup lead-in on the tool as well as the operation. I never set the tools up with a lead-in or lead-out but rather do it on the operation only. That seems to solve the problem
Thanks, I’ll try that
The leadin/out parameters (plus feedRate) in the Operation are inherited from the Tool definition originally at the time the Operation is defined, and again when the Operation is edited AND when you change Tool selection in the Operation.
When editing the Operation AND selecting the Tool edit button (ellipse), that action may or may not update feedRate and sometimes perhaps leadin/out params in the Operation. That seems to be the odd behavior that I’ve noticed, and it may not be odd at all, I just don’t understand the algorithm in which the update occurs vs. not. The Update button in the Tool def doesn’t seem to force the effect in every case. This could also be Sheetcam version dependent behavior, an improved behavior since 7.0.21.
Perhaps @Les_Newell will post to explain.
Thus I have fallen into the habit to simply flip/flop the Tool selection in the Operation (select any other tool, then select the one I want) to force leadin/out and feedRate to update when editing the Operation.
Separately, but related what may seem as odd behavior in this regard, logic in the post processor can affect expected gcode produced from these 3 params since most Tool params are read and handled in gcode logic in OnToolChange() function, but one has to account for the situation where leadin/leadout and feedRate may also be modified in the Operation, thus OnNewOperation() function should have logic to handle those params also, IF ‘handling’ involves anything other than normal Sheetcam handling of feedRate throughout the post processor run.
Re hole processing, there are some settings at the top of the post processor file that disable Plasmac’s hole processing mode as well as some other settings. Its been pointed out that you have more flexibility with Sheetcam’s rules for processing holes.
If you wanted to experiment with automated hole processing with Linuxcnc, Monokrom Plasma is a better choice. Its experimental, but it strips out all of the holes and replaces the code with much more sophisticated algorithims that are database driven for individual hole thicknesses.
I describe how it works here. https://youtu.be/SXlafvsFLx0?si=xNM27hlnqroxSPaA