Muzzer wrote:

Muzzer post=349428 userid=18852

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:

Hi.

1) Until we release a new version of the software, you get unlimited updates. If and when a new version is released, the previous one is locked for life with no further updates. We expect that the product would have reached full maturity by then. We expect to release a new version every 24 - 36 months
2) We expect to have an update a month during the first 3 - 4 months and slow down after, these are more for features rather than bugs or refinements in UI. We dont claim to be bug free but we have tested thoroughly already. We are also working on a couple of additional machining strategies like radial thread on a rotary setup - all will be free updates.

Whatever you do, Fusion will cost you 1500 per year for a basic 4th axis. Takshak wont.

We have a community space for feature requests / posts submissions / bug reports etc..
We have videos on our Youtube Channel showing both 3 axis and rotary Feature recognition. It does not cost you anything extra. comes standard.





 

Cheers, I appreciate the reply

This is the internet your not gonna hurt anyone’s feelings but that about the pi is what I half thought.

only issue with the parallel port is I wont have enough I/O.
Back of the napkin mathematics says 14 output 10 input but could be 6

Spindle PWM Dir Enable / Feedback (optional)
Step / dir XYZ 6 / 2 end stops each for some reason 6 (3)
Tool change step dir 2 / end stop / sensor to count tools for some reason
DC drawbar 1 /compressed air 1 / 1 for sensor

but could still get it working limited the re do the extras later.

just wondering if their was a better option

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:

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.