Why real time kernel is needed with board like MESA?

That's right you're right. Here are some details about the openings and methods of HYPERTHERM. There things were like that in the recent past - if you mathematically calculate how long the burner travels while cutting a hole and then if you cut a straight line from a contour you get a number. That is, in order for the cutting speed to be equal, it must be reduced in the holes to about 70%. This was what Hypertherm's controls were doing then. However, then they found (of course not only them - most innovations in this business actually have Kjellberg) that the cyclone of the plasma jet is not actually stationary but wanders when changing direction and therefore it is better in the holes cutting height should be more small, the velocity is about 65% of that of the contour and the plasma must stop shortly before reaching the kerf crossing. At Kjellberg at this point at the end of the hole (1/2 of the thickness of the kerf) the plasma decreases, does not stop. I can not say what curve reduces the amperes (I did not think to measure).
Kjellberg do the same in sharp turns - reduce amps in real time (up to 20%).
However, this is aerobatics and very much depends on the equipment and whether it is compatible. In no case does it apply to any equipment.
The plasma cutting machine can cut very well without controlling the power of the plasma in real time.
This for the second cutting height of the holes can also be done with the tool number !!!
I want to make one clarification - all the time as holes - I mean small holes or precise holes (bolt holes) such under 30mm.

This is interesting. Yes its unfortunate that there are not many plasma cutters that allow reaI time control of current. There was one mentioned recently with 0-10volt control. I think the Thermal Dynamics current control would be easy to intercept and replace with a digital potentiometer. I do know one user who has done this.

I do not think the amps will alter on a curve as plasma is a constant current circuit. With current control, it would be interesting when cutting a hole to disable the torch height control and switch to changing the current to keep voltage constant. In theory, the arc's power would remain constant so kerf should remain the same width at the lower speed. That sounds like what Kjellberg is doing.

With Linuxcnc, it would not be necessary to change tools, we could use an external offset to lower the cutting height in real time without gcode. Then the height adjustment could be dynamic and vary with conditions. How much do you lower the torch by?

I really would like to see a system where there was no gcode changes required at all but instead let the motion controller manage everything. This pull request to the linuxcnc core I wrote was the first step to allow this. github.com/LinuxCNC/linuxcnc/pull/900
This publishes the arc radius, and variables that say if its a hole or an arc and a direction heading which could be used to calculate X & Y offsets to adjust the torch position to account for the wider kerf at the lower cut velocity. It these kind of complex calculations that apply position and velocity overrides where Linuxcnc's real time control comes into its own...

I don't know if you understand - if we apply a technique that is used in one piece of equipment to another - it may not work!
That is, the burners are different and can create a stable cyclone of different lengths - according to what I worked with, I would first put this one - OTC - Daihen D12000 - this thing cuts with a 3% slope of 40 mm, then Duramax S105 - S125 - the same quality but up to 30 mm, followed by Trafimet S105 and PTM100 - slightly lower quality and again up to 30 mm.
So if the burner rotates the cyclone well, you may not need to change the height. If necessary, it can be changed by up to 10%, ie if it is 2.5 mm - to reduce it to 2.25 mm.

And about real time and holes I don't understand what you mean?In LinuxCNC it may be so, but in others even the most branded ones are not. For example, Okuma to Model 7000 does not give a code error message at the beginning, even if there is a move that cannot be executed. Just before this line stops and then writes an error.
In my opinion, the code analyzer should crawl the entire code to decide if it is possible to execute it, if there are errors, if it does not violate the soft limits, and so on. Then he will "see" the hole and will create such a task, which the planner will turn into simple small tasks to send to FPGA.
My opinion !!!

Thanks. So you rate the OTC Daihen as a high quality machine then? I had not heard of it in our market.
Yes, Linuxcnc by default will report errors before allowing it to run. Plasmac filters and modifies the gcode to apply hole cutting mode adjustments etc.

By working with G code you do not know everything that is happening for example you do not know the exact velocity right now, It may not be possible due to machine acceleration limits. By working in real time in Linuxcnc, we know everything instantly. So think of it as applying adjustments in your FGPA but that the linuxcnc "Super FGPA" knows a lot more about the job so can do a better job managing the cutting and apply adjustments that cannot be done in a FGPA that has imperfect information.

rodw wrote: So you rate the OTC Daihen as a high quality machine then? I had not heard of it in our market.

I own a 190A welder made by them in collaboration with another company, works nicely and uses an SSR to switch on and off, not a relay, so there is no clapping noise when pulling the trigger.

My OTC Daihen robotic welder is a high end machine and it better be for 17K,



I did not know they made plasma cutters, I will look into it.