Update on plasma use case success, albeit post processing gcode

LightBurn Software Questions
1

This thread is related to Feature Request: per-cut focus touch off for plasma cutting w/THC

I have finally completed my Mill Right Mega V Plasma build today (yesterday) and spent the day running the system through some paces. I experimented a lot with the probe code needed to touch off the torch to the cut surface in order to set the Initial Torch Height or sometimes called the Pierce Height. The gcode process involves saving my LB generated gcode to a file and post processing the file using a VIM macro, performing search and replace. Iā€™m going to run more tests tomorrow using some prior laser design LB files I have, running without actually firing the torch but just observing the movements, thus saving the making of potentially a pile of scrap. I did like the results I got today with fine tuning the initial probe and retract code; it seemed to prove out the process.

Itā€™ll be great though when LB actually puts in the probe touch off code :slight_smile: I hope this feature request is on the short list. :slight_smile:

Hereā€™s my test file and probe code:
MegaV test pattern.gc.txt (5.1 KB)

take care,
Lou

2 Likes
2

Hope all goes wellā€¦ :+1:

3

update: Iā€™m happy to report a successful CNC plasma cut job on my new CNC build ! I used LB to design and gen the gcode in GRBL-M3 device mode. I saved the gcode and post processed it as described in the above post of this thread. Then I sent the gcode to my CNC system using UGS. It worked end to end, no issues. I debugged and mitigated many EMI and RFI issues to get to the point of success and reliability, but it was worth it. Many thanks to many folks that offered advice.

For those interested, please read about all of this, including pics and videos, on the MillRight CNC forum here: https://millrightcnc.proboards.com/thread/3323/plasma-mega-set
See the posts near the end of the referenced thread.

I will continue to use LB for design and code gen in my plasma use case, itā€™s just too awesome not to. The ease of use factor in design for minor engineer drawings to especially with text and graphics is extremely powerful. I just wish there was a plasma mode of control and burn.

If LB does add plasma feature, I recommend the begin cut (M3) and end cut (M5) user gcode blocks we discussed earlier this year in the LB referenced thread; the code blocks being edited and stored in layers. The amount of fine tuning that will be on going in the plasma system I see continuing, and code blocks provide full user control on those plasma M3 and M5 events. For instance, movement delay after starting the arc is critical, and must also be synchronized with a movement delay in the THC.

Here are my first project code files and the VIM macro to post process.
I welcome any discussion.
hello world2.gc.txt (31.4 KB) hello world.lbrn2 (43.7 KB) plasmapp.vim.txt (798 Bytes)

Cheers,
Lou

1 Like
4

update: Still having great success with LB on my MillRight Mega V Plasma machine. Yesterday I had a need to use the ā€œStart Hereā€ feature of LB (find it as a button in the Cut Preview window). It worked great ! Saved me from an otherwise disappointing case of scrap metal.

I have used Start From cut settings of Current Position and Absolute Coordinates, but work fine, but in the latter case, remember to code a G90 at the end of the torch touch off (pre M3) and torch retract (post M5) commands. I use the LDCrestore keyword in my VIM macro to mark those locations, since at a minimum I do a global replace to plug in the cut speed (Fnnnn) setting, itā€™s altered during pre and post Z moves of the torch. Absolute Coords mode also allows direct editing of the gcode file as another means of resuming a cut after a collision or cut malfunction. Only when I want to use an origin other than bottom left do I use Start From: Current Position.

Iā€™m still fine tuning the torch touch off routine, and have at least one more condition to solve, that being Torch Height Controller (THC) induced error in the Z axis that accumulates in jobs with >20 or so cuts; I sometimes get a soft limit error thrown by grbl controller when in fact the Z is physically safely within those limits. I will experiment with less retract distance, perhaps 10-15mm rather than 20mm. The condition is also an indicator that my THC monitor voltage is too low, thus the THC is only issuing Z up commands and the cumulative error is always positive.

Hereā€™s the latest torch touch off and retract gcode, this was a case of Absolute Coords job gen-

=======================================
;begin safe retract and ready for probing next cut ITH
M5
G21 G91
G1 Z20 F800 (fast retract to safe height)
G1 g90 f2000 (restore feed rate, move mode, and units as needed)
;end safe retract and ready ITH

G0XY absolute coord move to next cut start positionā€¦

