Advanced Search

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


 

using the python interface for on the fly feedrate changes is a bad idea that is what the real time 'motion' pins are for:
linuxcnc.org/docs/html/man/man9/motion.9.html

Did you try with the drive disconnected?

That is measure TB3 pin 4 (AOUT0) relative to TB3 pin 3 (GND)
with the 4 pin connector unplugged. 

 

I don't think you can change acceleration settings during operation. The problem is that changing acceleration messes with the calculations that the tool planner has to make.

I don't understand are you saying that changing the feed override does not slow the machine? Unless you are referring to the feed of rapid positioning moves (G0) which are not affected by the feed override settings.

 
Hi,

Please can anyone share 7i95t pin and firmware files with Stepgens on 1,2,3,4,5,6,7,8,9,14,16,17 and Inputs on pin 10, 11,12,13,15 pins on 5Axis BOB.


 

I hope this message finds you well. the issue with my machine's feedrate and acceleration settings while using the Python module's feedrate function. Despite initially lowering the feedrate, I am still encountering problems where the machine achieve speed of 1500mm/min on short segments during 2D movements. This has led to some safety concerns, as the spindle has accidentally hit me on the head due to these high speeds.

To resolve this, I am trying to implement a feature where, upon pressing a push button, the machine would operate at just 10% of its maximum speed and adjust the acceleration to 10% of the set maximum acceleration, to tackle the 2D sort segment speed up very slow, with a hop i do not hit me again.

ve?

Forgot OpenCV, and use a barcode scanner.
I do this way to scan the worksheet and load the G-Code according to the type of part which I need to machine. The bar code scanner act as a keyboard, and I use a few python in the handler.py file to get what I need.

Hi,

I'm trying to change tool offsets on the fly, in order to use a grinding wheel with two workplaces, one at the front to machine my part, and one at the back to refresh the grinding wheel with the diamond wheel. For other reasons (I have 4 axis, X, Z, U, W and two grinding wheels attached, one on X,Z and the other on U,W), I can't work with the tool diameter (since I have two different diameters).

So, I want to change from +X offset to -X offset when I work at the front or at the rear of the grinding wheel. And that's where I try to switch with G10 L1 P1 X[#5401] but it doesn't work. As it may come from my setup, I gone back to simulation sample configuration. It works in Axis simulation sample, but not in QtAxis simulation, neither in QtDragon. So it seems to be related to Qt.

This is working in Axis but isn't in QtAxis or QtDragon :
G0 G54 X0
M6T1
G43
G10 L1 P1 X10
G43 (here G54(X) is 10)
(debug,#5401) (show -10)
G10 L1 P1 X[#5401]
G43 (here G54(X) is -10)
(debug,#5401) (show 10)

This is working in QtAxis or QtDragon (double call to G10 ) :
G0 G54 X0
M6T1
G43
...
G10 L1 P1 X10
G43 (here G54(X) is still -10)
(debug,#5401) (show 10)
G10 L1 P1 X10
G43 (here G54(X) is 10)
(debug,#5401) (show -10)
G10 L1 P1 X[#5401]
G43 (here G54(X) is still 10)
(debug,#5401) (show -10)
G10 L1 P1 X[#5401]
G43 (here G54(X) is -10)
(debug,#5401) (show 10)

I don't understand why I need to call G10 twice in order it works. Since I want to inverse the value, I'm not really confident in calling twice the function...

Any idea on what's is going on ?

Regards,

Ronan

I'll take a look at the branch when I get a chance.

Unfortunately I'm in the same boat in terms of not having been a NativeCAM user previously, so I'm not familiar with the nuances. About a year ago I did manage to hack-and-slash the old version to run on modern 2.9.x as a standalone app. Stuff was still broken but I could do the basics like define the workpiece, and create some basic ops.

Does anyone know the last LinuxCNC distro it was known to work on? If one of the old LinuxCNC ISOs works with NativeCAM, it's easy for me to spin up a virtual machine to test it out as it was intended.

Hi lcvette, Ok, so looked at the probe_basic.ini, and apart from the X axis, my setup is the same. Z is 0 to -ve, Y is 0 to -ve, and X is 0 to +ve. So apart from the X axis my information is the same. Is that your understanding?

No worries, I figured I'd ask in case it was something someone else has seen. I was doing some integration testing on the physical machine yesterday and it was behaving fine, so maybe it is just a Virtualbox problem.

PCW wrote:

Yes, 7I96/7I96S TB3 pin 12 is the input common.
Isolated inputs accept +-5 to +-36V signals relative to input common.

If you connect +24V to input common, the inputs will be activated
when grounded (connected to the 24V negative output) This
is the normal way to setup the input for NPN sensors
(or switches with a common ground)
 

Good evening PCW,

Thank you for your help. I have attempted to draw how I would wire up NPN NO switches to the Mesa 7I96S.

I will have 8 NPN NO sensors (www.makerstore.com.au/product/elec-lj2a3/), but in the drawing I show only two.

Would you be able to check if I am wrong, please?



Thank you and best regards,

...behai.

So i was watching the pid.x.output in halshow and it pretty quickly ramps up to 10 in an effort to correct the position error.But... I am showing only 10-12 mV coming from the card to the drive.