Advanced Search

If you could do the motion via a handwheel rather than a direct mechanical connection,
you could probably use external offsets to accomplish this motion without disabling the
drive.

papagno-source wrote:

But I don't understand where to connect: pos_fb_out

Looks like from your hal it should be connected to pid.2.feedback You want the component to sit between the motor feedback and the pid

As far as the enable input, I wasn't sure. I thought it might be connected to a button on your GUI.

Another left field but more work idea would be to add a 100 ppr MPG wheel and manually jog the axis by hand. There are hale examples in the docs

 

for the isolcpus, where would it show up? (the histogram or the text version)
I'll have to look at what I did in the grub there, I thought I had it right for a change...
NOPE, I screwed it up, TYPO in the grub section on my part
M


All fixed now that I spelled it right.
I'll run some testing tomorrow to see if the error is still there, not currently hooked to a machine so I can run on the bench without much fear
Thanks again
M
 

That all looks good, so stress testing or just normal use for not important stuff for a while till you are certain the error does not show up.
And, isolcpus is not active on you last screenshot.

I just feed the mpg counts to both the joint & axis pins and whatever selections for which step and which axis to both the axis and joint pins.
Never had a issue jogging before or after homing a
Or a MDI command. I'm pretty sure the docs mention this

Unless something has changed, I'm still on 2.9.4.

I actually modified a component I found, sorry I can't recall the original author, that takes all the mpg inputs, does all the selection logic then has pins for both axis and joint so it's just a direct connection to each halui pin. All the "messy stuff" happens in the comp and the Hal file is easier to read. Least for my poor logic.

rebooted here's the current results 
-- 192.168.1.121 ping statistics ---
60000 packets transmitted, 60000 received, 0% packet loss, time 59999ms
rtt min/avg/max/mdev = 0.066/0.106/0.296/0.017 ms
cnc@router:~/Downloads$ sudo chrt 99 ping -i .001 -q -c 60000 192.168.1.121
PING 192.168.1.121 (192.168.1.121) 56(84) bytes of data.

--- 192.168.1.121 ping statistics ---
60000 packets transmitted, 60000 received, 0% packet loss, time 59999ms
rtt min/avg/max/mdev = 0.065/0.107/0.287/0.018 ms

I wonder if I did it right, doesn't seem to have changed much since turning the cores all back on

the base thread tightened up,  servo thread is a little better as well

jitter looks way better, servo thread is still over 1000000, maybe I'll have to bump that up in the configuration

I'm shutting it down for tonight, maybe I can try some more tomorrow
Thanks for all the help, it's really appreciated
M
 

Run LinuxCNC with the card on, see if it faults or drop connection, while watching youtube and doing anything to stress the PC.
No need for the machine to be actually milling.

sudo ./pinirq.txt eno1
Cores: 4
Old CPU Mask: f
Set device eno1 IRQ 24 CPU mask to 8

Looks like it did something, how can I tell if it worked?
M

You can try this script to pin the IRQ:

 

Download and set as executable with chmod +x pinirq.txt before running:

sudo ./pinirq.txt [ethernet_device_name]

Where [ethernet_device_name] is something like eno1, eth0, enp2s0 etc

You can use 

ip a

To determine the realtime Ethernet device name by its IP address
 

Nope, can't get it to work. Thought it did but turns out I busted the last fix and it would work until a MDI command and then it would stop
M

altered the grub
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet isocpus=3"
GRUB_CMDLINE_LINUX=""

does that second grub_cmdline_linux="" wipe out the line before?


I read some of the doc on pinning but honestly I really got lost on how to actually get that done.
Is there a pinning for dummies file somewhere? (there was a few links to a doc by Rod but the link is dead)

Thanks again, rebooting.

BTW, what part of this am I looking to get better?

I got the program running.

I’ll have to sit down with some math and figure out the WHY, but the HOW is I set g54 z to two extreme values and worked my way inside those values until I didn’t get either a negative error or a positive error. 

I think the final value was 3.75 or something. 

I believe the required z travel for my program is just inside the soft limits. 

thanks for all the help. It’s nice to be making chips. 

I touch off G54, X=0, Y=0, Z=0.  Then I run my program, which uses G10 to set up work offsets, in theory every 30mm away from G54, each calling the same subroutine.  (Kinda weird subroutine: I'm trying to cut t-slots in the edge of oak and it tears out, so I'm finessing the toolbit into the wood.)

What I'm seeing is that I set all three axes at 0, then it switches to G55, and I very strongly think the G10 offset should read G10 L20 P2 X-30 Y0 Z0.  If I do that, it runs to X-30, Y0, Z3.  In all the subsequent, identical, work offsets, it also runs to Z3.
If I touch off X0 Y0 Z0 in G54, and then instead do, as the below program shows, G10 L20 P2 X-30 Y0 Z3, it runs perfectly.
I do not understand where three millimeters in Z is coming from, when both X and Y work exactly as I expected.
Is there a secret stateful variable somewhere I need to reset?

For that matter, is there a better way to do this?  This is my first time trying work offsets.  I've always previously either used a cam program or written multiple sites by hand as a single file without a subprogram, but I thought it would be fun to try learning work offsets.

Thanks for any advice.  LinuxCNC, version 2.9.6.

G17 G21 G40 G49 G80 G90
M08
G54
M05
M09M6 T1
G10 L20 P1 X0 Y0 Z0
G10 L20 P2 X-30 Y0 Z3
G10 L20 P3 X-60 Y0 Z3
G10 L20 P4 X-90 Y0 Z3
G10 L20 P5 X-120 Y0 Z3
G10 L20 P6 X-150 Y0 Z3

o199 sub

G0 X2 Y-20
G1 Z-8 F20
G1 Y-12 F10
G0 Y-20
G0 X3.237
G1 Y-12 F10
G1 y-20 F40
G0 x-3.237
G1 y0 F10
g2 x0 Y3.237 R3.237
g2 x3.237 Y0 R3.237
g1 y-20
g0 z2
o199 endsub

G55
o199 call
G56
o199 call
G57
o199 call
G58
o199 call
G59
o199 call

G0 Z10
G54 G0 X0 Y0

M2
 

I would use all cores but set isolcpus=3  in the kernel command line
otherwise you run all realtime and non-realtime code on the one core.
(plus reducing overall performance)

In addition, pinning the Ethernet IRQ to the last CPU (LinuxCNCs CPU)
will help with network latency.
 

Right now I've got it turned down to only a single. One of the many documents on tuning I came across seemed to want the 7010 to run with it set to single. I'll reset it to all in the bios and re-post


--- 192.168.1.121 ping statistics ---
60000 packets transmitted, 60000 received, 0% packet loss, time 59999ms
rtt min/avg/max/mdev = 0.065/0.102/0.281/0.018 ms

M