Advanced Search

I'm currently running Mint 19.3 and the 2.9.0 pre-release with the 5.something RTAI kernel. Is there value in upgrading to mint 22.1 with the RT-preemtive kernel?
I don't have issue with version 2.9.0 pre-release but lack of 19.3 support concerns me since this system does have network connectivity for transferring files.
Thoughts?

forum.linuxcnc.org/10-advanced-configura...to-example-mesa-7i77

Regarding robustness, I have downloaded new firmware to my IO card on a running linuxcnc system. It still works and comes back online. One can always wonder how good it was that it was away for half a minute. But nothing crashed, nothing stopped.

Thanks for that document. I had already looked into it and tested what you write there.
Unfortunately it wasn't sufficient on this mini-PC and these realtek network adapters to make the datagrams UNMATCHED go away.
On another system I have it worked fine on the builtin realtek driver though. If I remember, your settings worked on the J1900 I briefly tested.

I am aware of the coalesce settings, but I didn't have to set them to zero on the Intel cards. It worked fine anyway, they are at 3 usecs still.
When I come around to it I will set them to zero in the interfaces file.
I can't find a good way to enter non-energy-efficient mode. It doesn't seem possible (at least easily) to set it in the interfaces file.
If I remember it resets the interfaces when entering or leaving ee mode so nothing I want to do too often.

There are plenty of those mini PC but it is exhausting to search for them. They have product listings with CPU options that are dirt cheap, but after choosing the N100, memory and disk they cost quite a bit more. The one you list look alright, not that I need RS485. Found it on AliX as well. There is now the N150 which is almost identical to the N100. I wouldn't pay much more for that one, maybe a fiver more.

Hi Rodw,

I really hope Clive can use the planner with the plasmac application and even get a better result.

And yes the centripetal radius can be used to calculate cut speeds. Your approach should work ok.
If you need any additional hal pins, don't hesitate to request a feature.

For plasma's true hole technology we could also give a-axis, b-axis values to compensate kerf angle at runtime.
This is simplest solution that can be done by 2 tiny motors attached on z axis torch holder. A compensation range
0-15 degrees should be ok in x,y direction.

From that perspective we could also compensate the tp xyz position output so that
the torch kinematics stay valid, the tcp stay's valid when torch angle is compensated.

This are just idea's.

I will have to try your planner now
Yes, I know how hard you have worked to achieve this planner.

The theory I had was to calculate the cetripetal radius at a given cut speed so that we knew the radius below which the torch must slow down due to physics. Then we could apply some yet to be invented algorithm to the cut parameters. One idea was to stop managing the process control variable voltage to keep height stable, and we would lock the torch height and then alter current as a process control variable to maintain constant torch voltage. In this scenario, the kerf width should stay constant as the arc is negotiated. When you have perfected this planner, try that on your machines

Hello, today I had the opportunity to update LinuxCNC on this machine (it is normally not connected to the internet). I'm happy to report that the problem has disappeared!
Thanks a lot!

Most AI's lie. Grok gets it right

Does Linuxcnc support jerk limited motion?

As of the current date, March 28, 2025, LinuxCNC does not natively support jerk-limited motion in its mainline trajectory planner. Jerk-limited motion refers to controlling the rate of change of acceleration (jerk) to achieve smoother motion, reducing vibrations and mechanical stress on a CNC machine.

This is all I use now

Hi Urvilsuthar,

That's likely an ai hallucination.
Or maybe Tormach is pushing their work, finally .

@Vre,

It's not in master at github linuxcnc. I use Codeberg to host source code.
It is in working state. But as always. It just needs testers, and feedback helps improve the final result.

@Rodw,
The arc radius of G2's, G3's are now also added to display in hal. tpmod.hal_segment_radius
Also the arc radius for the clothoid fillets are displayed in hal, same hal pin, to make it complete.

there is nothing to stop you from doing a pull request to Linuxcnc master
But then the donkey button is not visible anymore.
To be honest, this planner has a value for me to be around +$200.000 dollar in invested time.
On new shipped machine's, this is a game changer.
If i invested my time in building and selling machines, i made much more money. In fact i don't
give a shit about money anymore.

I give it for free to the world, under GPL2 licence.

