Advanced Search

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?

 

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