Advanced Search

@Finngineering: So you did not start a rewrite? I see it the same way. The actual component looks like a school book example of object oriented design, then it didn't suite the needs, took way more time then estimated and the needed redesign, simplification and finalizing never happened. But for a rewrite, the chances are high the same will happen and to get it to the functional state the actual module has, it will take a lot of time. So if it works now, fine. If there emerge unsolvable issues, we can think about it again.

I looked quickly into the xhc-hb04: is way less complex but it also has less functionality. I find this automatic change to manual quite nice. And the xhc-hb04 has a complex hal and config file which probably also makes it difficult to use.

@rodw: As I understand linuxcnc, before homing, you can only jog single axis due to the kinematics needs homing. But due to jogging Y1 separate from Y2 will bend the gantry, this is deactivated like in my machine using HOME_SEQUENCE. I don't need jogging before homing, so that's fine for me.
However, the WHB04B tries to activate jogging also before homing and then generating errors. For me, that's a non-issue, I just don't touch the wheel. And if it happens by accident, nothing else happens except an error messages.
For non-gantry machines, you can jog also before homing, so I did not remove that functionality because it might be useful for others.
An solution would be to add a command line option for this. However, I rather create some chips than continue coding...

Additionally, I started another rabbit hole which is more important for my machine:
github.com/LinuxCNC/linuxcnc/issues/3839

Just a note: Linuxcnc is just a hobby for me I started recently. But I have a lot of experience in coding and bug fixing from my day job and I figured fixing the issues I am having myself and creating PR's would give something back to the community.

It sounds like you get gravel in the servo motors from time to time.
Or you get click sounds from the motors. It repeats itself with a few or many minutes apart.
The first thing to do is to enable syncToRefClock and enable DC mode for the servos,
this will keep the servo loop in sync with the DC.

What grandixximo is doing here is fixing an effect that despite DC and servo loop are synchronized,
the two loops have been started with an undetermined/unfortunate phase between them.
The gravel sound is there all the time and it doesn't go away until linuxcnc is restarted.

Surprisingly, yesterday Sasha Ittner popped up in the PR log and mentioned he had been working
on a complete redesign of the DC system, eliminating all these problems (don't know details)
grandixximo seems to have reviewed that work and decided to adopt Sasha's work.
grandixximo will have to say himself. And if you don't know, Sasha Ittner is the author of linuxcnc-ethercat
from many (>10) years ago.

I don't think this will be of much use to you.
There are many topics and instructions on setting up LinuxCNC EtherCAT.
First, check whether your system and CIA402 servos are compatible. Then start setting up your system using the templates. If you get stuck, start a topic in the forum.
This thread is not suitable for that.

Hi,

I also need to ask about this.
How does the jitter problem manifest itself?
Can I see it in the dmesg output?
I have tried to read up on the topic on GitHub, but I still don't understand the actual problem.
It's also a translation problem. 
Another question: is this patch already implemented in the current linuxcnc release, or does it have to be installed manually?
Is there any documentation on the additional commands, where and how they are called?

regards

andrax

Hi everyone, I’ve been away for a few days focusing on the hardware side of the project.

Regarding meister's tests: they are very interesting! They confirm exactly why io_decoder is specifically designed for HMI (MPG, buttons, and operator panels) rather than real-time axis control.

While a 100-200ms jitter is critical for stepper motor timing, it is virtually imperceptible for an operator pressing a 'Coolant' button or turning a feed-override knob. By moving the logic to a dedicated user-space thread in v1.1.0, we ensure that even these USB latencies never interfere with the core LinuxCNC Real-Time performance.

Small update: I’ve just ordered a very limited run of 5 'Ready-to-Use' hardware kits (Core + IN/OUT expansions) for those who want a plug-and-play experience without the hassle of SMD soldering. I'll have them in my hands soon for final testing.

If anyone is interested in being one of the first 5 'beta-testers' for the official hardware, stay tuned!

Linuxcnc wont start , how do i CPU that right ? I have no Internet connection in my Workshop thats why i have to download the file and Transfer it with a USB Stick , and when i made this an error accured

its so automatic I can't remember  source dir I think. 

I think there is an oversight in the homing model. I can't see why joint axes can't move in unison before they are homed. If my first machine didn't have a gantry, maybe I'd have a different view. I've often wondered why this treats each side or a gantry as seperate axes when they are always joined at the hip!

Ich kann auch kein neues Thema eröffnen. 

Um eine detaillierte Fehlermeldung zu erhalten, muss der Debug-Modus des Forums aktiviert werden. Dann gibt das Forum eine klare Fehlermeldung aus. 

@ tommylight:  www.kunena.org/forum/36-German/169090-in...timmte-themen#234690

 

Gruß Mücke 

There are always situations with tool and work piece geometries
and unfortunate stop situations where one need to stick the nose (eyes) close up
to guide the tool out of the situation before it's free for homing.
I guess the best is to leave it up to the user if he wants to jog before homing.

Hi Thank for reply.
The git pull command start with terminal in SRC directory on base directoiry ?

Thanks

git pull
make
sudo make setuid

That's it so simple!

Good morning. I compiled LinuxCNC master version 2.10.0 running in place, downloading it from Git, about a month ago. How can I update the source code to the current version and then recompile it with the latest bug fixes?

Thanks

What kind of error?

I was thinking of building a new image for the Raspberry Pi 5. It will feature 2.10 to get scurve planner and be on Trixie and use the 6.12.74 RT kernel
Is there any reason not to use our current installer framework? 
Is there anything that desperately needs changing?

It just seems to be still the best way forward and I have the template to start with.