Advanced Search

You might also want to mention what tools/holders, speeds, and feeds you're using, as well as how far off the dimensions are.

That said, my first reaction to the above is deflection- the gouge looks like where the tool ended the cut, possibly dwelled there a bit before/during retract, giving it more time to cut. If it is deflection, there's a good chance you'll feel ridges if you run a fingernail along the floor of the machined surface perpendicular to the direction of cut.

Adding a finishing cut might be all you need- I generally leave 0.1~0.2mm of stock during roughing operations for the finishing cut(s).

Generally increasing rigidity should help as well (shorter tools/toolholders/stickout, bigger tools, better worktholding, working closer to the table), but I've always thought the columns on benchtop mills look too small, so you may be limited in options if that's the root cause. The good news is that so long as it cuts OK, taking a light finish cut should still get you on dimension.

@RodW,
Is the "user exchange" section just for that kind of stuff?
You could have mentioned here you have a paid solution and posted a link to "user exchange" section, as i do not think that is just for parts nor am i aware it excludes services, but i am not sure.
@Others,
Would that be OK?

Hi,

I just updated LinuxCNC via the package manager.
When I set `syncToRefClock=“true”`, I still get the error `lcec_conf: ERROR: Invalid master attribute syncToRefClock`.
I've now downloaded the EtherCAT master from GitHub.
When I run `make`, I get the following errors:

[/code]


Edit:
I've used Git now.
git clone github.com/sittner/linuxcnc-ethercat.git
There were no errors this time,
but the syncToRefClock=“true” still doesn't work.

 

@rodw
Not sure what to think of this. I don't have a problem with you providing paid support for linuxcnc but please do not (ab)use your posts on this forum for blatant advertisement.
Thank you.

Taichi wrote:

 Does it mean that in the firmware the encoder index is untied from the counter?
I will try to implement this using the GPT chat

A quick note to make it easier to find:
Instead of
“hm2_board.0.encoder.1.index-enable”
Use
“hm2_board.0.stepgen.1.index-enable”

I'm not good at coding either, I'm having the code checked by YangYang aka Mika in the forum, he is the master coder lol.

I did quick commit to fix the bug, seems legitimate, it was also present in original master. Thank you for reporting, hope the grinding noise goes away. Thank you for testing the code, would appreciate if you could leave a comment if my branch worked out without grinding noise for you. Thanks.

Thanks Luca for all your work around this. I am experiencing grinding noise myself. Very random and I really only noticed it because I have my EtherCat system on a bench for testing, so no machine noise. 

Until now I was running the latest 1.40.0 release from Scott (9/2024) and wanted to try your code to see if that fixes the issue for me. 

While testing your current linuxcnc-ethercat code I encountered a reproducible SIGSEGV in lcec_parse_config().

Minimal configuration:
<masters>
  <master idx="0" appTimePeriod="1000000">
  </master>
</masters>

The crash happens during:
for (slave = master->first_slave; slave != NULL; slave = slave->next)
Even though no slave is defined in the XML.
Looking at lcec_main.c, both master and slave structures are allocated via:

master = LCEC_ALLOCATE(lcec_master_t);
slave  = LCEC_ALLOCATE(lcec_slave_t);

but are not explicitly zero-initialized.

If master->first_slave contains a non-NULL value, the code enters the loop and
dereferences an invalid pointer.

Adding explicit initialization fixes the issue:

master = LCEC_ALLOCATE(lcec_master_t);
memset(master, 0, sizeof(*master));

slave = LCEC_ALLOCATE(lcec_slave_t);
memset(slave, 0, sizeof(*slave));

After applying this change the driver starts correctly.

The issue may have existed previously but remained hidden depending on memory layout or allocator behavior.

I thought I share if anybody else has the exact same issue. 

BTW, I am not that good in coding and had a bit of help from my "buddy". 

Why are you advertising paid information in a free forum?

Hallo Leute,
ich wollte am Wochenende mal meinen Rechner der Maschine updaten.
alter Stand war Debian 11 denke ich mit LinuxCNC 2.9.0 pre0 Ethercat.
Ich habe nun Debian 12 installiert inkl. Ethercat Master, linuxcnc-ethercat von Herrn Ittner.

Leider habe ich ein Problem mit meiner EL6751 Klemme, die will nicht in OP Modus. 
Starte ich das alte System läuft alles wie gewohnt.

