Hakan wrote:

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.

Should be possible

Hello guys,
im new in Linux CNC i wat to connect Linux CNC with my Spindel+YL620a Frequency Converter
via a 7i96s and failed. I dont understand what im doing wrong.....

I connectet the Components like the Picture.

Added this to the Hal
setp hm2_7i96s.0.pwmgen.00.output-type 1
setp hm2_7i96s.0.pwmgen.00.scale [SPINDLE_0]OUTPUT_SCALE
net spindle-vel-cmd-rpm => hm2_7i96s.0.pwmgen.00.value
net spindle-enable => hm2_7i96s.0.pwmgen.00.enable

Added this to the ini
MAX_OUTPUT = 24000.0
OUTPUT_SCALE = 24000
OUTPUT_MIN_LIMIT = 0
OUTPUT_MAX_LIMIT = 24000

Changed the Frequency Converter Settings like in the Picture.

Im grateful for any help or tips.

Thaks in advance
Tach0
 

Which series of drives do you have? If they are fibre-optic controlled, Dmitry has the cleanest, fastest solution to controlling the drives over the SSCNET III/H control fibres.

If they are copper controlled network drives, then Dmitry has a control for that as well, but you can also run the MESA cards for step/direction interfaces.

I thought I'd added my HAL file, guess not.

The M-code files still have remnants of my first attempt at switching the drive (internally) between velocity and position modes as in @Aciera's example.  That stuff is commented out; just ignore it if you aren't switching your drive.

If you ARE switching your drive internally, you'll probably want stuff like "M66, check for drive mode" in your M-code file.

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