;begin probe for PH and ITH. THT=9.5mm
G21 G91 (metric and relative)
G38.2 Z-33.5 F800 (probe fast from safe retract, 24mm+THT)
G1 Z11.5 (fast retract 2mm+THT)
G38.2 Z-13.5 F400 (slow probe max -2mm -last retract)
G1 Z12.5 F800 (fast retract to Pierce Height PH, 3mm+THT, 150%-200% of ITH)
M3
G4 P1.25 (pierce delay, be sure to make THC delay => this+1.5)
G1 Z-1.5 (transition from PH to ITH of 1.5mm usually)
G1 g90 f2000 (restore feed rate, move mode, and units as needed)
;end probe ITH

=======================================

Cheers,
Lou

5

update: I had to add a grbl delay (G4 P0.75) in the M5/retract code block after each cut, the delay is 0.75 seconds and allows for the two mechanical plasma trigger relay reaction times (1 in grbl controller box and 1 in plasma cutter) plus the THC reaction and transition time once the arc shuts off. The THC reaction time includes time for itā€™s internal relay to switch the Z dir and step lines back to the CNC grbl controller. The symptom which youā€™ll see without the retract delay is that after 25 or so cuts (with torch probe touch offs), the cumulative Z error from lost Z steps during retract will cause a soft limit error on Z retract eventually. At that point, the LB Start From Here feature was very useful to allow me to resume the cut from the point of error, after I re-homed the machine of course.

Here is the code for both torch probe touch off/M3 and the M5/retract .

= = = = = = = = =
;begin probe for Pierce Height (PH) and Initial Torch Height (ITH)
; Torch Probe Travel TPT=9.2mm
G21 G91 (metric and relative)
G38.2 Z-30 F800 (probe fast from safe retract, 20mm+TPT rnd)
G1 Z8 (fast retract off probe switch)
G38.2 Z-10 F400 (slow probe -2mm+retract)
G1 Z9.2 F800 (fast retract to TPT)
G1 Z3.7 (retract to Pierce Height PH, 150%-225% of ITH)
M3 (light it up)
G4 P1.25 (pierce delay, make THC delay => this+1.2)
G1 Z-2.1 (transition from PH to ITH)
G1 f2200 (restore feed rate, move mode, and units as needed)
;end probe ITH

G1X0.9Y-1.79ā€¦ cut moves.

;begin safe retract and ready for probing next cut ITH
M5 (put it out)
G4 P0.75 (wait for THC to give Z control back to CNC)
G21 G91
G1 Z15 F800 (fast retract to safe height)
G1 f2200 (restore feed rate, move mode, and units as needed)
;end safe retract and ready ITH
= = = = = =

btw - here is my youtube channel which documents the custom build with video, all instructional.

and here is another link into the MillRight Mega V forum which gives additional instruction on much of the custom build details: https://millrightcnc.proboards.com/thread/3563/plasma-router-custom-build-frame

cheers,
Lou

6

update: So even though the M5 retract delay of 0.75 secs was added to mitigate the THC Z error, it was not a complete fix; it only fixes the gross error due to lost Z steps while THC transitioned control back to grbl. The THC Z control movements during a plasma cut will still compound when the THC set arc voltage is either too low or too high, which will always be the case by at least the precision of the THC set voltage function, which is 1 volt in my case. So the fix for that is to get precise in that setting, and to understand the symptom and apply change in the correct direction.

In order to understand the problem, see this diagram I created to demonstrate it.
Plasma THC Z error diagram.lbrn (124.0 KB)

Net: when the THC voltage is set to high, then grblā€™s view of Z is that itā€™s getting more negative (lower) after each cut. That is because the probe command will have a longer stroke each time by the amount THC moves Z positive (up) trying to achieve the set voltage. That error accumulates until you get a -Z Soft Limit alarm on a probe command (torch touch-off).
Conversely, when the THC voltage is set to low, then the opposite occurs, until you eventually get a +Z Soft Limit alarm on a M5 retract attempt.

What I have found works well to determine the right THC arc voltage is to test cut 150mm straight line with the THC control delay set high enough (9.9 secs in my case) such that it will not take over Z control during the cut, thus you can monitor the arc voltage, long enough, on the THC DRO to get a good read of the value; it remains fairly stable during the straight line cut, with the torch Z being static and already at the ITH.

