Advanced Search

It's been a while since I posted last. JetCad3 is a parametric CAD/CAM
package I've been building solo for machine shops — plasma, fab, router, laser,
mill — cross-platform on Windows, macOS, and Linux. Lots has landed. This has been in active development for just over 12 years now.

The QtPlasmaC post is fully built out and tested — native G2/G3 arcs (not
linearized unless you want them, it's a post option), material blocks, [spot]
small-hole spotting, M62/M63 THC envelope, M67 hole-velocity reduction. Also
bundled: a plain LinuxCNC Plasma post, Mach3/Mach4, FLCNC/FangLing, ProMach
StrikeCommand, FastCut G7. No post for your controller? An AI Import & Convert
turns a SheetCAM .scpost or Fusion .cps into a JetCad3 post.

Next step is deeper: JetCad3 as a DISPLAY in your LinuxCNC ini — full
CAD → CAM → control in one window. Our GcodePilot workspace already does this
for GRBL/FluidNC (live DRO, Z probing, wireless pendant, mid-cut Run-From-Here,
virtual plate squaring, firmware AVTHC). LinuxCNC is where it goes next — and
I'm looking for LinuxCNC plasma test users. My only LinuxCNC machine here is a
VMC, not a great plasma proxy. If you run QtPlasmaC and want to help, reach out.

THE SUITE — ALL LIVE TODAY

---

  • Design — 2D vector for signage and machine prep. Unlimited free, no account.
  • Drafting — full parametric 3D modeling with editable history, plus built-in
    Sheet Metal: base → flanges/hems → EZ Bend hand-fold reliefs → true flat
    pattern → auto-nest → post plasma/laser, all in one program. No DXF
    round-trip between four packages.
  • Plasma — top-down sheet CAM: DXF/SVG/SheetCAM import, genetic auto-
    nesting, Common Grid shared-line arrays, geometry-based cut rules, live sim.
  • Router — 2.5D nesting-first CAM; GRBL and MASSO posts.
  • Laser — palette-driven cut/engrave; G-code and Ruida output.
  • Mill — Fusion/HSM-style setup milling: high-speed dynamic clearing and
    new stock-aware rest machining. Posts GRBL, FluidNC, LinuxCNC.

Also built in: 2,000+ copyright-free fonts (live previews, offline cache),
straight/arc/circle layout, ready to cut or engrave.

Free/Hobby needs no account and follows the SheetCAM scheme — up to 500 lines of
G-code per post. That's the main gate, and it covers a lot of real hobby work
for free. Every workspace and tool is in the free login; I'm not gating
features. The ask is simple: if you're making money with it, support the project
so I can keep improving it. A free online account (for filing issues/requests on the community forum)
and an unlimited hardware HASP license are also available if you don't like monthly or yearly subscriptions (I don't like them, I'd rather own the software. Lifetime Updates are included with Unlimited Licenses, no version freezing like many other systems)

ROADMAP

---

  • Bevel cutting for Plasma
  • LinuxCNC control integration (DISPLAY in the ini, JetCad3 becomes the interface like Gmocappy or QtPlasmaC for Plasma, Mill, Router, Laser, etc)
  • Internationalization / multi-language
  • HVAC library + 3D-sketch wire-based duct builder in Drafting
  • Tube/rollcage: auto pipe coping + unbend, inline scribing (bend lines,
    orientation) straight to the pipe cutter
  • Rotary Jet Cutting workspace for tube notches — with "NotchMaster," a
    conversational tool that builds 3D tube notches ready to cut

Feedback from this forum has been some of the best I've gotten. Keep it coming —
and if you're a LinuxCNC plasma operator up for testing, please reach out.

 

stoobydale wrote:

Wow that just got expensive. This is a portable table, the cut dimensions are adjustable at the design stage and I am probably going to make mine 1000x800. The designer suggested a Nema 23 stepper kit with DM542 drivers and a Mach 3 controller from Aliexpress at about $235. I was hoping to use something like this probably with just a different break out board. Is this not possible? This is for hobby use and I am in QLD Australia if that makes any difference. This is also my first build, hopefully learn something and able to modify or make a MK2 at some stage.

I'm also  in Queensland also (Brisbane). You can find my email address on my @MrRodW YouTube channel. You can use a parallel port breakout board.I bought 2 off Amazon for $20. I might have a THCAD which you can use with the encoder component to read torch voltage for THC. If you went with Mach3, you'd probably need to get a Proma THC or similar so it will get expensive quick too. The DM542's should be fine. Very hard to kill. Geckos are way overrated.

On the flip side, all the electronics are in the drives so there is no control board to fail so you could argue Ethercat has fewer failure points do more reliable. I do like Mesa but Ethercat is easier to wire. Hers is a Ethercat plasma control box somebody shared with me today.

 

One small Chinese IO module and a Proma plasma THC

tommylight wrote:

-UP/DOWN/ARC_ON LED's on the main screen MUST be usable even while not cutting to check standalone THC's like Proma

Done.

Master Branch only:
github.com/LinuxCNC/linuxcnc/commit/1d62...9fc99abfe5068e608288

tommylight wrote:

From what a vaguely recall, i did some test and had no success of pinpointing it.
This sort of issues are lingering on from PlasmaC where it would run several cuts then stop at random and do nothing, requiring stopping the machine and using "run from here" to continue.
PhillC did find the issue but apparently not the exact source of the issue, the Z axis would not retract to set height and remain waiting, did fix it to a certain extent where it was very usable and happening rarely.
QtPlasmaC has another similar issue, where running a program would start, got to pierce coordinates and wait there indefinitely despite Z axis being at the correct height. This happened in PlasmaC about once or twice in a full days work, on QtPlasmaC happens way more often, sometimes 3 to 5 times per sheet.

I have not experienced this behavior on a physical machine, however I can reproduce similar in my QtPlasmaC Simulation environment. In my case, it happens when eoffset movement would exceed the available range of travel (usually in Z). I have to deliberately force what I consider to be unrealistic values (but may not be for every table/setup) to trigger it. If you encounter this again, please check the following HAL pin and report back:

If this pin is TRUE, that may explain what is going on. My recent changes to automatically adjust probe height based on material thickness made this more visible. I plan to add some bounds checking in the component with regard to eoffsets, and likely will also monitor the aforementioned pin a general catch-all fault condition.

All this is way past being important, i did voice my concerns during the development about not implementing useless features into it and PhillC ignored most of it to the point that i recused myself from participating anymore, it was disheartening to see:
-PhillC sabotaging his work by implementing useless features, always, always requested by users with a single plasma machine and mostly no or little experience
-my complaints being ignored, while i had over 15 machines in daily use

With regard to your broader concerns, I am not certain which specific changes you are referring to, but many valuable contributions have come from users with only one single table. It is relatively uncommon for contributors to be building machines commercially, and practical feedback from small shops has historically been an important part of Qt/PlasmaC’s evolution.

-my input about the functionality being ignored completely, like : float switch MUST react and stop the machine even during jogging, this has ruined many torches and would have ruined much more if they did not have magnetic holders.

This functionality is in the PlasmaC component. The float switch (along with breakaway and ohmic) inhibits jogging when the machine is Idle.

github.com/LinuxCNC/linuxcnc/blob/2078bd...ts/plasmac.comp#L908

Excerpt (sensor_active is the result of if(breakaway || float_switch || ohmic_detected)):
Appears to be in both 2.9 and 2.10.

-UP/DOWN/ARC_ON LED's on the main screen MUST be usable even while not cutting to check standalone THC's like Proma

I've never seen this request but it would be straightforward to implement. I'll add it to my list of upcoming changes. Initial thoughts for criteria would be Machine On and Idle (not available when the GUI is off, or if the machine is paused).

-seeing all the effort made by PhillC and later you going to waste as PlasmaC and QtPlasmaC got so bloated and so unreliable that i had to stop using QtPlasmaC completely, and actually thinking of slowly moving the remaining PlasmaC machines to my old hal THC stuff, that never fails, ever. Yes, PlasmaC is usable and mostly reliable
-etc etc
-

I disagree with the characterization of PlasmaC/QtPlasmaC as bloated or unreliable. There are multiple real-world installations running successfully, including commercial operations.

Sorry Snowwy and Phill, but i have discussed this before with both of you, even on the phone, so to recap, this is not fixable, must be started over.

I was not trying to pick a fight.

I was not privy to you and Phill's telephone call(s), but in fairness to both Phill and myself, we've both asked you to post a backup of your configuration to try to help pinpoint the root cause, several times. If I recall correctly (not always reliable ), I even emailed you on the side asking for it in case you weren't posting in fear of leaking any sort of Intellectual Property.

As a developer it's not that I don't believe you're having an issue, it's that it is insanely difficult to pinpoint a cause and try to fix it when we are unable to duplicate it. This thread, and the changes made to the component are proof that your concerns were not just brushed off.

There are times like the recent PlasmaC issue I closed out where it was, in fact, the user's configuration that was causing the issues...

From what a vaguely recall, i did some test and had no success of pinpointing it.
This sort of issues are lingering on from PlasmaC where it would run several cuts then stop at random and do nothing, requiring stopping the machine and using "run from here" to continue.
PhillC did find the issue but apparently not the exact source of the issue, the Z axis would not retract to set height and remain waiting, did fix it to a certain extent where it was very usable and happening rarely.
QtPlasmaC has another similar issue, where running a program would start, got to pierce coordinates and wait there indefinitely despite Z axis being at the correct height. This happened in PlasmaC about once or twice in a full days work, on QtPlasmaC happens way more often, sometimes 3 to 5 times per sheet.
All this is way past being important, i did voice my concerns during the development about not implementing useless features into it and PhillC ignored most of it to the point that i recused myself from participating anymore, it was disheartening to see:
-PhillC sabotaging his work by implementing useless features, always, always requested by users with a single plasma machine and mostly no or little experience
-my complaints being ignored, while i had over 15 machines in daily use
-my input about the functionality being ignored completely, like : float switch MUST react and stop the machine even during jogging, this has ruined many torches and would have ruined much more if they did not have magnetic holders.
-UP/DOWN/ARC_ON LED's on the main screen MUST be usable even while not cutting to check standalone THC's like Proma
-seeing all the effort made by PhillC and later you going to waste as PlasmaC and QtPlasmaC got so bloated and so unreliable that i had to stop using QtPlasmaC completely, and actually thinking of slowly moving the remaining PlasmaC machines to my old hal THC stuff, that never fails, ever. Yes, PlasmaC is usable and mostly reliable
-etc etc
-
Sorry Snowwy and Phill, but i have discussed this before with both of you, even on the phone, so to recap, this is not fixable, must be started over.

Thanks for your reply.
Please find attached my back up config.

Also I do not want G53 in my code when I load any .ngc file. Please help as I do not wish to install limit switches to my system. I want to use G31 instead before the cut starts with THC.

Can you upload a back of your configuration made from clicking BACKUP CONFIG on the settings tab inside of qtplasmac please?

hi
Machine reaches the requested speed while cutting. 1000
I have all the default settings on the Parameters Page.
Tried with VAD 60%. still does not work.
Also M3 $0 S1 does not work.

Does the machine reach the requested speed while cutting?
If it does not, it will not turn height control on.
What are the settings on the Parameters page?
Set the VAD to 60% first and try again.

hi,

The Z axis DRO will not move in spite of the following in Raspi 4/5:
a. torch on
b. THC enabled setting
c. HALSHOW is showing move up and even.
d. After trying the changed settings mentioned previously on proma.
e. Mode is 2 for the external THC
Please help as I have been trying to do the same for few weeks now and let me know if any settings need to be added in the HAL or ini.

# ---JOINT ASSOCIATED WITH THE Z AXIS---
net plasmac:axis-position joint.3.pos-fb => plasmac.axis-z-position


 

On the Proma, the first and second settings should be set at minimum, i do not recall what was the third and forth settings.
Only after having this work you can set voltage higher if it wobbles a lot while cutting.

Voltage is set to 100 and H-t to 5.

What settings are on the Proma THC150 ?

Hi All,

I am using 7c81 board, raspi 5 with thc proma 150. I am using QTplasmaC 
The gpios and leds for UP, DOWN, Arc OK are getting connected and blinking.
However, the Auto Z axis movement not happening with thc proma 150. Attaching the files for your reference. Please help.