Advanced Search

We've recently suffered a problem on our DMG CTX 310, with an error on the HSCI bus. Had to change the PLC I/O board, which is not cheap.
Finding a generic drive for those servos might be a problem. If I were you I'd toss the Heidenhain stuff, make some servo motor mounting adapters and just get new servo+drive sets.
I worked on a project with some Leadshine EL7-EC servos and drives through EtherCAT (although not with LinuxCNC, but they could easily be integrated) and can recommend them. Very smooth motion, quick integration and easy tuning. I also used a Mesa 5i25 + 7i76 on another project and the Leadshine EL6/EL7-RS should work just as fine through Step/Dir.
Motors are compatible with both series (23-bit encoder). Big pluses of EL7-EC vs. EL6/EL7-RS is (to me) STO. Both series are relatively inexpensive.


 

delete the red text

and change lines like

net joint-0-pos-fb <= hm2_[MESA](BOARD).0.stepgen.00.position-fb

to net joint-0-pos-fb <= hm2_[MESA](BOARD).0.encoder.00.position

If you want encoder feedback (closed loop) rather than stepgen feedback (open loop)





# position command and feedback
net joint-0-pos-cmd <= joint.0.motor-pos-cmd
net joint-0-pos-cmd => pid.x.command

net joint-0-pos-fb <= hm2_[MESA](BOARD).0.stepgen.00.position-fb
net joint-0-pos-fb => joint.0.motor-pos-fb
net joint-0-pos-fb => pid.x.feedback

# PID Output
net joint.0.output <= pid.x.output
net joint.0.output => hm2_[MESA](BOARD).0.stepgen.00.velocity-cmd

# ENOCODER
setp hm2_[MESA](BOARD).0.encoder.00.counter-mode 0
setp hm2_[MESA](BOARD).0.encoder.00.filter 1
setp hm2_[MESA](BOARD).0.encoder.00.index-invert 0
setp hm2_[MESA](BOARD).0.encoder.00.index-mask 0
setp hm2_[MESA](BOARD).0.encoder.00.index-mask-invert 0
setp hm2_[MESA](BOARD).0.encoder.00.scale [JOINT_0](ENCODER_SCALE)

net x-pos-fb <= hm2_[MESA](BOARD).0.encoder.00.position
net x-vel-fb <= hm2_[MESA](BOARD).0.encoder.00.velocity
net x-pos-fb => joint.0.motor-pos-fb
net x-index-enable joint.0.index-enable <=> hm2_[MESA](BOARD).0.encoder.00.in
net x-pos-rawcounts <= hm2_[MESA](BOARD).0.encoder.00.rawcounts

# Home
net home-x => joint.0.home-sw-in
net x-neg-limit => joint.0.neg-lim-sw-in
net x-pos-limit => joint.0.pos-lim-sw-in

The controller I linked to gives a max RMS current of about 6A.

This one is on sale for 80% off!
www.aliexpress.com/item/1005005291871448.html

Max RMS current is about 5A.

(After I've already purchased it, of course)

I am very, very unlucky

I know they are 6-wire, but perhaps they are 8-wire internally.

No worries, it is Linux and 19.3 still gets security updates and Firefox also updates regularly.
I have probably over 10 machines on 19.3 in daily use, connected to internet with no issues.

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