Now, if you do get a Z Soft Limit alarm or have any other job cut interruption, LBs Start Here feature is the fix in order to resume your cut and avoid making scarp metal :slight_smile: Iā€™ve used it several times already, each time very successful :slight_smile: Great feature.

Cheers,
Lou

7

update: Here is the latest torch touch off and retract code Iā€™m using to plasma cut. Iā€™ve run several different jobs with it and all worked fine cutting 14ga mild steel. I can use the same variable parameters of PH, ITH, Pierce delay on mild steel 18ga. to 10ga. I have found. All other parameters/values in the code blocks are basically constants for my CNC. When I cut thicker material > 10ga, then perhaps Iā€™ll have to adjust some of the variable parameters, as those will likely change due to torch tip size changing, plasma amps, and PSI. For the 18-10ga material, Iā€™m using 30A (.8mm) and 40A (.9mm) tips, on a Tecmo machine torch PTM60, with a PrimeWeld Cut60 plasma cutter. On material larger than 10ga, I plan to use a 60A (1.1mm) tip.

Iā€™m also using unshielded tips. I tried a couple of times to use a machine shield and tips but kept having Z/torch move collisions with surface dross blown out of the pierce hole. The interference is very slight, perhaps .2mm or less, but any interference (the slightest force lateral or axial) with my torch will move it off the magnetic mount, itā€™s becoming my latest and remaining issue. However this is a double edged sword, because you want the mount to give way on interference, but it seems there should be some tolerance/resistance to something as minor as a brush with molten dross. The tip when used with any shield is recessed about .8mm, and this distance is a component of the ITH/TH when cutting, so that means the shield is only .7mm from the cutting surface in the case of a 1.5mm ITH/TH. So for now, the best fix is to use unshielded tips, giving me a full 1.5mm ITH/TH during the cut, and Iā€™ll stick with the magnetic mount as is.

Suggestion: I mention all this because I read that some CNC plasma systems use a lateral XY move while transitioning Z from PH to ITH, and thus it makes those systems less likely to collide with pierce hole surface dross, which also extends torch tip consumable life. So LB may consider such a provision when implementing the plasma support. If implementing a user code block as Iā€™ve suggested previously, that could pose a problem, but perhaps an LB keyword can be used in the code block for this transition move and the keyword replaced at runtime. This implementation would also allow for piercing to take place while XY was moving (if so desired in user block code), which would further eliminate dross interference and extend consumable life. :slight_smile:

TIP: The kerf on the 40A tip, cutting 14ga, @35amps @60psi, at 1.5mm ITH/TH, the kerf width is 1.5mm. You can easily measure kerf by cutting a small rectangle programmed with zero kerf offset, then measure either the inside or outside rectangle of the cut and the difference between that measurement and the designed dimension of the rectangle is the kerf width.

Suggestion: if/when LB may implement plasma support, the Start Here feature is great. I use it a lot, and Iā€™m getting lucky in that the restart of the plasma torch is usually in a corner in my interrupt or collision cases, the condition being EMI/RFI caused gcode send is interrupted by knocking out my communications channel and thus grbl continues to run only the few commands in itā€™s buffer, which usually means it quits at a corner. In the case of collision, its usually pierce hole dross collision. In either case, I can edit the shape in LB to start at a different node and even truncate the shape so I donā€™t travel down an open kerf, thatā€™s not healthy for torch consumables also. So my suggestion is to implement the lead-in cut on Start Here conditions if itā€™s already programmed on the layer. :wink:

latest code:

;begin probe for Pierce Height (PH) and Initial Torch Height (ITH)
; Torch Probe Travel TPT=9.2mm
G21 G91 (metric and relative)
G38.2 Z-30 F800 (probe fast from safe retract, 20mm+TPT rnd)
G1 Z8 (fast retract off probe switch)
G38.2 Z-10 F400 (slow probe -2mm+retract)
G1 Z9.2 F800 (fast retract to TPT)
G1 Z3.2 (retract to Pierce Height PH, 150%-225% of ITH)
M3 (light it up)
G4 P1.0 (pierce delay, make THC delay => this+2.0)
G1 Z-1.7 (transition from PH to ITH)
G1 f2350 (restore feed rate, move mode, and units as needed)
;end probe ITH

G1XnnnYnnn cut shapeā€¦

