--- 192.168.1.120 ping statistics ---
60000 packets transmitted, 60000 received, 0% packet loss, time 60060ms
rtt min/avg/max/mdev = 0.017/0.018/0.079/0.001 ms

All power management disabled.
IRQ coalescing disabled.
pinning the Ethernet IRQ to the last processor does not affect, still getting realtime delay message.
Also tried without hm2.read-request.

I just managed to verify the cause for the spikes visible in halscope. They appear to happen the same interval than the pyvcp graphics refresh. I just can't figure out if it's more of a symptom than a cause.

I found the error on my part just minutes ago. I had set HOME_SEARCH_VEL != 0 and that was the issue. Caused half a day of headache for myself, but now the C axis homes and after a few tweaks responds to commands to some extent, yay

I was homing it from the gmocappy GUI and now the homing bit works great! Now the other problem is with the mcodes and remaps. Calling m419/420 causes errors with "ngc file ended with no % sign or program end" and unknown m119/120 code. Will try to figure that out next.

I have to thank you and Aciera as your work let me actually attempt this

I based my C-axis config on Aciera's example as well; he really saved my bacon discovering the index-enable synchronized motion bug.

I don't see anything really obvious in your config at first glance...you've got HOME_USE_INDEX in INI set right...

Index-enable signal appears to be connected to everything:

• encoder
• spindle
• orient
• joint
• pid-spindle
• pid-orient
• pid-axis

Have you tried orienting the spindle yet?

How are you trying to home joint 2?  Home-all, or just that joint/axis?  halui or something else?

What actually happens when you try to home joint 2?  Keep spinning forever, doesn't move, or something else?

Just for reference, my config starts up in C-axis mode, and there are (software) restrictions so I can't put it in spindle mode until the Caxis is homed.  
I could post my config, but it's really complicated and not in a final-final state just yet.  If you/we cant get yours sorted out quickly I'll post it for you to try to digest.

i see, will look at it too. Was the HF start giving you issues with THC?

read-request is only intended for use with multiple Ethernet cards

What does:

sudo chrt 99 ping -i .001 -q -c 60000 10.10.10.10

report? (it will run 1 minute and print timing statistics)

(replace 10.10.10.10 by card IP address if that differs)

Is all power management disabled in the BIOS?

If the PC has a Intel MAC have you disabled IRQ coalescing (man hm2_eth)

One further step is to pin the Ethernet IRQ to the last processor
 

Arc voltage is DCEN, that is, between -400V and 0V.
The torch is negative, ground is positive.
Not saying that the below is correct. It has worked for me for many hours though.



github.com/MetalMusings/MyOwnEtherCATDev...in/Cards/THTIC/Kicad

First hello everyone, my first post here.

I'm currently trying to make a Schaublin 110 retrofit work and using the config from here github.com/LinuxCNC/linuxcnc/issues/3556 as a basis to try and make the C axis functional, however I cannot get it to home. The c-index-enable signal and all corresponding ones are not set to true when homing. I can set it manually in halshow and the axis will reach the index point, but then it resets it before it latches again. I went through everything to the best of my extremely limited ability but can't figure it out. The things I've changed were that C axis is now on Joint2.

 

Halscope screenshots of spiking attached. These are captured having [HMOT](CARD0).read-request at the beginning and at the end of servo-thread. The following error spikes go crazy when read-request at the end but also visible when at the beginning. When servos are stationary no spiking.

Hello. 

I'm having hard time getting Linuxcnc run without "Unexpected realtime delay on task 0 with period 1000000". What I have tried so far is the "regular" isolcpu approach: 

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash isolcpus=5 nohz_full=5 rcu_nocbs=5 irqaffinity=0-4 intel_idle.max_cstate=1 processor.max_cstate=1"

Also tried to isolate cpu number 4, no difference.

packet error-total stays at 0.

I tried to add [HMOT](CARD0).read-request servo-threadin the end of the servo-thread. That makes read.tmax drop significantly and realtime delay error does not appear but causes weird spiking in servo-thread.time when any of the axis(or spindle) is moving. The spikes also appear as joint following error. So maybe it's only hiding the problem from servo-thread?

