Advanced Search

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.

Update on this:
(a) I have connected 220v power to the machine and have confirmed that the drives and servos all work. I will be able to use this machine in its entirely with 220v single phase input on 12HP spindle (will run it at 4hp max) and run all the drives  (8 of them, XYYZ, AA BB). These old amp drives were set up to run the DC brushed servo at max rpm if the signals (10V,tach,EN) were all OPEN - sort of insane. Thankful I had the foresight to disconnect the ballscrews from the servos. I don't have workspace - working ON the bed of the machine with the controller. See pic. Could have been a final destination sort of outcome. 

(b) Hunted down faulty monitor display to a few bad connections and once those were fixed, my LCD display is actually perfectly good, this allowed me to actually test out the machine's ability to work. The linuxcnc mindhive (grumpy old dudes who have forgotted more shit than I will ever learn) helped me out immensely like with everything else. Have to look at the fagor 8055 manual to understand what to expect from triggering the limit switches but other than that, I have a big functioning CNC router. There is some weird stuff going on which I do not understand - the servos are not paired corrected, meaning, moving "controller Y" physically turns one X servo and one Y servo. A few wires need to be fixed and I need to make sure stuff turns in the right direct and get synced and what not. Maybe its a controller setting. I have no intention of using the Fagor controller and will likely not waste time on it. 

(c) Mechanically, Y axis is good. Z axis is good. the X-axis is "grinding". Will remove rust with neutralized citric acid and starch to get me a chelating paste. and repack the bearings on the X axis. I hope it is not a bad ball screw. The blocks that glide on the linear rails are these things that have 2 rows of bearings that slide along the groove. I have no experience whatsoever with these. Any and all tips super appreciated.

(d) Ordered my 5in rotaries. Found this design where the 5in chuck is connected to a wormgear with 20:1 reduction. backlash (10arcs) seems acceptable. The reduction gives me holding power that will all but eliminate any issues with holding the word steady. Adding up the 2 chucks, I'll have in the region of 200Nm of torque on my work pieces. Happy about this. 

(e) Gambling that it will be OK to hang 200lbs off the gantry for the swivel head + spindle. Found some implementations of this with older heavier hardware so I'll take my chances. I might have to upgrade the air balancer, or add a counter weight to the gantry. In any case, its too late. Stuff is ordered and they don't do refunds.

(f) Fun times. The entire manual for my spindle contains one single word of English. It says No! on page 19. See attached. Everything else is in Chinese that I can't read. Hopefully AI translation is decent. Same company with spindle and swivel head. Very happy to have found them. Not pushy. Don't give bullshit answers. Take pride in explaining stuff in engineering speak. Feels like a bunch of guys trying to make the best damn product they are capable of making.

Some questions that remain:
I wonder if I can reuse the dynamic brake and reactors. They are rated for the amperage that I will use with my 9kw spindle. I don't see why not, but I do not know for sure. I also don't understand from first principles what a reactor does. I think they are inductors to smooth out ripples in the outgoing current from VFD to spindle.

Grease. What should I use? I wanted to change the color of the grease so I know which lines are blocked, but someone cautioned against mixing stuff.

Ball bearings. Should I just put new ones in while I'm at it, or, do they last a lifetime? Do I caliper them? Is it even meaningful to? Surely the precision needed would be far more than my 0.02mm caliper. 

July 4th. This has to make a chopstick by then.
 

OK I guess I got too swayed by the "homing" in the title when in fact this looks like a C axis
programmed path where the "steps" are real.

It basically looks like  the acceleration is too high to the spindle to follow. This may just be physics
(inertia vs spindle motor torque) or programming (some acceleration limit set in the drive)

@Hakan @papagno-source
I get worse OP times with 1.5.2
Is that the case for you as well?
Do you have a kernel + linuxcnc + linuxcnc-ethercat + ethercat
versions combination that gets everything ready sub 1 sec?
Before axis opens or just as axis UI opens up?

gitlab.com/grandixximo/ethercat/-/jobs/1...ad?file_type=archive

Here have debs of ethercat 1.5.2 compatible with debian 13

github.com/grandixximo/linuxcnc-ethercat...0.9.5-retro1.5.2-rc1

and here a linuxcnc-ethercat compatible with the 1.5.2 retro release

you need to type in the mac address and use generic in the systemconfig/ethercat file, in my test OP is same speed, please test on your end and let me know.

linuxcnc-ehtercat retro version I only tweaked latest version based on Sascha's work, and did minimal changes to be compatible with retro 1.5.2 ethercat

I'm trying to revisit this again. (and still failing)

I am trying to insert the Gladevcp Offsetpage widget into a tab in the Axis user interface. The tab and Offsetpage widget are opening and seem to function (sort of), but it is showing all offsets as zero. I can use the edit button in the widget to set an offset to some value, and that offset is set to that value in Linuxcnc. The problem is that the widget will not see what current offset values are or are set to by other means in Linuxcnc.

What am I missing to make the widget read the current offset values from Linuxcnc?

Hi everyone,I've recorded a short video demonstrating NativeCAM 2.0b (Python 3 / Gtk3) running on Debian 12/13. You can see it in action here:Video: In this video, I demonstrate basic operations and G-code generation, showing how the new Gtk3-based interface handles the workflow.P.S. For those who want the full experience: please note that to correctly display tool orientation in the preview, some modifications to the core LinuxCNC files (and) are required. I will provide more details on these tweaks if anyone is interested.Best regards, Axemas

