Post feed rate issue

So the other day my table took off like a rocket cutting at 250 ipm. I'm sure I checked the file and it was fr=250. To get the job done I just set my feed override way low in QtPlasmaC.

Just now I posted using my 90 ipm cut chart and in the file it has fr=50 so that's not right either. I can't say why it's sometimes 50 and sometimes 250, and sometimes the correct feedrate prescribed. Here are some of the opening lines of the file, for the record. Should be fr=90

(Contour e136ba61-aee6-48db-9359-c044ae292eaf [hole])

T0 M6 (select plasma tool)

G43 H0 (apply tool offsets)

(o=0, kw=0.0560, ph=0.1500, pd=0.00, ch=0.1250, fr=50, th=1, cv=127, pe=0, jh=0, jd=0)

UPDATE -- the 50 feedrate is because the hole cutting rules slowed it down. So the holes rule is working but the calculated hole cutting speed is based on 250 ipm normal feed rate. (I have holes cutting at 20%) Just a bit further on in the file, after the holes are cut, we have this.

(Contour a62e9715-a5fc-4005-a130-209e7e809124 [outer])

(o=0, kw=0.0560, ph=0.1500, pd=0.00, ch=0.1250, fr=250, th=1, cv=127, pe=0, jh=0, jd=0)

There you have your fr=250

You actually only need to specify feedrate, pierce height, pierce delay, pause at end, etc, one time at the top of the file. (I would prefer this approach. Hand edits to feed rate are very easy, change at one place and the entire cut file is affected. I do this sometimes) To slow down for holes, issue g-code to slow the feed rate in QtPlasmaC like so:

M67 E3 Q40 (that would set feed rate to 40% of what's set in the "fr" variable at the top of the file. "40" would obviously be replaced with whatever % specified in the hole cutting rule)

Back to 100% again after cutting the hole:

M67 E3 Q0

https://linuxcnc.org/docs/html/plasma/qtplasmac.html#plasma:velocity-reduction

Slowing down via G-code commands rather than re-specifying the feed rate every time also yields the advantage of giving the operator the option to automatically disable THC for hole cutting if desired. There's a param in QtPlasmaC to disable THC if speed is less than so many % of specified rate.

Hey Joel — found both of your smoking guns. Thanks for the detailed write-ups, the JCM, and the sample files; that's what cracked it.

1. The feed rate (250, then 50, then way too slow)

You were dead on in your update — your hole rule was working fine, it was just doing the math off the wrong number. Two things were going wrong under the hood:

• The cut speed wasn't getting carried through to the posted file correctly, so your holes were being calculated off a feed that wasn't your 90 ipm chart (that's where the 250 was coming from, and why the hole rule then landed on 50).

• On top of that, when a hole matched a feed-rate rule in two places at once — one on the machine and one on the cut chart — the two reductions were getting multiplied together instead of just using one. Your config happens to have a hole rule in both spots, so stack a couple of those and the number goes right off the rails.

What we changed:

• Reductions no longer stack. If more than one feed rule hits the same hole, the cut-chart rule wins (it's the more specific one), and it's taken off the full cut speed — never off an already-reduced number.

• JetCad now warns you at Generate if you've got overlapping hole rules, and tells you which one it used. It's an easy thing to set up by accident, so now it's visible instead of silent.

• The feed is written the proper QtPlasmaC way you pointed to — the material line carries the full cut speed, and the hole slowdown is handled with M67 E3 Q… instead of lowering the actual feed. That was a good call on your part.

2. The slow loads in QtPlasmaC

This was the sneaky one, and I'll be honest — I had it pegged on the wrong thing at first (the extra line segments). That's not it at all. It was the material line.

JetCad was writing the full material block (the (o=… ) line) in front of every single contour — a couple hundred copies on your fire-pit sheet. QtPlasmaC treats each one of those as a temporary material change on load: it writes a file, talks to the controller, and waits for an acknowledgement, every time. SheetCAM only writes that line once. Doing it a few hundred times is the entire 30 seconds vs 5.

In hindsight it's an easy trap to fall into. Repeating that line seemed harmless — extra comments in G-code usually are — and I'd actually left it on every contour on purpose, because it makes the file easy to eyeball when you want to reference what's what for a quick manual edit. Nothing in the QtPlasmaC docs warns against it either; I went back through the materials section to be sure, and it documents the (o=… ) format and temporary materials but never says anything about not repeating the line. The catch is just that QtPlasmaC doesn't treat a repeat as a harmless comment the way you'd expect.

The fix: we now write the material line once per material change, same as SheetCAM. One handshake, then straight to cutting.

About those tiny line segments

I want to correct myself here, since I floated this earlier. The extra little straight-line moves on curvy parts are not what's slowing your load — that difference is milliseconds, not seconds. And ignore my earlier comment about Simplify tolerance for this; Simplify only affects motion planning while the job runs, it has nothing to do with load time.

Where the tiny segments can actually bite you is at runtime, not on load. LinuxCNC runs a lookahead planner as it cuts (I mis-stated earlier that it plans the whole file up front — it doesn't), and a dense run of very short moves can starve that lookahead and make the motion feel jerky through those sections.

The reason we don't just arc-fit everything automatically today is that arc fidelity through the CAM pipeline mostly comes from your input geometry — the DXF/SVG you bring in — and a blind arc-fit can quietly cost you precision. So what I'm building is a blind arc-fit pass on the posted output as a toggle. It'll most likely land in the next release and default to on, giving you smoother output out of the box — while keeping a clear way to leave the input geometry untouched when you need exact fidelity. Best of both worlds.

One thing on your config

Totally optional, but you've got a hole rule on both the machine and the "12 GA aluminum" cut chart. With the fix they no longer fight each other, but you may want to delete the redundant one just to keep things tidy — JetCad will flag it for you on the next generate either way.

Both fixes will be in the next release. Thanks again for the patience and the detail on this one!

Fantastic! Thanks for checking into this. I'll test the new release once it's available, for sure.

I actually had this sneaky feeling that slow loads may have been related to all those material definitions sprinkled through the file, but had no way to prove it and didn't have time to dig into details to verify that could be related. I'll be super glad to have one material definition at the top of the program and feed changes done via M67.

Thanks for catching that re: the hole rule duplicates. I'm learning, slowly...