Good morning everyone. We're running some tests with Rodw on a Debian Trixie system, kernel 6.12.74-rt, and ethercat 1.6.9.
Just to be fair, we're using the same configuration on real machines, so motors connected to lead screws, running Debian 10, kernel 4.19.0-27-rt, ethercat 1.5.2, and linuxcnc 2.9.0-pre1. So, with Debian 10, the machines work without problems. When I first start up, the drives and all ethercat I/O are immediately visible, meaning, for example, the positions of the absolute encoders for the motors appear instantly upon startup.
With Debian Trixie, we're having two problems. A less serious one, that is, at startup, the motor encoders' values ​​appear late, the first drive starting to appear after about a second (x axis), after another second Y appears and after that Z appears. But the most serious problem is that if you run the machine, the axes shake, then they stop shaking, then the vibration comes back and everything gets worse if I move windows on the desktop. Rodw has already attached the latency test on the matter, but I repeat, the PC is always the same and all the i/o and xml files are the same. Now I tried to copy from Debian 10 the bin/lcec_conf and rtlib/lcec.so files into the respective directories of Debian Trixie, without result, same problem. We tried to copy the same files from a version with the Grandixxximo patch, same problem, I also tried to vary the lcec.0.pll-drift pin, with values ​​from 10 to 1000 without solving. Honestly, I don't I know what to do. I'm attaching the XML files I use on Debian 10 and Trixie.

Thanks.

Good point. I didn't consider helix angle. I tried with G76 P1.27 J0.4 R1.8 Q30 but the tip chipped out after a few passes. I then went down in J over a few attempts, with 0.2 resulting in a lot of passes, and the tip wearing out rather than chipping. I ended up with R2 and J0.3. I'd put in a fresh tip and rerun the code to clean up the thread, and use that same tip to rough out the next part.

They are crap Amazon inserts, so maybe  as carbide prices went up, they mixed some sawdust into the mixture

I was was unsure how much overhang to give those jaws. I really need to make up some new ones, as all the only I have are heavily used.
Yeah, I only cut in both directions, as it gave me the nice chamfer on the step.

 

Thanks for the vid Mark!

Couple of unsolicited thoughts...

• I wonder if part of your threading inserts were dying because they're designed for RH helix instead of LH? Probably not, but I have to wonder.
  • I also saw what looked like a million threading passes.  Perhaps your aren't taking a deep enough cut per pass and rubbing?
• Looks like your pneumatic chuck has adjustable serrated top jaws.  Instead of turning a new step diameter so far out that you run in to the holes, maybe move the top jaws out a couple of serrations?  My Rohm is similar and has a specification on how many serrations you can overhang before they get dodgy.
• Birds-nesting during facing... just cut from OD to ID instead of both directions. That inner step was so shallow you should be able to just plunge in Z- and cut to the ID.

Nice job on the tool changer!

Recuperei a minha dessa forma.
Com o cabo jtag.
Instalei um  .bit errada e a placa travou , depois o vendedor forneceu o .bit correto e usei o jtag para recuperar a placa.
Estou com 3 modelos de placas aqui, todas funcionam muito bem.

I changed the lines as follows

net program.is-idle whb.halui.program.is-idle
net program.is-paused whb.halui.program.is-paused

net program.is-idle not.0.in <= halui.program.is-idle
net program.is-paused halui.program.is-paused => time.0.pause

No errors at startup but is it right???
 

Thanks a lot for your help and advice guys. I got the turret.comp finished and working really nicely. (Attached)

Here is a video of it in action, doing it's first production run...



Cheers,
Mark

Thanks for ideas.

It gets worse and I've been pondering the next step.: "The machine is unusable; the axes shake and make a lot of noise. I tried rebooting and changing the refclock settings from -1 to values ​​of 1 or 1000, but to no avail. The PC has an Intel NIC, but, as I said, the hardware and software are identical to Debian 10. At this point, I don't know what to do. The problem is EtherCAT."
The customer would like to try Ethercat 1.52 from his Debian 10 days but I don't think it will run on later kernels 
The current Debian 10 Ethercat version on their repos is 1.62, Debian 12 and Debian 13 is 1.69 with no other earlier versions published. Latency is OK but not great for a 4 core machine
 

The only thing I can think of is to roll back to Debian 12. Any other ideas? 

 

rodw wrote:

