Advanced Search

How do you plan to handle bug fixes and feature upgrades? Do purchasers get free perpetual upgrades every time new features are added or are they stuck with the release that was active at the time of purchase? I can't see how the first option would be commercially sensible for you and the second wouldn't work for users.

Centroid have an interesting model where you can choose to pay for periodic major updates where new features have been added but otherwise you purchase is forever and includes free minor updates and bug fixes. Might be worth considering something similar?

Certainly it won't be long before some kind of machine learning / AI becomes usefully capable of this kind of feature recognition and takes a lot of the surprisingly laborious CAM off of our hands. There are hints of it already in CAM such as Fusion where you can use Claude to create toolpaths directly inside Fusion via its API and an "MCP" connector. I've done this myself and it's surprisingly powerful but at this stage it's not something I want to stop doing myself. In my experience, agents like Claude currently have the capability and dependability of an excitable junior engineer who doesn't know what he/she doesn't know. This will surely improve in the medium term.

Here's a view of the Claude / Fusion integration at work:

Parallel port.

I boot vmlinuz 3.4-9-rtai-686-rtae  (linux version 12.04 LTS) on Compaq Presario Desktop and run vi parallel cable.  I think this uses the pci 8255 driver, but not sure. 

Thank you jjdege.
Schaublin12: du müsstest die xml nur noch etwas anpassen. So in etwa:
Die Pins findest du dann in der Halshow

Em vez de seguir pela borda, a máquina faz uma curva arredondada.

Li sobre usar o comando G64 PX no início e funciona.

MAS! Fica absurdamente lento!

Existe outra maneira de obter um resultado melhor?

Doing some work on multiaxis improvements.

github.com/LinuxCNC/linuxcnc/pull/4374

Would love to get some feedback and testers if anyone had time, appreciate it.

Most interesting stuff at this stage might be G53.5, usefull to always lift the Z slide (joint 2) all the way up
G53.5 G0 Z0 (always move joint 2 all the way up regardless of tilt orientation)
and G53.7 Jn=nn
A gcode to move joints instead of axis, for robots and such similar to MOVJ in other controllers.

If you have a 5axis or a robot let me know what you think

Becksvill wrote:

Ecam.it which is another really good turning cam software in my opinion offers the software free for weekends. 

Did you mean e-cam.it ?
I found only 14-day trial and nothing about weekends.

We need to know who still uses the drivers that only work on RTAI kernels. They are all old ISA/PCI/parallel-port cards:

• Servo-to-Go (STG)
• Motenc
• Vigilant VTI
• Siemens EVOREG
• Axiom AX5214H
• Opto22 AC5
• pci_8255
• Advantech PCL720
• Pluto-P (pluto_servo / pluto_step)

If you run any of these cards with LinuxCNC on an RTAI kernel, please post here with the card name.Pluto-P is a special case: its drivers can likely be made to work on regular preempt-rt installs, so if you have one and are willing to test, please say so.Technical background: github.com/LinuxCNC/linuxcnc/issues/4505

Some computers are not suitable for LinuxCNC, not because they are too weak, but because they save energy without taking into account the costs.
If the processor heats up and is turned off for a few milliseconds, you will not be able to control any machine with it.
I like to experiment and although I don't recommend it to anyone, I installed properly working LinuxCNC (2.10 on Debian 13) on Wyse 3040 (Atom X5-Z8350 2 GB RAM and 8 GB "disk"). It lags a bit if you run several programs at the same time, but LinuxCNC with Mesa 7i92 works flawlessly.
For work I use AMD A10, both for Mesa and Ethernet. No problems.
I tried Ryzen 3 2200G and Ryzen 5 3400G, they work better, but they lost compared to AMD A10 in terms of dimensions, because they don't fit in a backpack, and that's what I care about.
So it's more of a lottery, a computer for LinuxCNC doesn't have to be very powerful or very expensive, it just has to fit.

Ok, so for the first test I will use a mesa card, since I don't want to mess with the original motor drives. However if we decide to use Linux CNC multiple machines may be converted, therefore the hassle implementing ethercat is valid. Am I right when looking for a PC that has a Intel nic and 8th gen i5? Is Linux CNC able to do collision detection of the machine gcode?

hey one idea for you that i have seen

Ecam.it which is another really good turning cam software in my opinion offers the software free for weekends.  

can you try a free trial without credit card or anything.  just so i can quickly try it?

cheers

Andrew

You did not give linuxcnc-ethercat version


github.com/linuxcnc-ethercat/ethercat/releases
github.com/linuxcnc-ethercat/linuxcnc-ethercat/releases

I made arm64 debs as well...

syncToRefClock="false" without a refClockSyncCycles means free mode, don't use with axis.

syncToRefClock is going away because it is confusing, use refClockSyncCycles=-1 if you want to test having the pi sync to the clock on the drives, in your case it does not seem to work, should be same as syncToRefClock="true" but test with latest version.

refClockSyncCycles="1" if your latency is decent is a good choice.

5 axis is certainly a bit off the beaten track. You might want to try on the linuxcnc discord server or on a forum that caters more to 5axis machining and CAM applications. I'm afraid I don't have any links for you though.

Here   you have a good example of the xml file for Beckhoff devices
Hi

quark wrote:

 If you know somebody who might be a fit or would be interested yourself, I would love to hear from you. 
 

Contact details?