Advanced Search

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.

Hakan wrote:

Get a real machine, rodw
In a milling machine and lathe, there are many situations where you may need to jog before homing.
To get the tool out of the way before homing for example.
 

I had a mill and am building another. I thought HOME_SEQUENCE was designed to get the tool out of the road 

Get a real machine, rodw
In a milling machine and lathe, there are many situations where you may need to jog before homing.
To get the tool out of the way before homing for example.

 

Hannes wrote:

@rodw: Jogging in manual mode is fine. My machine can not jog in teleop mode due to I have two Y axis servo motors. The only thing the WHB component does after my PR is:
- Change to teleop mode if not homed (which fails on my machine but on others, it will do that) -> You can jog before homing any special action
- Change to manual mode if homed AND program is idle -> You can jog after homing without any special action

In this case its far better to disable motion before homing with a simple change to the ini file. I still have no idea why people want to move or jog before homing. None of my machines allow this! And yes, one was a XYYZ gantry plasma table that jogged with a pendant perfectly!

andypugh wrote:

G71 and friends exist mainly as an alternative to CAM, to make hand-coding easier.
I don't know of any CAM system that generates G71 (which isn't to say that there aren't any). But I don't think much would be gained from doing so.
 
 

I am not familiar with any other CAM software for turning, but Fusion360 / HSMworks / Inventor CAM can do this.
 

The standard LinuxCNC turning postprocessor from the HSM library does not work without corrections (it uses Fanuc-style UVW for incremental offsets, which LinuxCNC does not understand). I don't know who added this post or why these corrections haven't been made in almost ten years.

G7X canned cycles are also not defined in this postprocessor, but you can add them by following the standard Fanuc turning postprocessor example. This will probably require verification and correction to match the LinuxCNC code-style. The cycles are defined in the following functions:
function onCyclePath()
function onCyclePathEnd()