Thought I'd ask here. User has upgraded from Debian 10 to latest Debian 13.3 and 2.10pre RIP config. Now Running grandixximos Ethercat driver but have not set syncToRefClock yet.

He reports:
With the same xml file, i/o and drive configuration, Debian 10 kernel 4.19 with ethercat 1.5.2 works fine, it has no latency at boot and hasn't given any problems. The current system has kernel 6.12 with ethercat 1.6.9 and has synchronization problems at boot, sometimes it doesn't see some drives on the bus, I'm forced to turn it off and on again. Would it be possible to use the current 6.12 kernel and linuxcnc 2.10, with ethercat 1.5.2?

I copied the lcec_conf and lcec.so files into the respective bin and rtailib folders from the Debian 10 version that I have and which works well on my machines, with linuxcnc 2.9.0 pre1 and etherrcat 1.5.2. At boot time, the drives are now seen within 1-2 seconds of booting and are always found on the bus.

This has 5 axis servos and a few Beckhoff modules attached to EK1100 

Next step is to add syncToRefClock

It seems odd to me that today's Ethercat hal driver is not performing but rolling back to an older version of it works. It seems to me his problem is the driver, not the version of Ethercat.

Any ideas or advice?

 

Ive experience of this non recognizing slaves on the bus during some experimenting at my debian 12 + 6.xx kernel ... but everything was solved by using non generic drivers and restarting ethercat service ifself... back that time I have benn using the 1.5.2 ethercat ... 

but it is sometimes odd till todays that with some hardware at bus ethercat is self-restarting and with some hardware is not ... and therefore bus has no slave active 

Ive not found solution at this till now...

It would be helpful to see the messages in syslog from when there was a problem.

from 5 April as an example. And cut to a reasonable length.

Hello PCW, I am having the same trouble.
Do you have or know where I can get a copy of 5i25_prob_rfx2.bit that includes a DPLL?
Thanks Robert?

Dear 

I think there are some opportunities in absolute encoders field with low information output as the one that I have.
 with only encoder counts in a multi-turn format s32 and encoder spins counter as well as multi-turn format s32.

I make it works but I need to spend some time testing it. but G33 and G76 are working with ethercat absolute encoder as spindle speed and position feedback , and some spontaneous axis following error to debug. ( jitter ? i do not know ).

Thank you.

Before this, I tried a component and attempted to read the current X & Y position and the prior x,y position. This allowed me to calculate the radius which I wanted but it never worked accurately. So I went to the state tags approach and Andy one of the devs convinced me to add the heading while I was at it.

This is something that is missing in Linuxcnc. This is actually quite complex. I had a go at it some years ago but my use case faded away.
The pull request still persists.  github.com/LinuxCNC/linuxcnc/pull/900
I got it working but it needed a bit of cleanup once the devs reviewed. It really needs to be completed.

This gets pretty deep into the Linuxcnc internals. The interpreter and motion are totally seperate entities in Linuxcnc. The interpreter tokenises the gcode so motion only sees the waypoints.

The interpreter knows or can calculate the centre of the G2/G3 arc and its radius. Motion does not. The change which enabled this was the release of state tags. State Tags passes the interpreter state to motion in real time. 
github.com/LinuxCNC/linuxcnc/blob/master...c/motion/state_tag.h
I extended the tags to include
    GM_FIELD_FLOAT_ARC_RADIUS,
    GM_FIELD_FLOAT_ARC_CENTER_X,
    GM_FIELD_FLOAT_ARC_CENTER_Y,
    GM_FIELD_FLOAT_STRAIGHT_HEADING,
The last field is the heading you need for your knife.
I published all of these state tags as interp.* pins including the heading so interp.heading is exactly what you need!

I was thinking recently now I am retired I should revisit this project. Maybe you can help and come along for the ride.
 

1.69 was released two weeks ago. Its what you get from their repos with a current version of Debian Trixie.
gitlab.com/groups/etherlab.org/-/packages

The code should be here.
gitlab.com/etherlab.org/ethercat/-/tree/1.5.2?ref_type=tags

From 2013. wow! that's old! From that, I would think it was built from source from Sourceforge. But well before my involvement.
Just checking Etherlab's gitlab releases, the first version on gitlab repo was 1.53 in 2024 so must be from Sourceforge

From what I can see, its not an Ethercat issue because the Debian 10 version of  linuxcnc-ethercat (with Ethercat 1,52) works with no problems  on Debian 13.3 with Ethercat 1.69.