GRBL Plasma cutter programing help

I’ve been using lightburn for 2 years and have recently modified my CNC plasma table from a proprietary control board to a GRBL. I am currently using an Arduino Nano to feed the signal to the 2 stepper motor drivers (TB6600). The motors move and I can send simple jog commands to them with no problem. Right now I can use lightburn to dry run simple shapes. I have no problem with running a square shape. When I try and dry run a complex shape like a letter or circle that has an arc the motors slow down to a crawl and move in very small increments and don’t run in a smooth fluid motion like they should. I also know that the post processor for lightburn uses G1 and makes many segments to form a curve. Is there something I’m missing that should resolve this issue. Its almost like the Arduino is having trouble receiving the data from lightburn at a high enough speed and then sending that information to the drivers.

In my mind this setup should function no different than the GRBL laser I have (Ortur laser master pro) except instead of the g code command turning on a laser its sending a signal to fire the plasma cutter. they both use g-code and both move 2 axis’s. What am I missing?

Thanks for any help and I look forward to participating in this forum.

Firs thing i would do, specially if you have an OLM2 Pro to compare is compare the outputs of $$ commands on both machines

Compare acceleration values, and also $12 arc tolerance

Somehting will pop to the eye specially if you use code compare or similar software to see differences (or post both here so we can help pinpoint it)

What does the $12 arc tolerance do? I have it set to .002, any suggestions of what value I should put there? I will look at the values off the ortur this week when I’m at my shop and compare them to the grbl I’m using for the plasma cutter.

This is defaults, you might have something else going on
Let me ask though, ONLY happens when both motors start moving in vectors, curves?
Wonders if it could also be current draw?

Got to compare all values if i am honest because there are on $$ multiple variables that could play into the problem

I will check this week when I’m at the shop. You should see a reply here on Tuesday evening.

IF you cant figure it out, try recording a small video of it, and upload to youtube or soemthing. At times audio/video gives a ton of insights on what might be going on.

also isolate the steppers
As in, unplug X motor, run
swap Y motor, run
Do they suond the same and move the same if isolated?

So I did ALOT of playing with firmware and got most things working. Acceleration is perfect, calibration is perfect. Added a 5v relay to fire the plasma. Thanks for all the help. Now I have one thing stopping me.

When the dwell time is turned on in lightburn it fires the plasma and dwells properly. But then it very quickly turns the relay of and on ( few milliseconds in the open state) and then rapidly closes to fire the plasma for the cut after the dwell. This quick open and close of the relay causes the plasma cutter to not fire on the second firing of the relay. I see this is because there is a g4 p.6 for dwell then a m4 and m3 to fire the plasma. I’d like to dwell and then just continue the cut without rapidly opening and then reclosing the relay. How can I do this within lightburn so that I don’t have to manually edit the post processed g code.

If I understand what you’re trying to do, you might want to test the “constant power” option.

I am using constant power mode

Which transfer mode are you using and what are your $30 and $31 values?
Is the relay ON at 5v or does it turn on at less voltage?

The relay is on at 5v. I have tried it at lower volts and it does not close at anything under 5v. I do not know what the $30 and $31 are as the plasma cutter is at my friend’s shop. I will go sometime this week and report back.

@TonyDovaloni , as of V1.5, LB now has a better method for CNC plasma table process. The dwell behavior you are seeing is normal behavior for laser process. It’s simply not applicable to plasma process for the reason you cited. Rather, you should create your own Custom GCode device profile and you can add to it your own gcode stmts for key events in the plasma process and custom for your CNC plasma table, including a pierce delay. I have an example of using it in the following link. My example even uses a floating torch probe cycle to find the surface prior to each shape cut. Enjoy.

Last night, before going to sleep, I did a search and collected some links, small world, some of which are from bLouChip (a success story), have a read very well explained.

Lightburn:

Github:

@parsec , that’s a good list you have compiled.

Adding to your list, if OP or anyone is looking for a Lightburn - Sheetcam workflow combination for plasma process, especially if they have multiple CNC process tables or as in my case, a single CNC table runs processes of laser, plasma, and milling…
then consider grbl/HAL or LinuxCNC as controllers. LB supports both in laser process. And both controllers are EMI hardened and facilitate further EMI mitigation with signal and control wiring.

For plasma process, both have an integrated THC capability. In the case of grbl/HAL, follow the links on its page.
In the case of LinuxCNC, see this post for 3 components (sw + 2 hw).

However, if using an Arduino mega2560 board or the like, adapted with EMI mitigation and shielding (my CNC controller), with a standalone THC such as a Proma THC SD, then see this post for a Sheetcam plasma post processor and a THC Z Anti-Dive Circuit schematic.

1 Like

Loaded your .lbdev file and it controls our machine. But before I do any testing I want to make sure we do NOT have THC enabled as we do not have a probe or z axis. Any recommendations on how to proceed?

Also thanks everyone for all the input. This place is a wealth of knowledge

1 Like

CORRECTED gcode…

Since you don’t have a THC nor a Z axis, all you’re going to need in the Tool On device action is:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;tool on
;|ABS| (macro wasn’t available in last beta I used)
;adjust this code for G91 or G90 mode
G0 Z3.7 (move to pierce height)
M3 S1000 (fire torch either via Spindle Enable or SPWM)
G4 P0.800 (hard coded, dwell var not available here)
G1 Z1.5 F1000 (move to cut height)
G1 F{speed}
;|RESTORE| (same as ABS I presume)
;end tool on
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

In LB, use menu Edit->Device Settings, Custom GCode tab
to edit the device actions. See the doc for more details and edit macros and choices.

1 Like

So I tried the above code. The plasma cutter not run a job when I draw a simple circle. But the machine will job once and the console says stream started and then never ends the stream. I change the device to a regular grbl profile and not the experimental device and everything goes back to operating but I then still have the issue firing the plasma. Any suggestions?

please export your Custom GCode device and post the resulting .lbdev file, and post your .lbrn2 file with the shape(s) that don’t cut. I’ll take a look at it.

please post your LB generated gcode file also, Save Gcode button in Laser window to create the file.

as an example, here are the files I just used to generate valid CNC plasma gcode for a job cutting 1 simple square shape.

simple square plasma example.gc (1.9 KB)
simple square plasma example.lbrn2 (3.3 KB)
Custom GCode for Plasma NO Torch Probe Cycle.lbdev (5.6 KB)

plasma cutter.lbdev (5.7 KB)
2 inch circle test.lbrn2 (12.8 KB)
2 inch circle test.gc (4.0 KB)
here are the requested files. these were what we were using for testing. just a simple 2 inch circle.

@TonyDovaloni , a couple of observations…

  1. I forgot you don’t have a Z axis, so when I “corrected” the code snippet above I broke it for you, I was thinking you ‘only’ lacked the THC and floating torch mount. Disregard any “G0 Z…” motion stmts.
  2. I believe your CNC controller is hanging or throwing an error msg re. the “G0 Z20” stmts in the .gc file that you posted. Again, you don’t have a Z axis, so don’t produce Z axis code. Check each of the actions in the device profile for Custom GCode and adjust those action stmts to remove Z axis motion.
  3. you are also producing gcode in ‘relative’ G91 motion mode. That can be more complicated and dangerous since Custom GCode device actions have mostly hard coded stmts, although the doc mentions the ability to flip between absolute and relative motion with some builtin macros. During the beta, when I tried to use these macros, they didn’t seem to be implemented yet and I’m not sure if they are there now.