The manual for your drive (pages 27–28) shows that Digital Output 5 (pins 19–20) and Digital Output 6 (pins 21–22) are digital output pairs rated to switch loads up to 200 mA. Output 6 can be used to send a stop signal to your system, indicating that the drive has entered stop mode.If your goal is to feed an external E‑stop signal into the drive, you must wire that signal to  digital input IN1 (Servo Enable) as shown in the wiring diagram on page 26.The reference to “differential input” in the documentation is simply a translation error and can be disregarded.

MB: P5g41t-m lx
CPU: Intel Core2Duo E7600
Memory: 4GB Ram.

Thanks Rod!

I have done all that already except using dkms driver. It is an Intel NIC (e1000e) not realtek... Now time will show if it is fixed

With Z0 and Y0 both sitting on the center of rotation in CAM, the G52 Y correction only compensates for the actual clamping offset of the stock, and the orbit problem doesn't arise. The part isn't referencing a point on the stock that moves with it — it's referencing the fixed axis center.

I still fail to understand the point of probing and using an offset.  What exactly are you offsetting?

• If the actual CoR position is not known and you probe the part - you don't know how far to offset.
• If the actual CoR position is known and you probe the part, you know how much to offset, but
  • the CAM doesn't know how far you've offset, so features will be machined in relation to the CoR, but not to the stock position
  • In the case of a profile-type toolpath - depending on how far offset the stock is from actual CoR - you will need extra material on one side and risk taking an extra-heavy cut on the other

If you position the part mostly in-line with the actual CoR and program a bit of extra stock in CAM, you will never need to probe and you will never plow in to unexpected material.

Yeah, I didn't think there would be any magic, but I figured I'd ask. My files come from various sources so "do it in post" is not reliable enough unless EVERY post does a G0XY before any GZ.

Oh, right,
I use the CIA402 and CIA402_homecomp by Colin Bardini. It works very well on XYZ machines.
However, there are generally issues with XYYZ machines.
It can happen that during homing, only one gantry axis moves. The other one stays still or starts moving late. It’s a known issue. 
@Marcos DC has taken on the problem. The current status of the work is unknown.
forum.linuxcnc.org/ethercat/58592-cia402...ation-easier-debuggi
There may also be issues with jitter.
Read more here:
forum.linuxcnc.org/ethercat/58103-ethercat-random-jitter-fix
@rodw has already incorporated all of this into his repositories and created installation instructions. I can’t find the link right now.

regards

andrax

Thanks so much for the detailed response and the PathPilot macro — really appreciated!

You're absolutely right that blindly setting G52 Y without accounting for Z would cause the orbit problem you described. That's an important warning and worth highlighting.

The key assumption I should have stated more clearly upfront: the CAM origin must be placed on the rotary axis itself — not on the stock surface. With Z0 and Y0 both sitting on the center of rotation in CAM, the G52 Y correction only compensates for the actual clamping offset of the stock, and the orbit problem doesn't arise. The part isn't referencing a point on the stock that moves with it — it's referencing the fixed axis center.

With that setup in place, I think TCP isn't needed either — Fusion pre-computes all positions for a table-type A-axis, so the controller just executes straight X/Y/Z/A moves.

Thanks again for pushing back on this — it forced a much clearer explanation of the preconditions.

Have you had any further development in your motion control plan.

Yes, I get that, but it seems you're using a different version of CIA402_home_comp than the one i posted there. Which one is it? I have everything working in the ethercat setup but the homing was the regular one.

I suspect its a hardware fault. Its a long time since I've used 2.9 on a live machine but it never happened to me.
Can you swap out the keyboard for another one? Some compressed air to blow out the keys perhaps?

Hold on—you need to make a distinction.
There are two fundamental homing methods:
1. LinuxCNC Homing
2. CiA-402 Homing using the CIA402_home_comp.
Your machine should first be running entirely under EtherCAT. The internal servo homing using CIA402_home_comp.comp should function without any issues.
Only then can you proceed to implement the topic discussed here.

I think the N100's will be OK but never tried them
If you want cheap, look for a surplus DELL or HP corporate desktop with an i5, 8 gb RAM, Intel NIC
I nearly bought a DELL the other day for AUD $80 (< USD $60)
I'd also look for 1080p video. I have had one here for ages and found out today it had a Displayport monitor output and I had even bought a VGA to HDMI adapter to use it! (that went in the bin)

What are PC specs. cpu, number of cores,  RAM. 

There is no magic as far as I know....
Is this not something you can deal with in the post-processor?
Like Ssetting a global before the M6, e.g. #<_restore_xy> = 0, and have your M6 read that flag to decide whether to restore?

Linuxcnc architecture will fight you hard on this, no real way to know the future move type after an M6, preview does it, but is fragile, it would be a waste of time implementing something like that IMO

2009.
I managed to boot - the issue was "Legacy USB Support" option in BIOS - it was turned off.

With this option turned on - USB storage is emulated as Hard Disk Drive - and I was able to boot.

But now I'm testing jitter - and it's waaay to high.
With LinuxCNC 2.7 - max jitter was 25k.
With LinuxCNC 2.9 - max jitter is 3 million.

I installed RTAI kernel - but it cannot boot at all (it says give up on waiting root device). PREEMPT-RT works fine.

Any ideas?