Advanced Search

Thank you so much for your support. You mentioned updating that on the main branch; I imagine you mean linuxcnc. How can I access those changes?
And if you could help me so I could make some modifications myself, I would appreciate it.

Surmetall wrote:

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.

Yes, I wondered about that. It would be able to be used by someone like grandixximo who is a member of the ETG (Ethercat Technology Group) but not OK for linuxcnc to put on its web site so I think it could be shared here for those users who have the membership

Hi endian,

I spent quite a few hours on this again today and tried to narrow it down properly instead of guessing.
On the full 13-slave bus, all other slaves go OP but the AX5125 at slave 7 still drops to PREOP + ERROR. The relevant lines are

:ethercat slaves:
7 0:7 PREOP E AX5125-0000-0216 EtherCAT Drive (SoE, 1 Ch.)

dmesg:
EtherCAT WARNING 0-7: Slave does not support changing the PDO mapping!
Currently mapped PDO entries: 0x0086:00/16 0x002F:00/32. Entries to map: 0x0086:01/16 0x002F:01/32 0x0024:01/32 0x0050:01/16 0x81E4:01/32 0x81E5:01/32

EtherCAT WARNING 0-7: Slave does not support changing the PDO mapping!
Currently mapped PDO entries: 0x0087:00/16 0x0033:00/32 0x00BD:00/32. Entries to map: 0x0087:01/16 0x0033:01/32 0x00BD:01/32 0x0054:01/16 0x0028:01/32 0x81CC:01/16 0x81CD:01/16
EtherCAT ERROR 0-7: Failed to set SAFEOP state, slave refused state change (PREOP + ERROR).
EtherCAT ERROR 0-7: AL status message 0x0045: "MBX_SOE".

I also made an AX-only test again. Earlier the AX could reach OP by itself, but I still could not get the motor to actually rotate from LinuxCNC. I tried both a direct velocity-command approach and then a stepgen/position-command approach. The command chain seems to work up to the AX command pin, but the motor still does not move.

From the AX-only spin test:
halcmd getp lcec.0.Antrieb-1-AX5-0.slave-oper
FALSE
halcmd getp lcec.0.Antrieb-1-AX5-0.slave-state-op
FALSE
halcmd getp lcec.0.Antrieb-1-AX5-0.Drive-status-wo-6
40960
halcmd getp spindle.0.speed-cmd-rps
8.333333
halcmd getp stepgen.0.velocity-cmd
8.333333
halcmd getp stepgen.0.position-fb
157.122
halcmd getp sercos.0.pos-cmd
157.1553
halcmd getp lcec.0.Antrieb-1-AX5-0.Position-comman-1
164824253

ethercat slaves:
0 0:0 SAFEOP E AX5125-0000-0216 EtherCAT Drive (SoE, 1 Ch.)
dmesg:
EtherCAT ERROR 0-0: Failed to set OP state, slave refused state change (SAFEOP + ERROR).
EtherCAT ERROR 0-0: AL status message 0x001A: "Synchronization error".

I also tested removing IDNs 32972, 32969, 32971 and 32970 once from initCmds, but that changed nothing, so I restored the original file again.
So at this point I have two clear observations:
on the full bus the AX still fails with MBX_SOE,
and on the AX-only LinuxCNC spindle test I can generate command values but still cannot get the drive to rotate.

What would you check next? I am little bit out of ideas. Thanks for your time! 

greetings 

Tom

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

Google translation:
"Hello, I have a LinuxCNC 2.9.8 Mesa7i92 board with SSK-MB2. It's a three-axis milling machine with X, Y, and Z axes. NGC programs work fine. I started the WHBO4B-4 with a cable and it doesn't quite work correctly. When I turn the wheel, the axis continues to move when I stop.
Please tell me what I have configured incorrectly."

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.