Hi Zbigi,

Great to hear it's working!

Regarding the "Master treeview minimal width" — yes, this is a known
GTK3 issue. The setting uses set_size_request() which GTK3 ignores
on paned widgets. Will be fixed in next release using set_position()
instead.

Thanks for the feedback — every report helps improve NativeCAM!

Best,
Axemas

 
 re homing, read the homing configuration chapter in the docs. linuxcnc.org/docs/stable/html/config/ini-homing.html
In fact read it about 3-5 times so it sinks in as its not a light read! Both sides need a home switch that remains triggered to the end of travel. When HOME_SEQUENCEs are set up correctly, the first side to hit a home switch stops and waits for the other one to catch up then homing continues in unison. Setting  HOME_OFFSETs allows you to square the  gantry on the final move with no need to physically adjust home switch position.
 

Hi Tom,

Thank you so much for the kind words — it really motivates us to keep going!

You are absolutely right about the lathe polyline / contour cycles.
This is exactly on our roadmap. G71/G72/G73 in LinuxCNC 2.9 are now
working properly, so the main blocker that stopped Fern is gone.

Planned for lathe:
- Polyline function (contour definition)
- G71 roughing cycle (OD/ID)
- G72 facing cycle
- G73 pattern repeating cycle

This would indeed bring NativeCAM lathe close to ShopTurn level
for conversational programming — without needing external CAD/CAM.

No timeline promises yet, but it is a real priority.
If you want to follow progress or report issues:

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

Thanks again for the feedback — users like you make open source
worth working on!

Best regards,
Axemas

Hakan wrote:

I tried to compile 1.5.2 on trixie but easier said than done. While I could get around several configuration issues,
there were in the end too severe compilation problems (for me) that I gave up.
At least 1.5.2 doesn't compile out-of-the-box on trixie.

This does not surprise me. I found over the years of keeping repositories in sync, Ethercat includes dkms code which is tailored for specific kernels and breaks with the release of new versions of Debian. This did happen again with the release of Trixie but etherlab expedited the release of 1.6 on my request so you guys probably never noticed. Also, 1.6 is much more sensitive to secure boot and this requires authorizing dkms to modify the kernel code.

please come over to discord

discord.gg/6mKut8xe

Forum is down way too often, I'm also trying to build 1.5.2
Honestly I don't think it will fix anything, not sure if is worth it, but I am building it
gitlab.com/grandixximo/ethercat/-/pipelines
not ready yet, only generic drive will work.

also

github.com/grandixximo/linuxcnc-ethercat...ses/tag/v1.41.0-pre1

did you test?

net sig_reducer_left_center  mh400e-gearbox.reducer-left-center <= hm2_5i25.0.7i84.0.2.input-03
net sig_middle_left_center   mh400e-gearbox.middle-left-center  <= hm2_5i25.0.7i84.0.2.input-07
net sig_input_left_center    mh400e-gearbox.input-left-center   <= hm2_5i25.0.7i84.0.2.input-11

I don't have such inputs on my machine. They are on the 28A1, but they are not in the loops. They immediately increase the resistance when triggered, but do not go to the controller. Can I configure the switching without connecting these signals?

We need to join forces and solve this problem once and for all, otherwise there's no point in switching to Debian 12 or Trixie. Keep in mind that Debian 10 works on both older dual cores and i9s. I've tried Trixie on Advantech e8500 cards, and it doesn't work. If we don't solve these existential problems, there's no point in updating the string writing style, or doing many other things that have always worked, but now we want to update the writing style. I've been building LinuxCNC machines for 17 years, and they're still working flawlessly and do everything we do today. Now we need to solve this problem, and I'm available to run any tests. It would be nice to be able to compile LinuxCNC 2.10 on Debian 10, but I understand the dependency issue. We need to figure out if the problem is on the Kernel or EtherCAT side. I could contact anyone who can help us with this, so they can move forward with the fix. Grandixximo's work is to be commended, but he is optimizing a problem, which is not the main problem.

I tried to compile 1.5.2 on trixie but easier said than done. While I could get around several configuration issues,
there were in the end too severe compilation problems (for me) that I gave up.
At least 1.5.2 doesn't compile out-of-the-box on trixie.

In theory the DC sync should be pretty insensitive to jitter and latency. It should tolerate perhaps 1/2 servo cycle time,
depending on the phase when data is sent to the slaves. It's enough that data arrives a bit before Sync0,
Sync0 then does the precision timing.

I also think the initial synchrony check delay is different from the DC sync issue.
I checked on my system and I do have a several-second delay still. Bad news.
Good news is that I can try to see what the problem is.

So far I have come to understand that it has to do with the initial value
of the "System time difference" in register 0x92c.
Here is a way to observe, don't need to wade through tons of lines of syslog entries:-pn n is any of the DC slaves except the first one with the reference clock.

Before starting linuxcnc it has a low value from previous linuxcnc session.
Start linuxcnc it jumps to aorund 1000000 (1 ms) and slowly works its way to do single digits.
This is on a 2 kHz servo loop system. It takes some 3-4 seconds to work its way down 
below the synchrony limit, and that's where the startup delay comes from.
Obvious question is "Where does the initial 1 ms System time difference come from?"
And it's always around 1 ms, if I wait a minute between linuxcnc starts or over night.