Advanced Search

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?

Hello,

have found out the Problem - have flashed another bin gain - now 4 different Versions in the same project.

Have edit the above Post for others looking a way to bring this thing to work.

Hello
So bad I missed this topic, I was looking for this board for years !!

One question regarding the doc

Feedback 0 will typically be the encoder or resolver mounted on the motor, and feedback 1 can be used to connect either Hall sensors for initial commutation or (potentially) scales mounted directly to the axes. See the  Pinouts section of this document for pin assignments and typical wiring color codes.

  So we can connect linear scale ? but does it include a PID closed feedback?
I sent you a message on matrix to get the price of a board please.

Thank you for your awesome work 

Moin, also nach ewigen rumgesuche - habe ich jetzt nochmal NVEM erased und neu geflasht. Und zwar jetzt mit dieser bin:

Jetzt kann ich die Achsen verfahren ohne Probleme auch hochladen der configs führt zu keinem Problem.

Also scheint es irgendwo in dem NVEM Ordner zuviele Remora-NVEM.bin Firmwares zu geben die nicht funktionieren.

andrax wrote:

Do you have a sample program that uses the G43 call?

Not handy at the moment, but the issue persists across multiple programs.  First noticed on a fairly simple turning pgm with 3 tool changes, but the same thing happens when I just hand code or trim down a pgm for testing.

I can double-check for something abnormal later, but is there something I (or the post processor) could put in a program which would cause LCNC to ignore G43?  It's not like there's a GOTO statement skipping over the G43 words.