Advanced Search

But no distro for bookworm. Now what? Build from source I guess.
Jim

Todd is right, that is the buildbot that builds the official Debian packages, and is always behind from the normal boluildbot Todd linked.
No idea why, but there were differences between those two builds for BookWorm.

Ja die ping ist OK.

Hello, thanks for sharing your configuration. I took a quick look and there is one thing I don't quite understand
net x-output <= cia402.2.velocity-cmd
net x-output <= pid.x.output
Is the direction above reversed? It should be
net x-output => cia402.2.velocity-cmd

after these ... discover just now most of my problem of these days become from "locale" bookworm setting .... I discover inside bokworm a patch named locale.gen that produce locale.alias in etc folder (all these 2 files) ... these for UTF-8 encoding compatibility .... not understand why but seems these causes a lot of problem with certain application .... because not able to transmit to all app the right encoding name. Some app not detect the right one and choose stadandard one of bokworm that seems to be "ANSI_x3.4-1968" ..... perhaps linuxcnc seems not  interested from these problem and discover too that linuxcnc deb package actually not use latex and no need it.

1. so not need to puge linuxcnc-ethercat?
2. Is for encoding problem that linuxcnc-ethercat not install all modules driver? .... Can I have the same issue installing Ethercat from repo 1.6 etherlab??

I waste 4 days for these "linguistic" problem ..... no need waste more ....

those of Debian are extremely meticulous with open source licenses .... too mutch perhaps ....
 

Hi all, I've been working on a custom VCP using gscreen and Glade. So far I have a semi-working VCP (not all the widgets are linked to their respective functions yet). I've been working on a simple custom widget that displays an axis position and a homed indicator LED. I realise this would be simpler to achieve just using stock widgets in Glade, but I wanted to have a practice run for if I make more complex widgets down the line. I took bits and pieces from the existing widgets found in linuxcnc/lib/python/gladevcp/ to try and get something working.

I managed to get the widget running and displaying correctly when run straight from the python code, then for a small window managed to get it to show up successfully in glade too. However I then somehow broke it to where it no longer appeared in glade, and then broke it even further so that it throws this error when running from python:

Can anyone tell me what exactly it is that can cause this error to occur? I've been running tests and googling to no avail. For bonus points, if anyone can tell me the difference between the linuxcnc/lib/python/gladevcp/ directory and the /lib/python3/dist-packages/gladevcp in terms of development (both directories have identical contents apart from the hal_python.xml file that is required for listing custom widgets).

I've attached all the files that I think might be relevant to the problem (but let me know if I missed anything). Thanks!

Nice! I'm glad you were able to see the issue. I apologize for the late reply. I will update this week and verify the fix. Thanks!

Update: Just verified this today and had no issues using the straight cut function to slice a sheet in half. Thanks again!

Some reading later and now I am investigating for DC Sync misconfigurations or problems.

Firstly, I noticed the BASE_THREAD in the .ini was set to 0. Why that was the case? I have no idea. I set it to 60000 as that was what the latency test reported and then decided to give it more headroom and set it to 100000. I'm still testing if this helped or not. I couldn't find any documentation on this value for servos, just for step motors. I'm not sure if the step motor logic can be applied to servos in this case. Could that be why the value was set to 0 (as in, is it irrelevant for servos somehow)?

I can definitely confirm that changing refClockSyncCycles in the .xml affects the machine behavior greatly. Initially I had a wrong understanding of what that value does so I set it to 60000 as well... That lead to extremely violent noises from the machine. I then tried to set it at 4 as my previous colleague had left it. Definite improvement, but there are still weird vibrations and noises sometimes, especially during homing. I then tried 1, 0 and -1 and -1 seems to give the best result, however the amplifier faults and following errors are still there.

From what I read, refClockSyncCycles="-1" used to be something only available if you additionally patched LinuxCNC, but from 2.9 onward that patch has been merged into the version that comes standard with the ISO? Could someone explain to me in more detail what this does? From what I get this is the so called "Slave Synchronization Mode" which is dependent on the master appTimePeriod and the PID values? However, my configuration uses digital servos, which should not require a PID config, correct?

Another thing I did was to reduce the axis acceleration rates drastically in the hopes that that would catch the error, but it doesn't seem it did yet. Now it does not reach more than 3200 velocity, even if the max is set to 6000mm/min.

A different approach I read about is the sync0Shift value of each slave, however I read that it must be the same as the BASE_THREAD. And that is already the case in my config.

I have not yet tried playing around with the FERROR values. I will try that tomorrow. I am seeing conflicting reports on them, though. The docs state that 0.0 is the minimum and 1.0 is the maximum, right? But even then, across the forums I see people with various configurations that have the value set as high as 5.0 or even 10.0?

I don't think that is the correct link to the Linuxcnc Buildbot.
The one here.
buildbot.linuxcnc.org/dists/
shows a last build date of 9/15/2024