Advanced Search

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

Looks impressive.

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.

Here are the 2 screenshots of the Pi. One whithout anything but the Desktop running, one with glxgears running (window resized to about the double).

You might have problems with tool radius compensation if you use the orientation, but only if you are doing compensation in the control rather than in the CAM.
So, basically, as a purely graphical fix, it will probably work.
You will need to have different orientations in the CAM tool table and the control tool table, but there is no auto-synching anyway, so that's not a problem.

Hello everyone

I've been working on a web UI for LinuxCNC for my own use and thought I'd share it in case anyone finds it useful. Note that I'm not a professional programmer and this was largely AI-assisted, so take it for what it is.

Greetings

github.com/bildobodo/lcnc-suite.git

       







 

So,

I have a great update. I got the machine working. Using the X-minus hall switch did not do the trick. Testing everything that I already thought was not the problem gave me the solution. The magnetic linear encoder in the X axis was the problem.

I did most of the testing of it at low speeds and short distances, as my indicators obviously cannot measure the length of the full axis. I can remember doing a test running the whole axis at rapid speed for multiple minutes, but I may have done this only on Z, it was two weeks ago. Or it got worse somehow, I don’t know.

In the end, using the motor encoder resolved all the problems.

I also disassembled the X axis to see how the encoder is installed. There is a very small read head in the plate behind the thrust bearing for the ballscrew and a putted scale in the underside of the X-axis slide.

I also made some pictures of the Z-axis encoder.

And then, after I spent all day getting this done, I was able to actually make op 1 on the test parts I wanted to make as test parts.

I've equipped the A6 with a battery-powered encoder cable.
No homing, no problems.
However, I would also recommend the following thread:
forum.linuxcnc.org/ethercat/58103-etherc...fix?start=160#345453

You will need to modify the gearbox comp and recompile it. I didn't write it myself, it was written for me by a friend, so you might need to find someone to do the code changes.

Tested a bit.
I get fairly consistent loading times of lcec's rt_app_main() function of 1.85-1.90 seconds.
But but. In syslog I can see that the initial sync of slaves takes anywhere between zero and
say 3,4,5 seconds. 
To check
ethercat debug 1
start linuxcnc
exit or leave running, doesn't matter.
sudo journalctl --since "2 minutes ago" | grep "Sync after"
and see where it stops for every slave.
I reckon this is the problematic delay time.
Seldom, but it happens, I get "Checking for synchrony" and then it is satisfied directly and moves on.

It seems measuring the time of lcec's rt_app_main is not a good indicator.
Is there a good way of measuring time to OP?

trixie, 
Linux plasma 6.12.69+deb13-rt-amd64 #1 SMP PREEMPT_RT Debian 6.12.69-1 (2026-02-08) x86_64 GNU/Linux
IgH EtherCAT master 1.6.8 1.6.8.g2543cc5-1+27.3  (via apt)
linuxcnc-ethercat, a slightly modified version of commit bf13577ec7b1b54844e07a80d949232e71776b32
linuxcnc 2.9.4 (via apt)

 

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

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.