Wow, that is quite a beast of a machine!!! Please keep adding to this thread with your photos and experience with it. Great reading.

7i76eu_7i76x1_pktv3d.bin

 or

7i76eu_7i76x1_pktv2d.bin

For older LinuxCNC distributions

I mentioned this here: forum.linuxcnc.org/39-pncconf/58480-conf...g-dual-y-axes#344832

I have "write a better debounce module" on my todo list. No guarantees

I would  first, disconnect  the encoder, jumper the encoder inputs for TTL mode
and then test the A,B and Index inputs by grounding the A+, B+ and INDEX+ pins
and watching the hal pins for these in halshow. They should change polarity when
grounded vs open.

The 7I96/7I96S encoder inputs are normally fairly rugged but can be damaged by EMI spikes
of greater than 25V. This can happen in a test setup where VFDs or spindle motors couple
the 400V or so square wave drive power into the encoder signals because of insufficient
grounding/shielding.

The Encoder input chip on a 7I96S is a 26LS32 (U12)

grandixximo wrote:

Would love to have a logo for linuxcnc-ethercat to match
 

I made one, and to be honest, I’m actually quite proud of it . However, I’m a bit hesitant to publish it. As far as I know, the EtherCAT logo is protected.

Please try to provide a program excerpt. I would like to take a look at it and test it on my system.

bookworm

what debian flavor?

Hello.
One 7i96s card on a lathe lost the encoder signal (it cames from a spindle driver on a differential line - as on 4th page ).
An other 7i96s card  ("from the box") has the same issue with the encoder and has the new W7 jumper for RS-485 - not used yet, just powered on)
I have connected a TTL encoder for test - that is why the jumpers on left hand.
On the table one card works, so i replaced it. But now i have a used (± a year) card, and a new one with no encoder input. We using them for lathe, so we need the encoder input for threading.
Can it be solved somehow? Re-soldering a component?
     
   
 

I guess tomorrow I’ll reboot the machine’s computer to version 2.9.8, reinstall the real-time kernel, and apply all the updates—but won’t that be version 2.9.x? And I’m ready to try running the cycle. If you could provide a link to the 2.9.x build for the real-time kernel (or userspace), I’ll be able to test it.

The axis desynchronization issue was caused by an error in my INI configuration—the parameters I had set required a frequency higher than 50 kHz. I changed the servo period, and the error disappeared.

“Probe tripped during non-probe move” is resolved by setting delays. In my case, using an electrical capacitor. Over 2 million activations.

This leads to the conclusion that it would be appropriate to implement a Probe delay parameter in the machine settings. “Feedback” delay. That is, when the probe triggers, the machine must immediately recognize this and begin braking, and then even execute the next command (typically, recording and rebound). And the specified parameter in seconds or milliseconds should not react to a change in the probe’s state.

@christer
github.com/LinuxCNC/linuxcnc/pull/3971
could you test this?

@AkkiSan
github.com/LinuxCNC/linuxcnc/pull/3971
could you test this?

@ fery15sty
github.com/LinuxCNC/linuxcnc/pull/3971
could you test this?