Advanced Search

So I am not really qualified here but I've had some ideas which I explored.The Core Issues

• Version 1.5.2 vs. Modern Branches: The reason version 1.5.2 felt "smoother" is because it often operated in Free Run mode. It wasn't strictly enforcing nanosecond-precise timing, so it never performed the violent corrections ("snaps") seen in newer, more precise versions.
  • The "Startup Snap": Grandixximo’s branch is designed to solve Phase Drift (especially common at a 1ms servo thread). To get the PC and the network in phase, the driver forces a massive time jump (the 1.6s jump Hakan lists) at startup.
    • Cheap Hardware Sensitivity: Modern, lower-cost EtherCAT servos have lower-quality internal clocks and smaller "sync windows." Unlike premium hardware, they cannot "soak up" timing errors and will grind or stutter the moment the Master clock shifts
      
      Deployment Fixes
      1. Slave 0 Hierarchy: The first DC-capable device in the chain is the Reference Clock. For industrial stability, this should always be a high-quality device (like a Beckhoff EK1100) rather than a budget drive.
         • The "Machine On" Interlock: You should never enable the machine (allow physical motion) until the system is "in range." The drives should be kept in a disabled state while the driver performs its initial 1.6s "snap" Hakan shows

The "Safe Window" Logic: Implement a HAL interlock that monitors the

pll_err pin.

Hold the enable signals low until the error is stable (maybe for a few seconds) Yes, some AI input here but this is a summary of a detailed conversation I had with my well trained assistant 

I think its very weird now ... I remeber that times when everybody here are running deb10 with 4.19 kernels and 1.5.2 master version... there was no timing problem at all either at startup of lcnc... I single grinding from the Kollmorgen S300 drivers at 1ms single time but I solved it by installing native driver and editing the assignActivate of DC from 0x0300 to 0x730 and every grinding sound was gone ... that drivers are pretty sensitive DC stuff really same to AX5000 from beckhoff(I do not know if I go right that time ... ) I am running well tunned i5 with around 2us latency beckhoff IPC but startup delay are present nowdays... sometime even AX5000 drivers are not became OP because of this synchronization issue I think ... somewhere there is the original thread of lcec from sascha and there is really really really recommended to start the physical ebus with the DC capable device, best practise is one of the axis  I can not see under the hood of lcec because its not my cup of tea but, it should be real breakthrough it this tailchasing will be done

Läuft den der Code ohne T... M6 bzw. Fräserdurchmesser 0?
 

Hello,

I'm planning to build a 5-axis machine. For the rotary axis, I intend to use a harmonic drive servo, driven by a Yukon Drive 1021 AFO.

LinuxCNC seems like a good choice for this project, but I'm wondering if it's possible to control the Yukon Drive using a Mesa card with +- 10 V analog output (I was considering a 7i92+7i77 setup).

Has anyone done something similar, or can confirm if this setup will work? Are there any issues I should be aware of?

I look forward to your replies.

So I am not really qualified here but I've had some ideas which I explored.The Core Issues

• Version 1.5.2 vs. Modern Branches: The reason version 1.5.2 felt "smoother" is because it often operated in Free Run mode. It wasn't strictly enforcing nanosecond-precise timing, so it never performed the violent corrections ("snaps") seen in newer, more precise versions.
• The "Startup Snap": Grandixximo’s branch is designed to solve Phase Drift (especially common at a 1ms servo thread). To get the PC and the network in phase, the driver forces a massive time jump (the 1.6s jump Hakan lists) at startup.
• Cheap Hardware Sensitivity: Modern, lower-cost EtherCAT servos have lower-quality internal clocks and smaller "sync windows." Unlike premium hardware, they cannot "soak up" timing errors and will grind or stutter the moment the Master clock shifts
  
  Deployment Fixes

1. Slave 0 Hierarchy: The first DC-capable device in the chain is the Reference Clock. For industrial stability, this should always be a high-quality device (like a Beckhoff EK1100) rather than a budget drive.
2. The "Machine On" Interlock: You should never enable the machine (allow physical motion) until the system is "in range." The drives should be kept in a disabled state while the driver performs its initial 1.6s "snap" Hakan shows
3. The "Safe Window" Logic: Implement a HAL interlock that monitors the

   pll_err

   pin. Hold the enable signals low until the error is stable (maybe for a few seconds)

Yes, some AI input here but this is a summary of a detailed conversation I had with my well trained assistant

Danke für die Mühe ! Aber das Problem taucht auch auf,wenn ich einen G-Code lade,der gestern noch Funktioniert hat,aber heute nicht mehr. Gestern habe ich einen Relativ Simplen G Code gestartet mit einer Kontur und 3 Bohrungen. Ein Teil ging Problemlos zu Fräsen,beim 2. Teil nach dem neuen Antasten auf Y fingen die Probleme an. Am Dispay sieht es so aus,als ob der Bohrer genau an der richtigen Position eintaucht,die Maschine fährt aber an die ursprüngliche Position ... Alle Nullpunkte stimmen aber ! Oft hilft dann Herunterfahren,neu Starten,Referenzfahrt und von Vorne beginnen. Aber diesmal kam wieder die Fehlermeldung mit den Kreisbogen.. Seit 4 Jahren benutze ich Fusion 360 (Leider) und Linuxcnc. Linuxcnc habe ich noch die Version von 2021 unverändert am Steuerrechner Installiert,ohne Update ect. Lief bis vor 1 Jahr eigentlich ohne Probleme. Leider bin ich was G-Code und Linux angeht nicht gerade ein Experte. Für mich ist die Fräse eigentlich nur Mittel zum Zweck und sollte mich daher nicht Zeit zur Fehlersuche Kosten. Komme ohnehin viel zu wenig zum Arbeiten damit.

