Post feed rate issue

No worries. The JCM file you sent me was for "My CO2 laser" (default laser machine profile). I think you forgot to click any of the sections under your plasma machine profile before clicking export. I should make the export selection more robust. It's confusing right now

I had clicked in the General section of my plasma config before exporting. It had named the file My CO2 Laser.jcm but I renamed it before uploading... Fiddling with it this morning, the export file was always named My CO2 Laser by default. It didn't matter which of the machine config sections I clicked in. I then deleted the laser machine; then it would only export "My Router". So I deleted the router, leaving only my plasma in the configured machines list, and then it named the file correctly. I presume this file will have the contents you're after.

Yeah and I thought it was strange that you had done that by mistake last night so I investigated. There was actually an export bug that was causing the wrong config to export on Windows only and only sometimes so you likely did it correctly. Was not your mistake. Tonight release will have those bugs fixed and now instead of an export button that relies on one of the sections to be selected, there's an export icon to the right of each machine.

None the less, I'm pretty sure I figured out what's causing your slow qtPlasmaC load times and it's just a quick settings change. I believe SheetCAM automatically simplifies line segments out at 0.002" in RDP terms and the equivalent setting in JetCad3 is in General->Simplify Tolerance which JetCad3 defaults to 0.001". The proof is that JetCad3 is posting nearly the same amount of arc moves out as SheetCAM but twice the number of G1 line segments out and that's your slow load times. QtPlasmaC/LinuxCNC actually plans all the motion in one shot at load time and it's those extra tiny segments taking the load time from 5 seconds to 30 seconds. That's a non-linear time relationship because the motion planner has to work backwards then backwards multiple times to plan the kinematics. So you should simply be able to up that setting to 0.002" and honestly for art work on air plasma 0.003" would even be unnoticeable cut quality wise and might yield a smaller file than SheetCAM that way. You can disregard my previous comment about arcs (although that is something that does happen) because if you where to check "Linearize Arcs" in the post settings it would dramatically increase the gcode file load time from seconds to likely minutes.

I'm investigating the original issue you posted about here with your JCM file loaded so I have your custom cut chart. QtPlasmaC expects the comment to contain the feedrate as fr= and then the F word to set the feedrate is an NGC variable. They do that so you can quickly over-ride the feedrate right in qtPlasmaC instead of editing the Gcode.

(o=0, kw=0.0250, ph=0.1900, pd=0.00, ch=0.0900, fr=90, th=1, cv=145, pe=0, jh=0, jd=0)

F#<_hal[plasmac.cut-feed-rate]>

I just posted twelve different nests with different geometry each time to different file names with the 12G aluminum - FineCut Low Speed cut chart item in your JCM and it posted out fr=90 each time. When you noticed this happening are you looking at fr= in the gcode file or what qtPlasmaC is showing and not necessarily looking at the gcode? I wonder if something else is going on that's causing qtPlasmaC to part the comment wrong and I also wonder if it's related to the slow loading time,I just re-watched your video again.

These two problems may be related.

I think the next trouble step I need you to do is change your simplify tolerance too 0.002" and also try 0.003" and report back if the loading time is dramatically reduced. I'll note that I'm running on LinuxCNC (gmocappy) on my VMC and it could not care less about about a boat load of tiny line segments. LinuxCNC itself will choke planning tiny line segments but a ngc file with a boat load of them doesn't hang the loading of the file for 30 seconds. I also know there is a couple other folks running qtPlasmaC with JetCad3 right now and they have not mentioned anything out of the ordinary with load times. While I'm waiting for you to report back about how simplify tolorance affects the load time, I'll take a look at the qtPlasmaC source and see if that uncovers anything. I'll get to the bottom of this one way or another. I'm also going to be creating the GcodePilot LinuxCNC integration soon so JetCad3's GcodePilot workspace will essentially be an optional replacement for qtPlasmaC. While I'm working on that It may shed more light on whats going on here as it may be something LinuxCNC isn't light and not necessarily qtPlasmaC itself. The LinuxCNC NAML may be hanging somewhere through the pipeline and qtPlasmaC probably make those blocking calls on the rendering thread

I do know that QtPlasmaC parses the gcode. I forget what all the reasons are and what all it does, but it reads the entire file and is able to re-write some code on the fly during loading as needed. This is probably related to the slow loads. I'll try the tolerance setting and report back when I'm able to get to it here.