Advanced Search

This are the results
for what i understand are good for mesa Ethernet boards
Now i´m gonna try to make connection to the board
its that okay?
 

After a moment's reflection I do get it. The 2.9.9 bug is serious because it could result in existing gcode not only not working but causing damage. So the 2.9.9. code had to be removed, and as the upgrade process still sees 2.9.9 as the "current" version, update attempts are going to fail.

But I would still like to get away from the 2.9.5 bug, and so my question remains. Is there an easy way in which I can upgrade to a subsequent version that does not suffer from this bug?

Hi everyone,
Could you please advise what to do in this situation:

When reading the PDOs, I see CiA402 indices.

But when reading the SDOs, I get indices mapped at 0x1600 and 0x1A00, which belong to the hardware interface (AIF). This mapping seems to be specific to Lenze.

Previously, the drive worked under CiA402 on a dismantled machine controlled by TwinCAT.

Now, when I try to automatically generate the XML via lcec_configgen, the XML is created with the hardware-specific indices instead of the CiA402 ones.

Has anyone dealt with this mismatch between CiA402 and Lenze’s AIF mapping? Is there a way to force or configure the XML generation so it uses CiA402 indices instead of the hardware-specific ones?

Thanks in advance for your help!

Hi everyone,
Could you please advise what to do in this situation:

When reading the PDOs, I see CiA402 indices.

But when reading the SDOs, I get indices mapped at 0x1600 and 0x1A00, which belong to the hardware interface (AIF). This mapping seems to be specific to Lenze.

Previously, the drive worked under CiA402 on a dismantled machine controlled by TwinCAT.

Now, when I try to automatically generate the XML via lcec_configgen, the XML is created with the hardware-specific indices instead of the CiA402 ones.

Has anyone dealt with this mismatch between CiA402 and Lenze’s AIF mapping? Is there a way to force or configure the XML generation so it uses CiA402 indices instead of the hardware-specific ones?

Thanks in advance for your help!

But I'm already dealing with a a bug in 2.9.5, and not being able to specify an offset when touching off the Z axis is a lot more relevant to me than the 2.9.9 bug appears to be.

I presume that I should in fact be aiming for 2.5.6, or perhaps 2.5.7 or 2.5.8. How do I go about upgrading to one of these versions?

Thank You all, for reply and taking care of this. I wrote already, why this update leads to problems with my workflow.
Sorry it's me, sometimes complaining after a new release, but i like the system running rocksolid and safe - then i have a relaxed time, operating the machine.
About new releases, its always great work with all that fixes and improvements.



 

Do not update/upgrade unless you explicitly need to.
2.9.9 is removed due to a bug sneaking in.

I would like to thank everyone that replied to this thread. PCW your suggestion did the trick. Iam now able to ping 10.10.10.10.

I've tried to follow the steps listed in the hope of getting from 2.9.5 to 2.9.9, but the upgrade fails with the following error message:

Failed to fetch www.linuxcnc.org/dists/bookworm/2.9-uspa...pace_2.9.9_amd64.deb 404 Not Found [IP: 69.163.143.134 443]

What do I need to do?

I have deleted the debs from the server (as much as I could do while at work) and will work on getting an update out this evening (GMT+1)

That version was the one that introduced the bug so you would need to update to a later version as this issue was fixed in 2.9.6.

Note the current version in debian (2.9.9) has an issue affecting tool offset parameters:
forum.linuxcnc.org/38-general-linuxcnc-q...38-2-weird-behaviour

So you could get the appropriate deb package for version 2.9.8 from here:
github.com/LinuxCNC/linuxcnc/releases

Or wait for version 2.9.10 to be available in the debian repositories to be able to update through the update manager.

Looks fine but for mesa its better to run: latency-histogram --nobase --sbins 1000 --show to get rid of the base thread window which gets in the road. and can suppress results. Run that and reshare.

I've just finished installing the system, disabled all power-saving features (C-states, SpeedStep, etc.) in the BIOS, and isolated a CPU core using isolcpus.

Here are my latency test results while stressing the system with 4 instances of glxgears and a YouTube video playing in the background

Note: I am currently running this test using an old VGA monitor. I suspect the analog output/Xorg driver might be causing some minor latency spikes compared to using a pure digital connection, but I'm not entirely sure.

What do you think of these numbers? Are they good enough to move forward with my Mesa setup, and what should my next steps be?

Thanks in advance for your feedback!

LinuxCNC 2.9.5

The old behavior did not respect the old docs, the old docs also specified that the parameter are set with G43

Tool Offsets for X, Y, Z, A, B, C, U, V & W. Set by G43. Volatile.

I guess there maybe many subroutine codes that relied on the old faulty behavior, even when the docs state you should set them with G43...

But the reasoning to use a different set of parameters is strong, we have had it wrong for so long time, wrong is the new correct...

Edit:
github.com/LinuxCNC/linuxcnc/pull/4219
follow progress here, you should get 2.9.10 with this reverted change soon.
The new behavior is in #5081-#5089