;begin safe retract and ready for probing next cut ITH
M5 (put it out)
G4 P0.75 (wait for THC to give Z control back to CNC)
G21 G91
G1 Z10 F800 (fast retract to safe height)
G1 f2350 (restore feed rate, move mode, and units as needed)
;end safe retract and ready ITH

latest files:
plasmapp.vim.txt (1.1 KB)
garden hose holder.nc.txt (28.6 KB)
garden hose caddie.lbrn (150.9 KB)

Cheers,
Lou

1 Like
10

updated the VIM script today (11/17) since original post yesterday.
During further testing, I found that the G38.2 probe command still carried too much Z speed which eventually induced negative error on the ITH; tenthā€™s of mm are precious in a distance of 1.6mm, so losing a couple of them is a big deal. The fix was to add a second probe cycle at 50mm/min, the first being 1000/min. This mimics the homing cycle pattern. Net results are more accurate and repeatable PH and ITH sets on per cut basis without loosing overall time per cut. The previous singe probe cycles were 200 and 100 mm/min, each having differing degrees of accuracy and repeatability.

update: 11/16 I rewrote the VIM script Iā€™m using to post process LB laser generated gcode into plasma process gcode. I cleaned it up quite a bit, made it much less cryptic, more man readable, and taylorable, I hope. Enjoy.

plasmapp3.vim.txt (5.7 KB)

Cheers,
Lou

2 Likes
11

Great work Lou! Iā€™ve built my own plasma cutter from scrap metal. But it works. Iā€™m trying to use LB for my designs, but the break out board uses Mach3. So I have to use Gcode too.

12

another update to the VIM script, this one adds another parameter (isRampZ) as a boolean to either ramp Z down or to plunge Z down during the PH to ITH transition. In either case, Z also moves in a timed unit mode to consume a portion of the Pierce Delay. Thanks to @TomWS for sharing the idea to consume the Pierce Delay during Z transition. This type of PH to ITH transition I have found has the side effect of making a gouge or narrow pierce hole rather than the usual large pierce hole otherwise. This is ideal when doing the Z plunge, which I use for starting open shapes, cutting tabs, or otherwise not desiring a leadin; that is, the pierce hole is in the saved part, not the waste part.
plasmapp3.vim.txt (7.5 KB)

Cheers,
Lou

13

yet another MyPlasmaPP() VIM script update. I further simplified the script code that replaces M3 and M5 with gcode blocks to perform torch probe touchoff and retract operations before and after each cut. Also, simplified the script code that appends Z pierce time ramping to the XY lead-in move. Hopefully these changes make the script easier to read and modify if you desire. Finally, in making these changes, the VIM runtime behavior of the script has been improved in that you no longer have to answer 'Nā€™o to the substitute/replace command on the first instance of M3 and M5, I auto skip those cases for you, so just answer 'Aā€™ll to the replace commands or 'Yā€™es / 'Nā€™o to selectively control which of the M3 and M5 commands youā€™d like to replace ; and finally the script does not intentionally finish in a VIM error due to not finding an instance of ā€˜;end probe ITHā€™.

plasmapp4.vim.txt (8.1 KB)

Cheers,
Lou

14

another MyPlasmaPP() VIM script update and version change.

  • simplified the arg list removing the args for isG20 and isG90 move modes; instead the script now reads the values from the gcode file.
  • changed the probe command sequence, removing the G0 Z-20 move which negated the end of cut Z retract move; instead the script now adds 20mm to the G38.2 probe command to account for the Z retract move, this way I avoid a potential torch collision of driving it into the probe limit switch if starting the job with less than 12mm or so of Z clearance.
  • added 2 pass/invocation usecase that is handy when having both open and closed shapes in a job/design. Open shapes are likely not to need or desire a lead-in, nor a kerf offset, while closed shapes are likely to need both.

All of this is documented in the script preamble and code comments.
plasmapp5.vim.txt (10.6 KB)

Enjoy,
Lou

1 Like
15

This is likely my last update to this thread. I have shelved MyPlasmaPP() VIM script and replaced with SheetCAM. MyPlasmaPP() was fun while it lasted and served itā€™s purpose in proving that LB can indeed be a very successful CAD/CAM solution for plasma process. SheetCAM in the meantime of full LB plasma support will bridge the gap to plasma serving as the CAM solution for me now. See more rationale here: Default Cut Direction? - #4 by bLouChip

Cheers,
Lou

3 Likes