QtPlasmac problems

I have been using a very old Plasmac version from 2019 and although I alway planned to upgrade it, it just worked so got put off. A month or so ago I turned on my plasma only to find the hard drive had failed. I fitted a new ssd and did a build of QtPlasmac with Debian 12 bookworm. Although I got the machine working as such, I have a couple of issues that I am stuck on;

Using the same PC I used previously without issue, I now regularly get errors like 

“Mon24 13:59: Unexpected realtime delay on task 0 with period 1500000
This Message will only display once per session.
Run the Latency Test and resolve before continuing.
Mon24 13:59: hm2/hm2_7i76e.0: Watchdog has bit! (set the .has-bit pin to False to resume)
Mon24 13:59: hm2/hm2_7i76e.0: Smart Serial port 0: DoIt not cleared from previous servo thread. Servo thread rate probably too fast. This message will not be repeated, but the hm2_7i76e.0.sserial.0.fault-count pin will indicate if this is happening frequently.”

I have tried the period setting at 1000000, 1500000, 2000000 etc latency test is around 35000. 



the other major issue is that I can’t cut anything that has an arc unless I use the QtPlasmac conversational. My sheetcam produced code just generates errors like

--- QtVCP Screen Started on: Mon, Feb 24 2025 13:12:29 ---
--- CNC_Plasma - QtPlasmaC v2.9-236.301, powered by QtVCP and LinuxCNC ---
Mon24 13:12: Tool 0: No Tool
Mon24 13:14: Loaded: /home/darren/linuxcnc/nc_files/examples/Darrens Gcode Files/Motor Moutn Blue Mill/10mm motor plate Arc Lead (SMM).ngc
Mon24 13:14: G-Code error in 10mm motor plate Arc Lead (SMM).ngc
Near line 42 of
/tmp/emcflt-m50pkakv.d/10mm motor plate Arc Lead (SMM).ngc
Radius to end of arc differs from radius to start: start=(X31.0695,Y19.2947) center=(X29.4735,Y20.3617) end=(X29.6980,Y20.4360) r1=1.9198 r2=0.2365 abs_err=1.683 rel_err=87.6824%

I have ensured G91.1 is active and all the holes entries are # out in the nc file. 

Can anyone point me in the right direction? I can provide any extra info needed


 

The first problem is real time issues with the network interface.

To get a rough idea where things are, can you run these two commands and reply with the results:

sudo chrt 99 ping -i .001 -c 60000 -q 10.10.10.10

This will run for 1 minute and print statistics
(replace 10.10.10.10 with 192.168.1.121 if that's the 7I76Es address)

lspci | grep -i eth

(this should make it possible to determine the PCs Ethernet interface type)

Thank for the reply

Ping stats 0% packet loss
Min/avg/max/mdev = 0.081/0.258/0.339/0.017 ms

Ethernet controller is intel 82579LM gigabit network connection (lewisville) (rev 4)

I see from other posts that with intel network card I should disable IRQ coalescing. I will try that in the morning and repeat the ping test

Ok so disabled the irq coalescing.  ping stats are pretty much identical and I still get the same realtime errors popping up.

I am also attaching the sheetcam code that generates the “ Radius to end of arc differs from radius to start:” error. I have tried with a number of different gcode files and if they include arcs they result in the error. I added in the G91.1 to see if it fixed it, it didn’t

 

Ok

issue of not being able to cut arcs due to radius error is sorted. User error as normal. For some reason I had it in my head that the statements in the gcode regarding the hole processing were commented out with a #. When I did actually comment them out with a ; the code loaded and ran with no issue.

the realtime error is possibly resolved but will know for sure when I do some more cutting tomorrow. I changed the Ethernet cable and also removed the WiFi nic. Will do more testing tomorrow and update the post if I can confirm which cured the issue, if it is cured that is.

There are some variables at the top of the shetcam post processor that allow you to prevent generation of the hole data if you don't want to use it.

Thanks Rod

Yes the hole processing variables are what I commented out in the g-code, the intention being to edit the PP as needed once I had proved it resolved the issue. I can confirm after setting the hole cutting variable in the PP  to = 0 all now works as expected.

Unfortunately the realtime comms problem is still evident. I have had 3 Ethernet leads so fairly sure that’s not the problem, the Ethernet nic is the only one now in the system so nothing there to interfere in any way. I have a static address, irq coalescing is disabled, the problem happens even when the plasma arc is not active so it’s not interference from that.
i never had any issues with realtime before the upgrade

Mon24 13:59: hm2/hm2_7i76e.0: Watchdog has bit! (set the .has-bit pin to False to resume)

Indicates relatively huge network latency (>5 ms if the watchdog setting is the default 5 ms)
That sounds like maybe a power management issue so you might try adding pcie_aspm=off
in your kernel command line.

What is the current kernel command line?
 (cat /proc/cmdline)