Here are .tmax's, i know theres a lot of them but the problem was there right from the beginning when there were not so many.
Parameters:
Owner   Type  Dir         Value  Name
   207  s32   RW          13227  air-pressure.tmax
    73  s32   RW           9832  and2.0.tmax
    73  s32   RW           4353  and2.1.tmax
    73  s32   RW           7964  and2.2.tmax
    73  s32   RW          10403  and2.3.tmax
    73  s32   RW           5666  and2.4.tmax
    73  s32   RW           7674  and2.5.tmax
    73  s32   RW           7831  and2.6.tmax
    73  s32   RW           4339  and2.7.tmax
   207  s32   RW          16332  axes-power-rdy.tmax
   207  s32   RW          12813  c-drop.tmax
    52  s32   RW         138371  classicladder.0.refresh.tmax
   207  s32   RW          10878  coarse-filter.tmax
    82  s32   RW           7483  comp.0.tmax
    82  s32   RW          13396  comp.1.tmax
    76  s32   RW          14106  conv-s32-float.0.tmax
    76  s32   RW          12091  conv-s32-float.1.tmax
    76  s32   RW          15938  conv-s32-float.2.tmax
    76  s32   RW          10591  conv-s32-float.3.tmax
    76  s32   RW           6288  conv-s32-float.4.tmax
    76  s32   RW           4193  conv-s32-float.5.tmax
   207  s32   RW          19851  fine-filter.tmax
    46  s32   RW         195887  hm2_7i97.0.read-request.tmax
    46  s32   RW        1370631  hm2_7i97.0.read.tmax
    46  s32   RW         272796  hm2_7i97.0.write.tmax
    88  s32   RW          31149  limit3.0.tmax
    88  s32   RW          22704  limit3.1.tmax
    39  s32   RW          37291  motion-command-handler.tmax
    39  s32   RW         185440  motion-controller.tmax
    94  s32   RW           5629  mult2.0.tmax
    58  s32   RW          12861  mux2.0.tmax
    58  s32   RW           2823  mux2.1.tmax
    61  s32   RW          13096  near.0.tmax
    61  s32   RW          11833  near.1.tmax
    91  s32   RW           5106  not.0.tmax
    85  s32   RW          14364  oneshot.0.tmax
    85  s32   RW          11632  oneshot.1.tmax
    85  s32   RW          17464  oneshot.2.tmax
    85  s32   RW          14563  oneshot.3.tmax
    85  s32   RW          12845  oneshot.4.tmax
    70  s32   RW          10989  or2.0.tmax
    49  s32   RW          36452  pid.s.do-pid-calcs.tmax
    49  s32   RW          30455  pid.s_orient.do-pid-calcs.tmax
    49  s32   RW          33685  pid.x.do-pid-calcs.tmax
    49  s32   RW          16981  pid.y.do-pid-calcs.tmax
    49  s32   RW          28642  pid.z.do-pid-calcs.tmax
   207  s32   RW          11362  probe-batt.tmax
   207  s32   RW           5467  probe-motion-inhibit.tmax
    79  s32   RW          35861  process_wsums.tmax
    67  s32   RW          12354  scale.0.tmax
    67  s32   RW          22722  scale.1.tmax
    67  s32   RW          14129  scale.2.tmax
    67  s32   RW           6315  scale.3.tmax
    67  s32   RW          13441  scale.4.tmax
    40  s32   RW        1624528  servo-thread.tmax
   207  s32   RW          11772  spindle-lube.tmax
    55  s32   RW          12661  sum2.0.tmax
    55  s32   RW          10884  sum2.1.tmax
    55  s32   RW          15876  sum2.2.tmax
    55  s32   RW          19655  sum2.3.tmax
    55  s32   RW           6870  sum2.4.tmax
   207  s32   RW          21391  transf-over-temp.tmax
    64  s32   RW          13011  tristate-bit.0.tmax
   207  s32   RW          22251  x-encoder.tmax
   207  s32   RW           7564  y-encoder.tmax

processor: Intel(R) Core(TM) i5-8400T CPU @ 1.70GHz

Thanks in advance for anyone trying to help, i've been struggling with this a good couple of weeks now.
Regards
Ossi

rodw wrote:

While there would be  a bit of re-wiring to use a 7i96s natively, you could end up with a cleaner wiring if you had the room and possibly elimination of some relays etc.
I did help someone do this a long time ago and it was pretty simple. Took  a couple of hours including adding limit switches. Just make a very basic/rough config with pncconf and edit the STEP_SCALE in the ini  file so it is the same as Mach's stepsper value. 

First of all: Thank you very much! image missing /media/kunena/emoticons/laughing.png It was your youtube channel, Debian Trixie and LinuxCNC, that got me going with LinuxCNC and brought me to the point of looking into a 7i96s.

I know that I can optimise by removing some of the existing electronics. I have considered it but the main argument of not going that road is that it is a table top CNC machine, small, reliable and a complete system. Optimising anything byound the D25 parallel port connector will make that machine no longer compatible with the manufacturer model. When, some time in the future, I want to sell this one I have to undo the changes first.

If there are serious performance issues I still have to option of bypassing the manufacterer hardware (or sell this one and get something else).

Again, thank you for the suggestion.

Kind regards, Andre.

 

There is a Beckhoff StepGen module for the ek1100 but its pretty expensive. Most people would use a seperate Ethercat driver from Lichuan, Leadshine or Rtelligent. From experience, I do think it would be a better bet to buy a kit with matching motor and driver to avoid compatibility issues. Lichuan have a 4 axis driver and I think also Nema17 and Nema23 options.