update to version 23.3
With the break in winter weather the past week I was finally able to bust out the garden hose and get some water in the plasma table 
So I spent the day catching up on plasma projects and working over the scpost with some specific testing also. I found a few bugs in my code, so this version accumulates several fixes the past week. Unrelated, I’ve switched to using SC Dev version 7.1.35 exclusively now, I’m finding it very stable for my needs and pretty significantly improved over 7.0.21 ga release, including some new function.
Enjoy.
GRBL plasma LDC w Rotary.scpost (32.5 KB)
update version 23.6
23.4 various comment fixups and corrections.
23.5 another entityLength fix for OnDrill(), save state and set to 0
23.6 adjusted comment header block for file name and datestamp location
I’ve been getting a lot of table time in this past week, hence the occasional bug fix and fine tuning…
GRBL plasma LDC w Rotary.scpost (32.8 KB)
Hi BLouChip I want to start off by thanking you for all of the work you have done on all these versions of this post processor over the years. You are a real ambassador of what open source is. I can only hope and dream of being able to make a contribution of your caliber.
So I have looked through quite a few threads and found where you wrote that your post will work without the THC By either setting external post variable LdcThcZAntidive = 0. So I used the post editor in sheetcam and found that line in multiple places. At first just changed the one that had mention something about setting default. That did not solve the error code when trying a dry run. So I proceeded to then modify all the lines that contained LdcThcZAntidive=1 to =0. Again no luck same result. Then i really played around and sheetcam now say it can not run post. so my question before I go download the post processor again and start over with my shots in the dark would you by any chance know where I could find a post processor that does not have coding for a THC or would you be so kind as to walk me through disabling it with yours. I am usually able to figure these things out but this thing has got me stumped. Probably Because I dont know know $h*t about code.
@Ronnie’- thank you for the kind words. I’m glad to help.
You are stumped only because I screwed up by picking stupid names for disabling THC code in the early versions of the scpost.
If you get this latest version (24) or the 23.6 version, you will find that I have renamed those external variables to hopefully more meaningful names and making it hopefully more obvious how to disable THC code. The new name is: LdcThcPresent = 1 (yes), 0 (no)
I made most options in the scpost external variables, so you don’t need to edit the scpost to change them at runtime. Rather, set the external variable in one of two ways:
First way) menu Options->Application Options, Variables tab. Create a new variable by the name LdcThcPresent, linear type is fine, assign it 0 to indicated no THC is present on your machine.
Second way) create an Operation of type Variable (Set a post variable), pick LdcThcPresent from the dropdown list, and assign it 0. Put this Operation as the first one in your operations list.
Now, about this latest version 24… I just finished it yesterday, so testing that I’ve done is minimal and concentrated on the areas that I had been modifying; but you know how that goes, everything is affected by everything, so if you have trouble with it, please advise here or PM me, and use the 23.6 version in the meantime.
Here’s what changed in Version 24…
23.8- added back SC global minArcSize in OnInit(), my mistake for removing it a few releases back.
- changed LdcThcEnable to OFF (0) as default, use Path Rule ‘on start’ instead
- added Warning msg if PH to CH plunge rate is too slow for desired pierce delay
- fixed wrong rotary max radius for rectangles in some cases
- improved some gcode comments and formatting for better readability
24- after discovering from Les the intricacies of qrySETYSTART() and qryCHKEND() (always use together with same Y),
and discovering that materialY1 (midpoint of corner) is NOT a good reference for rectangle
max rotational radius. Thus I’m using my own formula to calc max rotational radius, it matches exactly
with the value from CHKEND when the flattened Y drawing coord is on the apex of the rotated corner,
the point on which Z should be zeroed.
GRBL plasma LDC w Rotary.scpost (35.1 KB)
An easier way to set custom variables is by using the options window. You can set defaults and then the user can modify them from the window.
@dj- thanks for the tip, after looking it up I do recall seeing the DefineCustomOption() and ShowCustomOptions() functions a long while ago but didn’t have the time to explore them until you reminded me. So I spent the past couple of hours exploring, and I find them interesting, certainly helpful, but also I’m getting some strange behavior. Perhaps I’m not understanding the exact intent of these functions or the exact correct implementation. Here’s what I’ve discovered upon an implementation, which may not be completely correct, please review and advise.
if I put ShowCustomOptions() in the scpost prologue (before OnInit() ), which I understand is the post load time, and where the doc instructs to put it, then the custom options dialogue is run one time upon SC launch/startup, or when ever the Options->Machine is clicked, or when the scpost is selected in the Post tab, or when saved while editing. However, something strange here, the last values entered in the fields of the dialogue are the values used during post processing, AND even though at times the CustomOption() defaults are shown in the dialogue they are not used during processing. I don’t know from where the stale last entered values are coming from.
If I put ShowCustonOptions() in OnInit(), then of course the dialogue pops up for every post run, but again the fields have the last entered values in them, not the defaults. I don’t know where these values are being saved, they persist even across SC exit and re-launch. But the good news in, the values entered ARE the values use during post runtime. So this seems to be the correct implementation. I’ve also discovered that if I simply hit Esc key on the dialogue, then it closes, values changed or present in the fields are used, and that’s a quick way to deal with what can be an otherwise annoying event over time.
And one more really odd behavior, if the ShowCustomOptions() stmt is commented out and not called, then those mysterious last entered field values are still used, really strange.
I’m using SC v 7.1.35.
please advise.
GRBL plasma LDC w Rotary.scpost (37.3 KB)
The dialogue should just show up when you click the added button on the window where you select the post processor. I will have to look at my post and see how it’s set up. I think the values are stored in the SheetCam settings file.
update v24.3
- 24.1 added scpost Custom Options and popup dialogue for the external variables. External variables can still
be used as in previous versions, but the values entered, if any, in the custom options dialogue will override.
- 24.2 LdcTorchProbeTime rename, fixup rotary debug code, and comment adjustments
- fixed bug in plunge PD and improved warning msg re plunge rate too slow, added units/min
- 24.3 added distance units to numbers in messages and posted comments.
At this time, the Custom Options dialogue pops up on every post processor run (I can’t get it to work correctly otherwise), but it should retrieve and use the last values entered/used UNLESS you have external post variables defined for the same fields, the latter taking precedence. Of course the post variables defined in Operations will take effect during post runtime in the sequence that those “operations” take place.
Tip to quickly get past the Custom Options dialogue- if you like the values in the fields, just press Esc key on the keyboard.
Enjoy.
GRBL plasma LDC w Rotary.scpost (38 KB)
Try this. I also converted some of your options to checkboxes.
GRBL plasma LDC w Rotary.scpost (38.3 KB)
@jdreiswig-- Oh Baby! This is sweet! Thank you!
version 25
24.4 added minor improvement to gcode readability, comment separtor lines for OnNewEntity()
25 added @djreiswig ShowOptions() behavior fix, OnButton() and supporting code,
and unitBOOLEAN/checkbox data type for
external post variables: LdcThcPresent, LdcThcEnable, and LdcBenchTest.
WhooHoo!
After selecting this post processor in the Options->Machine->Post Processor window, click OK.
Then go back to this same window and you will see a new button under the post description,
“Set custom post options” button. Click it and you can set the external post variables here,
or you can still use the definition locations from earlier versions, described in the file prologue.
GRBL plasma LDC w Rotary.scpost (38 KB)
update version 25.7
25.1 prologue comments fixup
25.3 change default THC dynamic on/off cmd to allow continuous XY motion during state changes.
25.4 remove LdcAdcOFF flag and instead reset LdcAbsCutHeight, adj OnNewEntity() header comments.
25.5 added two machine pause cmds in Bench Test gcode so I don’t use it to cut by mistake!
25.6 changed per-cut torch probe cycle from 2 probes to 1, 1/2 the time,
while maintaining same probe accuracy of +/- 0.025mm or accuracy of Z axis
25.7 added LdcPauseOnNewPart boolean option
A few versions prior I had made changes to the dynamic THC on/off gcode, moving it to Path Rules. However, 2 of the gcodes (M7 and M9) for my THC Anti-Dive Circuit (ADC) (which has the side effect of also managing the effective THC on/off state) will cause the XY motion to pause/stop during a cut, albeit just a 0.1ms of a pause/stop, the reason being that grbl is synchronizing the M7/M9 with the exact XY position in which it was placed by Path Rules. This can cause a dimple in the cut edges of the kerf, not good. I had forgotten about this motion pausing side effect.
So to fix it and have continuous XY motion while also changing THC on/off state, I changed to a similar method that I used a few versions back and cleaned up the logic a bit. This method uses spindle speed (S0 for OFF, and S1000 for ON) as the dynamic THC on/off during XY motion, in Path Rules at anytime and when Z arrives at cutHeight during a pierce. This works in a continuous motion due to grbl laser mode $32=1, and when using M4 (spindle enable signal from MCU) to fire the torch, then spindle speed (S-PWM signal from MCU) is proportionally varied automatically by grbl to the realtime XY motion speed, accounting for acceleration and deceleration. My Z THC ADC uses S-PWM to dynamically block or pass the THC Z motion signals, so below 85% of feedrate due to deceleration, the circuit blocks the THC trying to adjust Z to the plasma arc voltage deviation, and then passes the THC signals to Z when later accelerating and feedrate is > 95%. So to ‘manually’ or programmatically manage this circuit, I can force S-PWM to zero (S0) to always block the THC signals, or full on (S1000) to allow the circuit to function automatically again. Grbl’s laser mode operation is that IF spindle speed is changed while ALSO processing a motion gcode XYZorA (called a motion block), then motion will remain continuous while spindle speed changes immediately. Lasers can respond to this instantaneous S-PWM signal change, but mechanical spindles cannot, so in $32=0 (non laser mode), then motion will pause for a spindle speed change, but again only for 0.1ms to process the Snnnn stmt, same as it does for M7/M9 stmts. If an actual mechanical spindle were being used, you’d want to insert a G04 P5 or so also to allow the spindle time to change speed. The final condition that makes the scheme work in plasma cutting with a THC and my Z ADC, is that my Proma THC SD unit is configured to delay Z motion control for 2.5 seconds, that’s enough time for the pierce to occur and for grbl to move Z from PH to CH. That is why I pierce with a M4 S1000 cmd.
here’s a link to the THC Z Anti-Dive Circuit schematic: bC THC Z Anti-Dive circuit.jpeg - Google Drive
and grbl laser mode explained: Grbl v1.1 Laser Mode · gnea/grbl Wiki · GitHub
GRBL plasma LDC w Rotary.scpost (41.9 KB)
LDC SC tools and rules.tools.txt (9.62 KB)
update v26
now I remember why I retired from writing code in my day job 10 years ago 
So after spending some time on the plasma table this past weekend, the modified torch probe cycle did not work out well 80% through a 130 pierce job on 16gaHR where the minor warppage of the sheetmetal combined with accumulated THC Z error caused a probe alarm, the 2mm buffer I was using in the probe cycle was not enough. Increasing the buffer distance in the single cycle probe method makes the overall cycle time about the same as it was in the double probe cycle. So I reverted back to the double probe cycle but increased the slow probe feedrate to 100mm/m instead of 50, only giving up 0.050mm of accuracy, so its still quicker and its written in a way to avoid probe error unless there is a 5mm delta from one probe cycle to the next, that’s how it was previously.
There is also a fix in the OnDrill() operation when not having the RotaryPlasma plugin enabled. Thanks to Ash for finding and reporting this.
GRBL plasma LDC w Rotary.scpost (42.6 KB)
update v 26.2
26.1 added two custom options and external vars for OnDrill(), LdcDrillPdPct and LdcDrillChPct,
to better control and allow tuning of drill pecking rather than full piercing. See the prologue for details.
26.2 thanks to Les… added code to auto load the Rotary-plasma plugin library if necessary,
conditioned on whether or not its enabled in SC, so no need to comment out the lib stmts if not using the plugin.
- fix to THC ADC enable M7 signal timing and sequencing with Z motion.
I did some drill peck testing on 16ga with a 30A PMX30XP nozzle and found that 90% of a 0.5s pierce delay, 3.7mm PH, and 2.6mm CH (50% PH to CH adder to normal CH of 1.5) for made for about a 0.8mm dia. peck 1/2 way into the 16gaHR steel sheet, air at 72PSI. Of course PDs will vary by plasma source mfg (I’m using a PrimeWeld Cut60 with Tecmo UPM105 torch). The scpost LdcDrillPdPct default is 90%, and LdcDrillChPct default is 50% based on these tests.
GRBL plasma LDC w Rotary.scpost (44.5 KB)
version 26.5
26.3 cleaned up msgUnit init, LdcThcONcmd timing after S0 setting, added G94 and S0 to G00 stmt,
added RTformat, changed fire cmd to M4 S0, changed LdcThcCtrl to just use M7.
26.4 added $HZ (Z homing cycle) during air supply catchup machine pause events. This is to
null out accumulation of THC Z error I continue to experience on my table.
26.5 created function DoTorchProbeCycle() to accommodate tracking/diagnosing THC Z error
GRBL plasma LDC w Rotary.scpost (46.4 KB)
update: version 28
mostly changes in gcode production to account for tuning my THC Z Anti-Dive Circuit and the Proma THC SD setting adjustments. You can read about this here: https://sheetcam.discoursehosting.net/t/proma-thc-sd-or-150-discussion/7398/1 , and it spills over in a crosslink to plasmaspider forum.
GRBL plasma LDC w Rotary.scpost (50.9 KB)
update: version 28.2
28.1 added LdcFastProbe var
28.2 added LdcProximityDist feature, supporting vars, and logic.
– proximity distance in mm to skip a Torch Probe Cycle before piercing if current location is within proximity of a recent previous location. A value of 0 turns off the feature. Using this feature is NOT Recommended if you are also using an autonomous THC such as Proma THC SD, these units require Torch Probe Cycles on every pierce location.
GRBL plasma LDC w Rotary.scpost (52.5 KB)
version 28.6
28.3 change double Torch Probe Cycle to single,
28.4 added feature to bypass Torch Probe Cycle if LdcTorchProbeTravel = 0.
28.5 changed OnDrill() pecking parameters.
LdcDrillPdPct – Plasma Drill peck tuning, % of pierceDelay, 0-150
LdcDrillChPct – Plasma Drill peck tuning, % of cutHeight, 0-250
Adjust these values from previous versions accordingly. Use Custom Option Settings window/popup to check/adjust your defaults also.
28.6 another attempt to fix entityLength in OnDrill() and later for accurate cut distance tracking
re. change to use a single torch probe cycle per cut…
inspired by @devloop to change the torch probe cycle to single cycle instead of double. Thanks @devloop.
I had tried this a couple of months ago but got the logic wrong. Hopefully it’s correct this time, both of our testing seems to suggest that it is.
So anyone using this .scpost modified or as is, know that your LdcTorchProbeTravel distance will have to be recalibrated/re-measured for this version forward. Tip to do this:
*) zero the torch to the material surface
*) zero Z WCS in the digital readout of your controller
*) run command G21 G90 (metric mode and absolute distance mode)
*) run command G38.3 Z-20 F1000 (probe down up to 20 mm, the feedrate 1000mm/m is important, that’s what my scpost uses), Z will stop when the probe switch is actuated.
*) note/record the Z WCS digital readout position of your controller, this is your LdcTorchProbeTravel value.
The probe command overruns the switch actuation by a distance that varies with the feedrate used during probing. As long as you use the same feedrate consistently, then the overrun will be consistent (+/-0.050mm); change the feedrate, the overrun distance changes. This has to do with the latency of the MCU as it watches for switch actuation and then decelerates Z to a stop.
GRBL plasma LDC w Rotary.scpost (51.9 KB)
Version 28.7
Inspired by @ROTM from this recent post and drill pecking tutorial, I adjusted my .scpost accordingly. Thanks @ROTM.
https://sheetcam.discoursehosting.net/t/plasma-pierce-hole-not-working-where-is-my-mistake/7430/1
Note though that I’m choosing for now to not change the tool or amps for plasma drilling and pecking operations. I already have logic during normal piercing to minimize the pierce hole (for open shape/path cutting reasons), which takes into account the plunge time from PH to CH; so I’m adjusting for pecking by using two custom options during Drill Operations, one to adjust pierce delay, the other to adjust pierce height, the latter being the new change from previously adjusting cut height. During Drill Ops now, cut height = pierce height and the custom option is a percentage of the normal pierce height.
During testing, I discovered my plasma cutter, PrimeWeld Cut60, will not fire with a pierce delay of 0s, rather it needs a minimum of 0.5s to at least fire. It could be that the air solenoid is worn out or failing, or it could be normal latency time for this model of plasma cutter.
GRBL plasma LDC w Rotary.scpost (51.8 KB)
version 29.3
28.8 motion to pierceHeight first and before restoring XYA pos precision after torch probe cycle
29 change M4 torch fire stmt to dynamic enable of THC/ADC using S960, and thus remove Path Rule which dynamic enabled THC/ADC after 10mm. This allows for correct use of On Small Circle path rules in same rule set as On Corner and On End.
29.1 added G91, relative motion mode, to OnFinish()
29.3 added LdcPdNPFADelta external var and custom option. to handle case of first pierce and anytime there is No Post Flow Air flowing.
Enjoy.
GRBL plasma LDC w Rotary.scpost (53.5 KB)