Advanced Search

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

 

There's always the possibility of installing MATE, but unfortunately the Debian setup of the Menus and panels isn't as nice as Mint's setup.

The i5 3470 is a four core chip.

Might be worth checking your BIOS to see if there is a setting that either enables or disables the 4 cores.

Thumbs up to the old timey British sayings.

Another I like is "proper poorly" but I've been told is a more Northern thing.

I ran it a couple of times
cnc@router:~$ 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.074/0.086/0.256/0.008 ms
cnc@router:~$ 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.074/0.086/0.377/0.008 ms

The histogram l ran on it's own and with 5 gears running

Nope, the network driver needs to be changed, installing the DKMS version of the Realtek drives should fix it.
Give this a try:

I have after many, many tries still cannot get the versaProbe actions to work properly. So I added some logging.

Please refer to this image inline.

 

1 issue and another oddity.

1st issue, note the lines that I have added to the qt_auto_probe_tool.ngc file in order to log and hopefully put an end to the first probe try failing.
The question, why is there a space that's being added to the filename when it's written to file?

The second is similar to a thread that I started many moons ago and still exists. In the image I point out what is actually logged in the file. It begins with this code in the aforementioned file:

touch_result= 161.824940 
calculated_offset= [161.824940 - -132.110000 + -106.700000] 
Probe Height: -132.1100
Block Height: -106.7000
Probe Result: 161.8249
Calculated Offset: 187.2349

I don't understand the calculated_offset line which includes a double negative.

Now then, in this same file I see the following reference prior to code being executed and for some reason it's almost as if these instructions are either out of order or are incorrect. Preceding numbers are actual line numbers.

16 ; The following settings should be enabled in the QtDragon interface:
  17 ;    A -  Under Probe Tool screens: insure that "Tool Measure" is enabled
  18 ;    B -  Under Settings: insure that "Use Tool Sensor" is enabled
  19 ;  The following workflow assumes using both a XYZ probe and a Z Toolsetter:
  20 ;    1 - Initial Setup: Before beginning the program, setup the Probe Tool as
  21 ;        having a zero z-offset in the tool table. (Non-zero tool lengths
  22 ;        for the probe tool can be made to work, but have multiple extra
  23 ;        steps required, and it is easy to have the tool offset interfere with
  24 ;        the remap coding and cause incorrect adjustments to your offsets.
  25 ;        This procedure assumes a zero length.)
  26 ;    2 - Initial Tool: Load the probe tool with M61 Qx, where x is the Probe tool's number
  27 ;        in the tool table. (Do not use TxM6)
  28 ;    3 - Toolsetter measure: Use button under the Probe Screens for "Probe Tool Setter
  29 ;        Z Height:" this will set and display on the Probe Settings screen the
  30 ;        "Probe HT" = #<_hal[qtversaprobe.probeheight> value in ABS coordinates.
  31 ;    4 - Workpiece Measure: Use the button under the Probe Screens for "Probe Z height
  32 ;        of material:" this will set and display on the Probe Settings screen the
  33 ;        "Block Ht" = #<_hal[qtversaprobe.blockheight]> value in ABS coordinates.
  34 ;    5 - Set Coord System (G54): Use the Probe Tool and whichever probe screen is
  35 ;        appropriate to set the coordiate system XYZ offsets needed for your job.
  36 ;        NOTE: Return_Option 3 uses the current local coordinate system, not just ABS coord.
  37 ;    6 - Prepare to Run: You may then issue a manual TnM6 command to change the tool
  38 ;        before starting the job, or if the job begins with a TnM6 command before
  39 ;        spinning the spindle, you may leave the Probe Tool installed.

And last I would like to know (if the above instructions are correct) what are "sane" values that belong in the my_machine.ini file?

Mine are as follows:
Max Z travel for Z-Axis is: -190
[VERSA_PROBE_OPTIONS]
 ps_probe_tool = 99
 
 [VERSA_TOOLSETTER]
 X = 14.68
 Y = 43.934
 Z = -55
 # Safe Z-Height, in Absolute coordinates.
 Z_MAX_CLEAR = -5
 # MAXPROBE must be positive!!
 MAXPROBE = 80
 # tool setter diameter for diameter probing
 DIAMETER = 22

 [CHANGE_POSITION]
 X = 200
 Y = 20
 Z = -5

Note that MAXPROBE in the LinuxCNC online documents still indicates a negative value of -20.

Thanks in advance for your feedback.