Advanced Search

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.

scurve planner is in master?
Have you completed it and is in working state?

I had not installed any locales. I was under the impression that it was already in english as default. It was C.UTF-8 as default.
I installed en_US.UTF-8 and chose that as default.
Now it works!
Thank you!

That index helps a lot. For a newb like me it is hard to find the relevant info in all of these threads. I guess it becomes a lot clearer when one has spent a few hundred hours on here

Next step is to connect some stepper drivers to confirm that the setup works.

I found that the high feedrate is made by "#<fscale>=10000" in linuxcnc sample ngc file. thanks

someone help me to config mesa 7i97t and servo wiring