Advanced Search

Good job!

I've renamed my m-codes from the original example, and due to some jitter (servo dithering) when the motor/drive is in position mode I just leave the drive in velocity mode.  LCNC is switched between spindle/orient/positioning. 

My M-codes and main spindle HAL file are attached for your review; maybe they can help.

There is quite a bit commented out, but the gist of it is M254/M255 are used to switch between C-axis and spindle mode, using spindle-orient to realign the spindle before re-connecting the C-axis encoder.

M102 & M103 are 'backstage' M-codes used to adjust stepgen & c-axis PID settings (and disconnect index-enable) in a way you can't (I think) do from inside a normal .ngc g-code file.

Let me know if anything is really unclear.

That does not look bad but the max servo thread time shows the issue
( 1624528  clocks at 1.7 Ghz is ~.95 ms)

It may be that the CPU/BIOS-Setup are simply not capable of the needed
network performance for a 1 KHz servo thread.

A last ditch is to use a newer kernel as the 6.1 kernel in the LinuxCNC distribution
is fairly bad latency wise.

7.0.0-rc1-rt1 #1 SMP PREEMPT_RT 

Is the current one


 

whoops, sorry about that.
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 60060ms
rtt min/avg/max/mdev = 0.095/0.118/0.250/0.001 ms

The spikes in following error were indeed caused by graphics. It settled down when I removed one of 2 screens I had attached. Realtime delay error persists though.

Looks like you are pinging the host rather than the 7I97

One would like to have a speed output from the drive but there isn't one.

Should be possible to get rps or rpm in the frequency output
by setting proper scaling factor in frequency-scale. 
Have not tried it, though.

--- 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

Already did and left a copy on the NAS for archiving.

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.

 

It says 400V Open Circuit Voltage, but you have a 250V TVS.
Maybe the TVS can go after the voltage divider? Or have a 500V one and a second lower voltage one after the divider. I think that with the TVS after the divider the divider would limit the current through it, which might work better.

You should probably put an optical isolator on the SPI lines from the ADC, just in case things do go wrong on your HV board.

I think the only way to know would be to try it.
I doubt it would work with our Pi SD card image, and it doesn't claim to work with Debian:
"Supports Radxa OS, Ubuntu Linux, Qualcomm Yocto Linux, Armbian, Arch, Deepin, Fedora, Windows"

But if you can get a working Linux sysgtem on there, with a realtime kernel, then it will probably work with hal_gpio and hm2_eth