Advanced Search

Is the above line from apt my clue?

The problem that is fixed by the DKMS driver has fairly specific symptoms.

can you run:

sudo chrt 99 ping -i .001 -c 60000 -q 10.10.10.10
 (will run for ~ 1 minute)

and post the stats here

(assuming 10.10.10.10 card address)

Lcvette wrote:

in probe basic? i don't recall ever having a feedoveride via shift. i do not see anything to that effect in the code. was this in a different ui?

It is not a cancellation, it is a speed increase. When you press the keys to move along the axes it moves at a speed of, for example, 360 and when you press the shift key + the movement key it moves at a much higher speed. I have always used that in probe basic and in any other Linuxcnc interface. but since update 2.9.4 it doesn't work for me.

just draw it out and if it looks right you are on the right track. if the jog directions corresponds to spindle motion through the tables work envelop, you have it correct. where the home origin is is just the defining point of the machine reference from which all other settings are predicated on. so where ever your origin is the min/max travels are from that point to the opposite side of the cartesian coordinate system.

Mine mesa ethernet card has interrupts on cpu0 how can move it to cpu3 isolated for linuxcnc ?

You can temporarily check if this helps:

 

first

chmod +x pinirq.txt

then 

sudo ./pinirq.txt [ethernet_device_name_]

Where [ethernet_device_name] is the name of the Ethernet device connected to the 7I96S
(probably eth0, eno1 enp0s25 or similar)
 

the installation is pretty well locked down, the issues come from configuration setup. if you are starting from an existing gmoccapy config you will need to use the docs for machine configuration setup to guide your transition. always start with testing to see if the sim works as expected, if it does but you have issues with your machine config its a good indicator you missed some items.

the required PB config bits are NOT optional, do NOT skip the reading as there are things in the reading that are required to be done. its a short one pager so just be diligent.

if using gmoccapy and you have ots of custom hal files and such be sure you remove anything that may conflict with probe basic in hal. if you miss one you will get an error telling you the conflict.

thre can be only one post gui hal call in the ini. so if you have anything you need to keep from your existing post gui hal file, you will want to consolidate the items into the probe basic post gui hal file or read the linuxcnc docs on how to call any other post gui hal files from within the main PGHF.

in probe basic? i don't recall ever having a feedoveride via shift. i do not see anything to that effect in the code. was this in a different ui?

Almost 3 years later and I still have hm2/hm2_7i96s.0:error finishing read!

Grub quiet isolcpus=11 idle=poll r8168.EEE=0 pcie_aspm=off

john@cave:~$ sudo ethtool -i enp6s0
[sudo] password for john:
driver: r8169
version: 6.1.0-29-rt-amd64
firmware-version: rtl8168e-3_0.0.4 03/27/12
expansion-rom-version:
bus-info: 0000:06:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
john@cave:~$ uname -a
Linux cave 6.1.0-29-rt-amd64 #1 SMP PREEMPT_RT Debian 6.1.123-1 (2025-01-02) x86_64 GNU/Linux

The r8168-dkms network driver is installed but ethtool reports the driver as r8169

This package provides the dkms source code for the r8168 kernel modules.
Kernel source or headers are required to compile these modules.

Is the above line from apt my clue?

JT

Hi,

Related to the 3d clothoid corner fitting i had to do some extra programming work.
In the abstract a example is given for arc and line :

 
This involves eq30 page 5.
There it calculates theta, kappa, sharpness at a given arc point. So far so good.

However, sinds linuxcnc uses arc & arc-helix solutions given a G2 or G3, above eq30 is not valid to integrate in linuxcnc.
The clothoid should not fit ok on a helix. What now?

To make it valid, we have to code the theta, kappa and sharpness for a helix at a given helix point.
Then the 3d clothoid can be attached to the helix flawless.

I made a tiny picture to show the 3d helix properties, and what we are dealing with :
 

The detail is also that the 3d clothoid input requires theta_z and theta_xy input's.
These are derived from the tangent T in the picture. Wich is a tangent decomposition.

All this code is done from scratch and vector based. In this we are not limited to G17, G18, G19 planes.
Soon we can validate the helix code output.

what else should i check for

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

I'm using the following hardware for my lathe:
Lenovo Yoga with i5-5200 2 core
Mesa 7i96s - with 3 encoders, 2 MPG's , 2 servo drives and all I/O

With stock BIOS settings I was getting the pop up latency warning, with revised BIOS settings the warning appears to be gone.
BIOS setting changes that seemed to make a difference:

• All power saving - disabled
• Hyper-threading - disabled
• Intel Network Frame Forwarder - disabled

Pre BIOS changes: (all times in uS)
                          Max int         Max Jitter
Servo thread:    1019             51
Base thread:     182               158

Post BIOS changes: (all times in uS)
                          Max int         Max Jitter
Servo thread:    1009             51
Base thread:         45             24.7

A few questions:

1. It's not clear to me how critical these results are when using a 7i96s for encoder and step generation?
2. Max jitter for the servo thread seems quite good, however base thread seems marginal, comments please?
3. I did not mess with isolcpus, and I'm not sure how or if I should?