5i24 substitute using ethernet?

Thanks Peter.

Pin out file attached.

Bit file also attached, but with appended .txt extension to allow attaching.

I think that avahi error means some kind of host network setup error (I've seen this before but I cannot remember the exact cause) It was fixable with the network manager or the interfaces file

I'll take a look in those areas. Wondering, if it does come to mind, could you let me know pls?

Again thanks,
Marty.

OK thanks, I'll try and get to this sometime today



Note that this has the DPLL added

Hi Peter.

I have installed the 7i80 and have setup the .hal syntax accordingly.
The mill is running, all tested functions and IO's are thus far working correctly, including table movement.

But... the spindle RPM overshoots target much more so than previously with the 5i24.
Also, when an orient cycle is called (M19 for tool change alignment), an S30 is used until the hall effect sensor is detected. In this case the M66 has previously had a 5 second wait time to "see" the sensor whilst the spindle runs forward at 30 RPM. But, after 7i80 install, the spindle (which is analogue controlled from the 7i47s) is so slow to start spinning up towards 30 RPM that the M66 times out. From this I also suspect that the reason that spindle is overshooting more than it used to with the 5i24 is a slow start/acceleration and corresponding wind-up and overshoot ensuing.

The 7i47s board power is 5v from the mill's power source (atx power supply) as it always has been. The analogue spindle 7i47s "potentiometer" legs are separately powered from the spindle VFD 10v output, with analogue command output going back to the spindle VFD. The only difference now is that whereas before the 5i24 was powered from the internal PC power supply, now the 7i80 is on the same 5v rail as the 7i47s board power input (from the machine's ATX power supply). I read the 7i80 specs, in that, it may draw up to 5A. I will check for voltage drop through the 7i47s aux 5v power input, thinking that the 7i80 current draw may be affecting the PWM function of the 7i47s analogue spindle control??

Overall, same .hal, same .ini etc etc, but more sluggish performance, seemingly different spindle PID settings needed as there is a distinct change in spindle behavior with the change from 5i24 to 7i80 boards.

So the question is, what could be causing this, as the .hal and .ini (and thus PID settings) are the same as before the change from 5i24 to 7i80.

