Advanced Search

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?

 

I'm not surprised I misinterpreted the intent of that pin.  The current state of in-drive homing code and documentation makes it a bit of an "adventure!"

So I've been cutting with no issues, recently cut a sign design that was 91.125" long Y axis metal came off the table at exactly 91.125" long. than last night I went to cut some basic holes and a piece that was 74 inches long with the metal pre-marked where the holes should be and noticed it was not moving to cut in that spot. verified the drawing and it was correct. ran the y axis from 0 - 36" and it ran to 36.25". short of redoing my config to get the correct distance again what would cause it to just say oh I'm not running on those numbers anymore. lol  I know it could be missing steps and if it is doing this is there a way to identify it. I wouldn't expect this to be the case as the distance is repeatable to the same distance each time. 

Is the Y properly calibrated? Yes

What hole processing does Pronest have? The defaut processing, into Pronest, I change the material and that's it
What diameter hole are you cutting? The last cuts were with 62mm hole diameter
What material and thickness? Same, the last cut were with midl steel, 15mm thick.

I wil try next time  reducing feed-rate to 60% and see. But I think it will be the same because i've got this issue also with straigt cuts

Thanks. I will keep trying. I had the exact same two lines in my code and it caused an error that states: m6remap remap error.

print("Before test code") <- This prints then the error text is next.
x = float(self.w.lineEdit_sensor_x.text())
y = float(self.w.lineEdit_sensor_y.text())
print("After test code") <- Does not print.

Parallel port tester is included with LinuxCNC, use the config picker to find it, it copies itself into your working config folder so you can edit it there, if needed.

Ok, I tried your lines out and LCNC gives me this erroro out:
"twopass: Error in file ./Hanno_Nr5_Neuer_Versuch1.hal:
Signal name 'spindle.0.on' must not be the same as a pin. Did you omit the signal name?"

The actual lines in my .HAL:
# ---digital potentionmeter output signals/setup---

setp hm2_7i76e.0.7i76.0.0.spinout-minlim [SPINDLE_0]OUTPUT_MIN_LIMIT
setp hm2_7i76e.0.7i76.0.0.spinout-maxlim [SPINDLE_0]OUTPUT_MAX_LIMIT
setp hm2_7i76e.0.7i76.0.0.spinout-scalemax [SPINDLE_0]OUTPUT_SCALE
setp hm2_7i76e.0.7i76.0.0.spindir-invert true

#net pdnt.spindle-speed-abs => hm2_7i76e.0.7i76.0.0.spinout
#net pdnt.spindle.is-on => hm2_7i76e.0.7i76.0.0.spinena # raus wg Problemen

net spindle.0.on => hm2_7i76e.0.7i76.0.0.spinena
net spindle-cw => hm2_7i76e.0.7i76.0.0.spindir
net spindle-vel-cmd-rpm-abs <= spindle.0.speed-out-abs => hm2_7i76e.0.7i76.0.0.spinout

# ---setup spindle control signals---

#net spindle-vel-cmd-rps <= spindle.0.speed-out-rps
#net spindle-vel-cmd-rps-abs <= spindle.0.speed-out-rps-abs
#net spindle-vel-cmd-rpm <= spindle.0.speed-out # raus wg Problemen
net spindle-vel-cmd-rpm-abs <= spindle.0.speed-out-abs
net spindle-enable <= spindle.0.on
net spindle-cw <= spindle.0.forward
net spindle-ccw <= spindle.0.reverse
net spindle-at-speed => spindle.0.at-speed

# ---Setup spindle at speed signals---
sets spindle-at-speed true

Did I do sth wrong?

Greetings,
Hanno
        

Can you guys review this and see if you agree?

Yes, that is correct. The idea is that we can set the homing type (ie one of the built in procedures or custom procedure) for each joint.

As described in the manpage:
linuxcnc.org/docs/devel/html/man/man9/homecomp.9.html

Todd wrote:

So It sounds like you are seeing parts of your code that are not reaching the programmed feed rate because of short line segments and acceleration limitations, but when you slow the feed override then those acceleration limited areas don't slow down the same as parts of your code that were not acceleration limited, is this correct? And you are asking for all parts of your code to slow at the same percentage regardless whether it was able to move at the programmed feed?
 

Yes, Exectly Todd, slow each gcode line with the same speed.

I did enough work in my new basemod.comp homecomp to prove that this works so I was correct. It makes the barest mods to the homecomp template. Its unfinished but feel free to look at this.
I am half thinking that the homecomp should let cia402 start the homing and then monitor the status word for target reached (bit 4)

github.com/rodw-au/cia402_homecomp

i do have both of these lines in my hal file