Advanced Search

It can be that linuxcnc-ethercat disturbs the process. It must be removed too.
I think this way is the best after all. The other way with changing a bit in the eeprom is even more complicated with ned tools.

I went through the disabling of EoE on a development system I have. Here is the list of commandsAt this point you should be able to start linuxcnc.
Check syslog for EoE appearances.
Take it step by step.
 

Thank you so much.
I tried multiple times, but I get the same result.

I installed ethercat-master using "linuxcnc-ethercat" package (that include some packages ) . and that may caused some issue for replacing ethercat master.

Do I need to install some packages separately, step by step ?
Unfortunatelly, I'm not familier to do this and I could not find proper procedures so far.

Do you know some web links or somethings to instruct this procedures to do this?

Indeed, it is the servoloop that isn't in sync with the dc clock.

github.com/linuxcnc-ethercat/linuxcnc-et...s.md#master-settings

If you have been using linuxcnc ethercat, you almost certainly have experienced jitter, the motor makes a weird noise, restarting lxcnc once or twice, and it works well, no amount of latency improvements ever fix this completly, just happens a bit less often.
Since I had sometime to kill this Christmas I put a lot of effort into pin pointing the cause of this issue, and fix it for good, I will share the code in the next few days, still doing some testing and refinements, but I wanted to share what I am at this time practically certain the cause was/is.
The issue is the servo thread syncs with the DC clock, but it is not in phase, each time linuxcnc starts the app-phase is randomly out of phase with the DC epoch time (Fixes value of "DC reference time" displayed by ethercat master), the fix was to remove app-phase from DC epoch, and drift the servo-thread to align with this time, that's all, this will make sure your packets are sent (with jitter) in phase with the DC epoch, and your sync0shift will actually allow for your jitter/latency.
I will do some more testing refine the code, and soon share the fix with the linuxcnc community,
Merry Christmas and Happy Holidays to all!

tommylight wrote:

use short cables

 
 

Just noticed this. It is the answer. I think.

Move VFD much closer to motor. Shorter cable from vfd to motor.
That by itself probably fix everything without doing anything else.

Also keep all DC wires far away from AC wires.

In terms of interference, the wires going from vfd to the motor are the baddest. The longer the badder. To a lesser degree all the AC wires are bad when so close to BOB and all. Contactors are also very bad the instant they open/close.

BOB too close to relay and power wires.

is a long machine and is installed in a reduced space, the original numeric control had that function in order controlling the motion all the time for operators safety

I can't wait to try that. I have tons of cheap inductive proximity sensors (well, more like a couple handfuls). Coil one motor power lead around it. Great idea. Cheap and simple. Thanks!

Yes, I updated the magic comments to include adding material thickness.

I don't see a picture of the actual breakout board, and related wiring. I might be able to pinpoint good locations to add ferrites. Even the parallel cable might benefit, you'd have to use a clip-on split ferrite, but those are more expensive and I have never tried that type. Best put them on the VFD wires first. A customer watched me do that to his project and it made such a difference he asked me if it is black magic.

All of the above (except I don't bother with an earth ground rod on mills. Plasma maybe, if its a big one). I have covered unshielded wire by wrapping in aluminum foil then cover with tape. Make sure shields are grounded at the computer end but NOT at the far end. If aluminum foil has splices, confirm it connects very good and overlaps some.

Grounding a shield at both ends can act the same as no shield. Don't ground the motor end. Spiral steel or aluminum foil is not as good as copper braid but should help.

Add ferrite beads, the more the merrier. That alone has completely mitigated some of my most annoying interference problems. I keep a bunch on hand, and just experiment by adding a couple here and there till it is fixed.

Start by putting some on each wire that's connected to the vfd, closer to the vfd is better. They absorb some of the interference the wires radiate. Next, I'd add smaller ferrites to the limit switch wires, closer to the electronics is better.

Some vfd suppliers recommend using one big ferrite and turning the three power wires around it 3x, one ferrite for the power in side, and one for the power out side.

Ferrites come in an enormous variety of shapes, sizes, and colors. I don't know how much it matters what kind of ferrite you should use. I've read there's a significant difference in different grades of ferrite. I never bothered to figure out which are better. I had a cheap USB charger transformer quit working, so I thought I'd cut the ferrite (molded in plastic) from its cord before I discard the charger. I cut it open, it was all plastic, no ferrite inside. That was a very fake ferrite.

OK since this has gotten some interest, there are two methods of using hard stops for homing without messing with the drives at all, for DC brushed motors:
1. using hal sensors wired to inputs (be it Mesa or Pico or parallel), more windings around the sensor = more sensitive
2. using REED switches wired to inputs ...., again more windings = more sensitive
-
There are two types of hal sensors, those with variable output and the on/off type, latter is easier to use for this use case.
Sensors should be wound with only one motor wire, not both.

NWE wrote:

May I ask, what use case requires adjustable home_search_vel?

+1

May I ask, what use case requires adjustable home_search_vel? Sorry for my ignorance.