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.

Code:

 

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.

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.

 

Starting to set up spindle status displays in Flex and ran in to a snag.

The documentation isn't explicit about how to reference multiple spindles, but I'm guessing the "0" in dynamic property like spindle_speed_0_lb is for [SPINDLE_0].

Problem 1 - spindle_actual_speed_lb doesn't reference a particular spindle.  Oversight in documentation, or was this not set up for multiple spindle encoders?  Document also has this note:

So I'm not sure if I should use the spindle_actual_speed_lb, or just set up a HAL float label.

Problem 2 - document indicates Flex looks for [SPINDLE_0]:
What about other spindles?  I've got three spindles on my lathe (main, sub, live-tool), and (theoretically) all three could be running at the same time.

I can probably muddle through using HAL labels and so forth, but was wondering if there's a built-in set of spindle connections I'm just not seeing.

Thx

That info is pure gold rodw, thanks a bunch!
- Dual homing switches were the plan yeah, just checking if it's fine to have a single limit switch or if i need one i both sides?
- I'm currently using a PWM output + an RC circuit to get 0-5v for my spindle RPM but had already got the suggestion of using serial to talk with the VFD, glad to confirm that is a good approach.
- IO modules, if i can get what i need from used beckoff listings on ebay i might go that way. The servo inputs should take care of all the homing/limits, and if the VFD is handled separately, one of the most common ones with 16 IO might just do for e-stops, probes.. And i can always just add another module if that changes.

The concept of the break is also new to me, is this something you need to config or it's something that's handled automatically between the servo and its driver?

I don't think you will have any problems getting the drive going. I'ver noted many attempts with this drive have been flawed from the very beginning. The fact is they are cia402  drives and this means the core Ethercat registers are standardized and there are components to follow the cia402 state machine to start the drive. 

I would use Linuxcnc homing and forget about internal homing for now because of your 2 joint main axis (We would say XYYZ). Internal homing of a joint axis by Ethercat is a bit unknown/unsupported. Note having homing switches on both sides is mandatory on gantry machines. The gantry is auto squared on homing.

There should be some inputs on the servos themselves you could use if configured to be generic inputs in your ethercat-conf.xml. The safest/easiest IO would be to use Beckhoff EK1100 but there are several on AliExpress like Rtelligent, deiwu (I have used both, configs here github.com/rodw-au/linuxcnc-cia402 ) and another with an encoder input called catio-a which is mostly documented here on the forum. I have one of these and the forum config generally works (I have one of these too).

Note that the Beckhoff encoder modules are quite expensive but with a printnc style spindle, you probably don't have a spindle encoder. You could use RS485 modbus for spindle control with a USB or RS232(preferred) RS485 interface. This works pretty well with ethercat. I've been playing with the modbus control on the catio-a and  read one register once but then could never repeat it after adding all of the required registers.

Good luck

Yes, same as those. I had seen the success case from dschultz in there around the middle of the thread, which is encouraging, but I'm mostly polling on thoughts from people that might have succeeded with them and not ended up coming back to post about. Also, in general about anything that I might not be considering about my linuxCNC + ethercat in one go.