Open Source Controller with internal THC

Whether or not velocity will slow when following a spline is dependent if the centripetal limits are violated for that given cut velocity.
Linuxcnc always knows the velocity the torch is travelling at and it also always knows the programmed feed rate (in v 2.9). Furthermore, there is a pending enhancement that publishes the arc radius github.com/LinuxCNC/linuxcnc/pull/900 . So it will soon be possible to compare the arc radius being traversed with the calculated centripetal limit. Granted these calculations are only currently restricted to arcs and splines are not considered but few post processors know how to use splines.

As I said, it is trivial to enable a pin that is true when velocity is constant. I have attached a component that will give you this pin if you wish to experiment with linuxcnc and your THC.
you may install this using the command halcompile --install constantvel.comp
Then you can add it to your hal file.
I've pasted the code for this component below.
I will be interested to hear your results from using Linuxcnc with your THC now you have the output you require. Note that the component probably should also reference motion.motion-type to ensure that the pin is not enabled when the system is idle.

Ha, interesting and commendable is that for you it is quite simple and you even have the desire not only to do it but also to publish it immediately, BRAVO !!!
But now it remains for us on the nasty task, our specialist, who is not as advanced as you, to be able to include it in our Linux system ...., which is currently a test. Unfortunately, we currently have to rely on CNC of the UCCNC, which is a complete mess in the plasma profile. In addition, it cannot be said that it can be relied on for support.
If we get somewhere I will share.
But since we have already noticed that LinuxCNC (as well as the UCCNC, by the way) is slowing down in places in SPLINE, do you have any observations where it should also be wrong now and the CV trajectory planner fails to maintain a CV. I mean test more possible errors.
And in the next moment is it possible to show the analog output the current speed linearly with PWM (this is probably too much right).

If you are wondering why this is important to me - it is important what the speed is not only for corners and small arcs and small holes, it is important even for large round shapes. Because the distance traveled by the burner and the speed measured in mm / min travel the contour and the distance traveled by the axes and the speed at which they travel is not the same. What do I mean if we cross a line on one of the axes - it travels the same distance as the length of the line. However, if we cross a diagonal, it depends on the figure but the distance traveled is more because the movement of both axes is added. However, if we take a circle then the distance is 27.38% greater than the length of the circuit. For this reason, since the speed of the burner is higher, the THC lifts it up and a bevel is obtained from above.

Spline or not, LinuxCNC will not slow down, ever, if the machine can handle the velocity and acceleration, so that makes me think you are testing on a not properly set machine.
Any way you look at it, you can always send one of those THC to me to have it tested for normal use and for miss use.
Please be aware that i do not do favours and do not write favourable reviews if there is anything wrong with it.
And i also do not do NDA's.
I have tested plenty of THC and other stuff, so far only Proma Elektronika and Mesa have passed every possible test and i had no interference form them ever. Even tested the proma by reversing power supply and input 300V form plasma, it survived. Tested Mesa THCAD300 on two high frequency/high voltage pilot start plasma and it works, although they implicitly state not to use them on such plasma sources.

BTW, Rod, what happened to that company that said they will send me one on another forum? I never heard from them !

Sorry someone has already tried here and now I just found it.We will experiment and share the result. linuxcnc.org/docs/devel/html/plasma/plasmac-user-guide.html

I understand maybe the mistake is in our settings. We will try harder and if we succeed I will share it.
Our THC is not yet on the market and is distributed only as a precaution for tests in a limited number and price. We can really send you one for a test.
I'll take your address and send you a test controller. We really don't need favourable reviews, but rather constructive criticism, if there are things that need correction.

www.tomberisha.com

stivemaster13 wrote: But since we have already noticed that LinuxCNC (as well as the UCCNC, by the way) is slowing down in places in SPLINE, do you have any observations where it should also be wrong now and the CV trajectory planner fails to maintain a CV. I mean test more possible errors.
And in the next moment is it possible to show the analog output the current speed linearly with PWM (this is probably too much right).

Thats the thing. Linuxcnc is all knowing so that a THC encoded inside Linuxcnc knows all the values you ask for and some!
The Pin motion.current-vel is the velocity at this very millisecond so you could use that to drive a PWM.

Unlike other systems like UCCNC, Linuxcnc does not have a constant velocity mode. Instead it uses G64 to set the tolerance required between the commanded path and the actual path followed. With no G64 tolerance set, Linuxcnc will round corners to maintain constant velocity based on centripetal limits that are determined by the machine's velocity and acceleration settings.

The reason why any motion controller slows down on splines and the like is that the laws of physics place constraints on how fast it is possible to negotiate that feature. If it is beyond what the physics says is possible, it has to slow down. there is no choice! THe faster your machine's acceleration, the less deviation will be required. Likewise the laws of physics also say that at high acceleration, your machine could well shake a apart from the applied inertial forces.