Advanced Search

For somebody trying hard to follow along from the sidelines, can you guys outline the objective for rolling back to 1.52 here?
Has anybody looked at the Igh Ethercat master 1.6 or even 1.7 which was released on gitlab 3 weeks ago (but not in their repositories) to see if it has these delays outside of linuxcnc.

It seems to me it would be unlikely that iGh master 1.6 or 1.7 are problematic as people would be complaining at iGh so to me,  the effort should be in understanding what has changed that linuxcnc-ethercat is not liking. Rolling back to a very old version does not seem a progressive step following the synchronisation enhancement.

Looks pretty good. I'll have to check it so I don't miss anything.
Sorry, I've had to focus on other projects these last few days which I have almost completed, then record an overdue video for my Youtube channel, then I will get back to this.

papagno-source wrote:

I have installed linuxcnc-ethercat...0.9.5-retro1.5.2-rc1, without error, but if coomand ethercat version have reult 1.6.9
But I think, this is not the Igh part, but the lcec driver, right?
I have a version running in place in another directory, do I need to copy or link something to test?
On Debian 10 , in direcory bin the linuxcnc , i have only lcec_conf and not have lcec_coffingen
 

gitlab.com/grandixximo/ethercat/-/jobs/1...ad?file_type=archive
This is the igh ethercat, you need to uninstall your current ethercat master to get this to work, also ethercat-dkms and libethercat.
You might have to run or restart the ethercat service after installing the deb packages in the artifact.zip
 
for the linuxcnc-ehercat remove your current version
and install this
github.com/grandixximo/linuxcnc-ethercat...0.9.5-retro1.5.2-rc1
this is the lcec part, and it has both lcec_conf and lcec_coffingen
I cannot fathom why you would have one and not the other if you installed my packages.

I saw you tried to come to the discord, but you did not give a thumbs up to the rules message, so you were not allowed in.

I'm on +08:00 time. not in Italy. So mind the time difference. I'll only probably be available in the morning Italy time.

papagno-source wrote:

Syste is debian 10 buster x86_64
Kernel: 4.19.0-27-rt-amd64 #1 SMP PREEEMPT RT Debian 4.19.316-1 (2024-06-25) x86_64 GNU/Linux
Ethercat : IgH ETHERCAT master 1.5.2 unknow
Etherlabmaster-1.5.2+20190904hg33b922p8ea394
LINUXCNC 2.9.0-pre0


When axis opens the gui, the axis dimensions are already present. From tests done, when I had the same problem with debian 12, as soon as it reads the loadrt lcec command, the dimensions appear on the pins in hal, relating to the individual axes.

 
linuxcnc-ethercat version? 

i hope to help with this analysis , it is made by AI, and this try to understand ,    

If they're upstream of the VFD they're called 'line reactors' and smooth out incoming power ripples.

If they're downstream they're called 'load reactors' and smooth out the power to the motor.  Reduces heating in the motor, especially useful for older motors which aren't rated for VFD use and which are going to be run at speeds lower than nameplate rating.

Grease - you can flush out all the greased components with kerosene, then blow out excess with air, then regrease with whatever flavor you want.  Disconnect each grease circuit and flush each component separately - this will help identify any clogged or broken lines.  When you've cleared all the individual circuits out, flush any manifolds and header lines.

Could be from a number of sources.  Suggest disconnecting the ballscrew nut (or nut mount) from the X-carriage.  This will allow you to move the carriage by hand, as well as rotate the ballscrew in it's bearings, and also the nut on the ballscrew.  Should help you identify the source of crunchiness.

Which bearings?  Your machine has quite a few.  Some are cheap, some are not.  Your wallet will determine what you can replace... but if the bearing is easily replaceable and remotely suspect, I'd replace it.  You can usually find NOS name-brand bearings on ebay for decent prices.

andypugh wrote:

Spindles are typically controlled through the NML interface by the GUIs, so if the GUI doesn't support multiple spindles you might have to use MDI to turn on and off the auxilliary spindles.

THat said, flexgui is mane to be flexible, so maybe there is suopport?
I haven't used it yet.
 

Thanks Andy.  I'm trying it out for the first time now.

All machine functions are already handled with hardware controls; I just want displays for all three spindles.  The only on-screen control which could cause machine movement of any type will be an MDI 'run' button.

I'm guessing FlexGUI is new enough that @JT hasn't had anyone bugging him about outlier configurations much.

See if you can add isolcpus=3 to your kernel boot file. I have done it on a pi but can't remember how
It should improve latency.

I hit buy on the servos this morning! My order was at the weight limit so i couldn't even add couplings to it and i'll have to place another for the extras, but i can use the us store for that and reship as well. Regarding the cables, of which i need at least 2 longer ones than they come with the motors, i'm guessing i can't chain them and i just have to replace with the longer version, right? Also, is the one for the servo with the break completely different?

Der VFD scheint in P02.10 nur eine feste Frequenz zu unterstuertzen. Damit koenne man wohl pruefen ob er z.B. eine Mindestdrehzahl hat. Z.B. 100Hz oder 6000UpM. Aber er kann wohl nicht vergleichen, ob die Vorgabe durch Spannung erreicht ist und dann erst schalten.

Wenn du ganz viel Langeweile hast, kannst du dir auch die ModBus Implementierung anschauen:

github.com/xsnoopy/LinuxCNC-Yalang-yl620...d?tab=readme-ov-file

Der RS485 Anschluss scheint stoeranfaellig zu sein. Ich wuerde das maximal zur Rueckmeldung der Drehzahl nutzen, nicht aber um die Spindel an und auszuschalten.

Falls du ModBus mal testen willst, nimm bitte einen USB / Serial zu RS485 Adapter mit A/B und GND (Masse). 120Ohm Widerstand am Ende der Verbindung nicht vergessen.

The walkthrough attached to this post might also help:
forum.linuxcnc.org/ethercat/56545-step-b...shine-to-pi-5#331624

The trick to freeze the VFD PID when not on the limits might be to set maxerror to a very small number (actually = 0 means "no limit") using a mux component.

If I was trying to retrofit the Schaublin I think I would take an approach like this:

1) Use one PID to operate the variator, Use this as the main speed control.
2) Use a second PID to control the VFD, but have this set up to default to 50 (or 60) Hz when disabled. The pid component appears to set the output to zero when disabled, so you might have to use sum2 to add on 50Hz / 3000rpm / whatever to the output.

Then the idea would be to use the variator for speeds inside it's operable range, but then enable the VFD PID to extend that range when the variator is on the end-stops.

Incidentally, the PID gains are full HAL pins. The "lincurve" compoinent was written to allow for dynamic gains to be fed into the PID, if you did need to tune differently for different gears.

Pi5 might work better. But given that you have a 7i96 the Pi4 should work fine with the latency shown. (Just don't watch YouTube while milling)

andypugh wrote:

Looks impressive.

+1