Am thinking to return to the 5i24 (which shouldn't take to long) to confirm the behavior returns to pre-7i80 to help eliminate causes.
Am also thinking to try with a different PC to exclude that, as this is a different pc than the one which is running the 5i24.

Thanks,
Marty.

There should be no difference so I think its definately worth going back to check the 5I24

Another possibility is that you changed LinuxCNC versions and there is a change in the PID
component relative to the command derivative input pin. If you connect to this pin
there will be some change in tuning. (you can get the old behavior by disconnecting the pin in hal)

Hi Peter.

Did some testing, results below.
Originally using Wheezy, with LCNC 2.7.14, 5i24.
Tried with Stretch (from the ISO) with preempt kernel, using both the same machine and another.
Using both 5i24 and 7i80.
Results:
Original wheezy and PCI fine. With an S30 M3 spindle starts rotation immediately.
Stretch with PCI, same as above i.e. fine.
Stretch with ethernet on same machine, S30 M3 takes spindle 4-5 seconds to start.
Stretch with Ethernet on a different machine, S30 M3 takes spindle 4-5 seconds to start.

In short, whether using Wheezy (RTAI) or Stretch (Preempt) (and both LCNC 2.7.17) via PCI the spindle is fine with no startup lag. When homing the process and axis’ are smooth.
Whenever ethernet is introduced via the 7i80 (and necessarily using stretch with the preempt kernel), regardless of machine, there is a real lag with the spindle starting at low RPM (some 4-5 seconds before rotation starts). When homing the axis’ have a mild thump.
I would love to try Wheezy with its own preempt kernel, but this is not possible anymore given EOL.

Just spit-balling but:
Is there a latent clock speed difference between the PCI card vs the ethernet card?
Is there any way that a PWM controller is off? Via the 7i80 bit file or otherwise??

Very curious given using same HAL, same INI (and thus same PID settings etc)
Other than:
5i24
loadrt hm2_pci config="firmware=hm2/5i24/5i24_16_svssst4_8_4_7i47S.BIT num_encoders=8 num_pwmgens=5 sserial_port_0=200xxx"
setp hm2_5i24.0.pwmgen.pwm_frequency 20000
setp hm2_5i24.0.pwmgen.pdm_frequency 6000000
setp hm2_5i24.0.watchdog.timeout_ns 5000000

7i80
loadrt hm2_eth board_ip="10.10.10.10" config=" num_encoders=8 num_pwmgens=5 sserial_port_0=200xxx"
setp hm2_7i80.0.pwmgen.pwm_frequency 20000
setp hm2_7i80.0.pwmgen.pdm_frequency 6000000
setp hm2_7i80.0.watchdog.timeout_ns 5000000

And associated syntax (all references to 5i24 and 7i80 interchanged for the respective HAL files)
No command deriv pins used (only feedback deriv for encoder velocity feedback)
All using LCNC 2.7.14

S30 is used as it is the RPM used for homing and tool change. (in fact the M66 times out before spindle rotation starts and it finds the sensor when using the ethernet card). Also, it is seemingly the easiest comparator to use as one can clearly see the current difference between the two set-ups.

Original Set-up
Dell 790
PCI 5i24
Wheezy 32 bit
RTAI kernel
Linuxcnc 2.7.14
Spindle:
Give S30 (RPM used to orient for tool change) – no lag to commence rotation
Axis homing smooth

Tried – Original Setup with PCI (5i24) but using Stretch
Dell 790
PCI 5i24
Stretch ISO
Preempt RT Kernel
Linuxcnc 2.7.14
Spindle:
Give S30 no lag to commence rotation
Axis homing smooth

Tried – Original Setup with Ethernet (7i80) using Stretch
Dell 790
Ethernet 7i80hd_16
Stretch ISO
Preempt RT Kernel
Linuxcnc 2.7.14
Spindle:
Give S30 large 4-5 sec lag to commence rotation
Axis homing thumps

Tried
Dell 9020
Ethernet 7i80hd_16
Stretch ISO
Preempt RT Kernel
Linuxcnc 2.7.14
Spindle:
Give S30 large 4-5 sec lag to commence rotation
Axis homing thumps

Very odd, can you do a calibration check of the analog output?

The PWM base clock is different on a Ethernet card vs a PCI card (200 MHz vs 100 Mhz)
but the driver takes this into account.

Can you post your hal/ini files?

Peter,

For interest:
I didn't recall I had access to it, but I was able to use a Wheezy with preempt kernal just now (I borrowed the SSD from my lathe which runs a 7i76e).

Got "unexpected realtime delay" message and "smart serial doit not cleared from previous servo thread. Servo thread probably too fast."
This was on the same PC (Dell 790) which is running the PCI card fine.

As a thought, given what you said above regarding PWM clock speeds, from my HAL:
setp hm2_7i80.0.pwmgen.pwm_frequency 20000
setp hm2_7i80.0.pwmgen.pdm_frequency 6000000

Could this be overriding the driver?

Beyond this, what do you mean by a calibration check of the analogue output? Physically check voltage of the "legs" and the "wiper" in relationship?

hal/ini attached.

Thanks for your help Peter!

Yeah just check the analog output voltage of the spindle when set by hand

I wonder if you are losing packets, can you run for a while and post the results of

halcmd show all *tmax*

I suspect you have intel MACs on the Dells, have you set the irq coalescing off?
(something like "sudo ethtool -C eth0 rx-usecs 0" with eth0 replace with your realtime Ethernet name)

It is interesting,also on start up, with one press when I press the GUI estop button to start the machine, I get about 3 "Error : External ESTOP is set, could not change state" in quick succession before the machine starts immediately thereafter.
The external estop is located on the sserial bus, on one of three 7i84's.

I'll try using sudo ethtool -C eth0 rx-usecs 0
To confirm, this goes into the etc/network interfaces file?
I have tried that via terminal but it doesn't recognize ethtool command

Will this line still work to set irq coalescing off gien that Network Manager is controlling the connections
/etc/NetworkManager/NetworkManager.conf

[ifupdown]
managed=true

Put the ethtool -C eth0 rx-usecs 0 phrase in the etc/network interfaces file, but to no effect.
ip link show indicated eth0, so that is what I went with...

The results of the tmax is attached.