Bei mir ist auf der EL6751 alles gespeichert was die Servotreiber benötigen. SDO habe ich deshalb nicht.
Anbei mal meine xml und ein paar Analyseversuche:
die Klemme habe ich auch mal unter Linux ausgelesen. (XML im Anhang)
steffen@mikron:~$ ethercat slave -p 7 -v
=== Master 0, Slave 7 ===
Device: Main
State: PREOP
Flag: E
Identity:
  Vendor Id:       0x00000002
  Product code:    0x1a5f3052
  Revision number: 0x00110000
  Serial number:   0x00000000
DL information:
  FMMU bit operation: no
  Distributed clocks: yes, 64 bit
  DC system time transmission delay: 1019 ns
Port  Type  Link  Loop    Signal  NextSlave  RxTime [ns]  Diff [ns]   NextDc [ns]
   0  EBUS  up    open    yes             6    729502240           0         155
   1  EBUS  down  closed  no              -            -           -           -
   2  N/A   down  closed  no              -            -           -           -
   3  N/A   down  closed  no              -            -           -           -
Mailboxes:
  Bootstrap RX: 0x1000/532, TX: 0x1800/532
  Standard  RX: 0x1800/558, TX: 0x1a2e/558
  Supported protocols: AoE, CoE, FoE
General:
  Group: Communication
  Image name: 
  Order number: EL6751
  Device name: EL6751 CANopen Master
  CoE details:
    Enable SDO: yes
    Enable SDO Info: yes
    Enable PDO Assign: no
    Enable PDO Configuration: no
    Enable Upload at startup: no
    Enable SDO complete access: yes
  Flags:
    Enable SafeOp: no
    Enable notLRW: no
  Current consumption: 300 mA
steffen@mikron:~$ ethercat slave
 0  0:0   OP     +  EK1100 EtherCAT-Koppler (2A E-Bus)
 1  0:1   OP     +  EL2008 8K. Dig. Ausgang 24V, 0.5A
 2  0:2   OP     +  EL2008 8K. Dig. Ausgang 24V, 0.5A
 3  0:3   OP     +  EL1008 8K. Dig. Eingang 24V, 3ms
 4  0:4   OP     +  EL1008 8K. Dig. Eingang 24V, 3ms
 5  0:5   OP     +  EL1008 8K. Dig. Eingang 24V, 3ms
 6  0:6   OP     +  EL2622 2K. Relais Ausgang, Schlie�er (230V AC / 30V DC)
 7  0:7   PREOP  E  EL6751 CANopen Master
 8  0:8   OP     +  EK1100 EtherCAT-Koppler (2A E-Bus)
 9  0:9   OP     +  EL2008 8K. Dig. Ausgang 24V, 0.5A
10  0:10  OP     +  EL2008 8K. Dig. Ausgang 24V, 0.5A
11  0:11  OP     +  EL1008 8K. Dig. Eingang 24V, 3ms
12  0:12  OP     +  EL1008 8K. Dig. Eingang 24V, 3ms
13  0:13  OP     +  EL5151 1K. Inc. Encoder
14  0:14  OP     +  EP2318-0001 4 K. Dig. Ein, 10�s, 4 K. Dig. Aus 24V, 0,5A, M8

 

Yes, drift is a testing value, you need set pll-step to 0 and then set drift, and you can go into the grinding window, it's just for testing, and finding where the grinding window is. You don't need to use, system should be working now, no more grinding.

@grandixximo Good news. The patch you did worked. DC-phased is now active and I can see changing values for drift, err, final, out and reset-count. Nothing on the drift and jitter signals though, not sure if that is how it should be. 

Also, regarding the pll-step value with the older version of the patch, it was at 1000. 

I never discussed with Rob, maybe on next meeting 

I know what you are saying.

What have the tormach guys said about it? The 1500mx doesn't seem to have any issues. is there something to take from their new source code?

Ventoy really shines on PCs
I use it like this, and I still have room for other distros when I need them, but it is mainly my Swiss Army knife USB for tools.

/ISO/Rescue/SystemRescue.iso
/ISO/Rescue/Clonezilla.iso
/ISO/Rescue/GParted.iso
/ISO/Rescue/Rescuezilla.iso
/ISO/Boot/SuperGrub2Disk.iso
/ISO/Windows/Win11.iso
/ISO/Linux/Ubuntu-Live.iso
/ISO/Hardware/Memtest86+.iso

It's based on the execution time between two processes which is not guaranteed to align well in all systems, it may be ok on some hardware, very little difference, and completely random on others.