That's why i hate the Tormach approach, where they keep their dev scurve software closed source.
And that's why Tormach may not use this software. It's stated in the licence. They are the only once's
that may not use my software, or ship my software. Because off their own behaviour to us, the community.

In return for my work i only ask for a tiny donation to the donkey farm in United States above San Fransico.
If users like the software, they can consider a tiny donation. The first donation is made already.

But Rod. You are free to push it to github yourself, as my account does not work any longer.

Great stuff. I have always maintained the more efficient Ethercat protocol makes it more robust than the hm2_eth protocol used by Mesa and I think you proved that with your tests.

There are a few additional optimisations you can do for either Intel or Realtek NIC's and I cover them here
docs.google.com/document/d/1jeV_4VKzVmOI...diY/edit?usp=sharing
Some settings to disable  Energy Efficient Ethernet which causes latency excursions and the forum scripts to set IRQ affinity
I might also suggest disabling coalescing as discussed in man hm2_eth as I think it might also help
linuxcnc.org/docs/devel/html/man/man9/hm2_eth.9.html

Anyway, my J1900 PC with Realtek NIC's is loving these settings and it running Ethercat perfectly. Currently running Trixie on it.

With regard N100 PC's with Intel NIC's, this one looks interesting even though it has a few too many NIC's. What is interesting is the RS485 serial port already built in for plasma cutters and VFD's
www.alibaba.com/product-detail/Linkleaps...N_1601225258750.html

This will be my next Linuxcnc PC

 

Hello everyone,I’m currently working with LinuxCNC on a Pi5 with a Mesa 7i95T. After getting the configuration for the motors and limit switches working, I’m now trying to set up the encoders (currently just for the X-axis). Unfortunately, I’m still relatively new to this, and I find the .hal configuration a bit overwhelming.
I’m getting the following error when starting up:

Debug file information:
Note: Using POSIX realtime
./main.hal:121: Pin 'joint.0.motor-pos-fb' was already linked to signal 'joint-0-pos-fb'
19234


I’ve attached my .ini and .hal files. Could someone please help me understand which inputs need to be connected where?Thanks in advance for your time and assistance

The servos don’t have tacos .The encoder is the ERN1387 which is listet as an incremental encoder in the data sheet with the “schnittstelle” being 1Vss. It does say ,in the data sheet,that it needs 5V . As I understand these encoders give an analog sinus-cosines signal which then gets  converted  by the driver electronics to digital signal. 

To reload the settings in /etc/ethercat.conf I restart the ethercat service
There are probably ways to just have the ethercat service re-read the config but that's how I do it.

Your new TP is a stand alone module just like the original designers of Linuxcnc intended. In fact, it is the first alternative TP module ever made to my knowledge. So really, there is nothing to stop you from doing a pull request to Linuxcnc master because the user would need to deliberately install it to break his machine!

But what grabbed my interest was you mentioning you have a tangential knife output. I am assuming by this means you  are outputting the heading which is tangential to the arc being traversed and the slope of the line if its travelling in a straight line. This is something which is in Mach 3 and something wanted for Linuxcnc. I did some modifications using state-tags that enabled the same feature. But while you are at it, why don't you also publish the radius of the arc being traversed? I have always thought this would be useful for plasma cutting so cut parameters could be modified based on the arc radius for better cut quality.

Thanks for trying. The hal files you bypassed are all well tested and are all for specific hardware so you could not implement them.

When you say that the velocity and acceleration is incorrect, I think you are expecting to see the axes values higher than the joints to allow for external offset ratio. But in practice, that is not necessary. I have them set as I always have since before external offsets was pushed to master 7-8 years ago.  After all, I was the one who worked out that we can double velocity and acceleration and use a 0.5 ratio because THC is mutually exclusive with gcode motion. The author of external offsets had not thought of this at the time. This was a major discovery that enabled THC control and ultimately qtplasmac without compromising velocity and acceleration.

I might add that there were a lot of constraints due to the machine design that we retrofitted with showstopper but the owner is happy as one job that took 2 hours now only takes 20 minutes because of QTplasmac.

Its little things like this that prevents him walking away from the machine on his lunch break! Hopefully, we will find a solution one day.