I want to trigger an error if the difference between the actual servo position and the commanded position exceeds a certain threshold (e.g., 5mm) due to external forces. However, unless I set the in the .ini file JOINT section to something very large (like 50 or 500), a 'Following Error' occurs immediately.

= INI FILE =[JOINT_0]
MIN_FERROR = 500
FERROR = 50

I want to set these values to be able to check following error within 5mm (5.0mm)
 I have already tuned the SERVO gains appropriately and confirmed that the actual physical deviation is nowhere near 50mm. The servo's electronic gear is configured so that 1 unit equals 1/1000mm, and I am converting the values to integers before writing them to EtherCAT.

= HAL FILE =
setp cia402.0.pos-scale 1000
 I know threre are 1ms time difference in EtherCAT and latency for servo position, but I think these settings are not proper.

Which part of LCNC settings should I check or modify to resolve this problem?

 

I'm using Sigma-X with EtherCAT.
I could rebuild IgH Master, thanks to Hakan.
Yaskawa Sigma-X is very strict for communication timing, etc.

Good morning everyone. This is very likely the problem. I've noticed that sometimes the problem occurs on the first reboot. I start LinuxCNC, with automatic startup at system startup. If I restart LinuxCNC with the system running, the problem goes away, but sometimes it doesn't. Tomorrow I'll try to test Grandixximo's latest fix. If it doesn't work, I'll reverse the bus sequence, install the SLA and I/O last, make sure the drives are the first node, and modify HAL.

I seems the initial delay is caused by lcec setting a bad initial reference time to the slaves.
Here is a listing of the first five lines, from lcec.write-all.
Data is cycle number, pll-err, reference clock time, application timelcec reads reference time of 3.53 second, and then sets it to 2.80 seconds. (lower 32 bits).
Now, speculating a bit, the clock is not changed right away, instead the clock is slowly changed
and the slave maintains a system time offset register 0x92c. It can then report and accurate
time by using the clock, that is off until in sync, and add the system time offset.
Must say it is speculation this though.

Anyway, the initial time setting in rt_app_main, or possibly the first few rounds in lcec_write should be looked at.
 

Hi,
was sind dort für Spindeln eingebaut Trapezgewinde oder Kugelgewindespindeln?
Wenn Trapezgewinde, dann würde ich Versuchen diese gegen Kugelgewindespindeln zu ersetzen.
Servos:
Da du scheinbar auf Ethercat gehen willst, würde ich hier zu Stepperonline raten.
Die gibt es günstig bei Amazon und sind hier im Forum gut getestet.
Die Glasmaßstäbe kannst du eigentlich ausbauen und gut aufräumen. Die Encoder der Servos sind bei weiten präziser.

Hi,

I've written a guide on this.
forum.linuxcnc.org/ethercat/58467-settin...attery-encoder-cable

all done, thanks

MaHa wrote:

While reaching the limit before generating gcode, just had a look at the operation options. Missing essential selection for ucs, and in general a preamble to be set. It seems corner radius is missing for pocket and contour, to have smooth direction change, and desired cornerradius. Stepover as percentage of the cutter diameter is more preferable than fixed value. The contour operations have no rough dimension input? Zig zag facing, is it using stepover? And the drilling operations, eg grid drill have no selection for cycle, retract, clear z (G98)
As i was not able to test for free, this is just from looking at the interface.
 

all done, thanks

Hi,

Thank you for testing! Found another Python 3 compatibility bug.
The function that modifies the ini file was still using old Python 2
API (io.BytesIO with str argument).

This will be fixed in the next release (2.0b-2) which I will push
to GitHub shortly.

By the way, there's a separate issue — your config folder has a
space in the name ("MILLING MACHINE"). LinuxCNC works with it, but
it can cause problems with some tools. Consider renaming to
"MILLING_MACHINE" for safety.

github.com/cnc-proton/nativecam-py3-gtk3/releases

Best,
Axemas

The main errors:
K0.75 is radius mode while in diameter mode.
I1 is radius mode (X34-X32) while in diameter mode
G96 D2500 ? 2500 m/min surface speed? Cutting steel with carbide  is typically only 1/10 that or less.
Maybe consider G97 S500 just to remove a variable while you are getting used it it?

Assuming a thread major diameter (stock OD) of 32, with you drive line at  X34, I-2. In practice, the major diameter is probably more like P/8 smaller. Somewhere around 31.8mm. Andy has programmed all that into his lathe macros, so you just give it major diameter (32mm) and it takes a first turning path at P/8 smaller before starting threading.
Since this is G7 diameter mode, the final depth K is also in diameter, so that will be 32-30.5 K1.5. Actually it is more likely to be about 30.38, so you will tweak this number to get your thread to fit, if you don't have perfect full profile inserts. Dont be surprised that you need around K1.62 to get the nut to fit.
J0.3 is reasonable. You will need lots of passes. See if you can get the insert to survive at J0.5
The R 1.6 means your cut will get heavier at each pass. I tend to set that at R2 for constant area, of course leading o increased number of passes.
The rest looks good.

G7 G18 G21 G90 G94
G0 X34 Z10
G97 S500 M3 M8
G76 Z-15 P1.5 I-2 K1.5 J0.5 Q29 H2 E0.75 L2