Advanced Search

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?

Drives usually have only optocouplers on the inputs, so chances are low for it to short, higher chances of loosing sensitivity (light output as inside the is an LED and a photodiode).
Much higher chances of interference from the spindle and/or VFD that caused a spike, might even be moisture messing things up.

I'm afraid i've got about the same questions as spumco and then some. I got the cables with the batteries installed today and followed your process, changed the config on each of the drives via the physical buttons and updated the relevant parts of the ini. I hadn't set up homing in any particular way before so i didn't have any of the stuff you commented in the hal file, though i was able to trigger homing and they would reference correctly against the inductive sensors even without any special config in the hal.
It'd seem like when i start linuxCNC the axis start on random positions. I get out of range errors if i try to home as is, and if i jog them into range and home after, i usually get amplifier faults. Am i misunderstanding what you mean by reference run? is there somewhere else in the drive's software where the homing needs to be triggered?

Besides that, my kinematics are the same as yours, with dual Y drives, and i'm wondering how gantry squaring works in this mode.

Edit: Ok, i think i sort of understand now, the config you have commented afterwards, you do need for the initial setup. However, where is request-cia-homing and start-cia-homing coming from? github.com/rodw-au/cia402_homecomp uses different names, not sure if what you're using is equivalent. I'm trying to get the initial config to get the homing done before turning off all the config now.