Tommy, thanks for your input as always.
Robert, I was thinking of one of these when I referred to high end machines
www.hypertherm.com/hypertherm/hyperforma...erformance-hpr130xd/
I know for a fact that many of these machines are deployed by plasma table manufacturers without using the Hypertherm controller but none of them will be using Mach3 or LinuxCNC. Here is a local manufacturer I've visited that has installations in shipyards all around the world:
www.advancedrobotic.com/
But you can see, these machines are not entry level CNC machines. Windows based controller of their own design.
I can't see why Linuxcnc can't do as good a job as these machines. After all, Islander261 is already on record as saying his Linuxcnc table is performing better than his previous commercial software.
I agree with you that at some stage, I need to make this table work. But the fact of the matter is that one of the LinuxCNC developers put a lot of time and effort into a software module which should do plasma THC very well while I was working on my table. So I decided to adopt this experiment. The developer Dewey then spent a lot of time and effort educating me about how to use it. My feedback then went back into improving his algorithm. So far I have not got it working but I feel I have an obligation to persevere until I have no more options to explore. I have not had a lot of time to devote to this and have been thwarted by my lack of understanding of the environment and a few hardware issues which have disillusioned me from time to time.
As Tommy (and others) have pointed out, there are other methods to do plasma with Linuxcnc but they have missing features. There are a few of us who are working on developing a fully complete THC internal to Linuxcnc. Each of us have our own views but we do collaborate. We think that that internal approach will exceed the performance of any external CNC. A couple now have good success.
I've also allowed myself to get distracted by writing a number of components to support basic THC functionality. Torch voltage sampling and corner lock are the two most important ones to help me manage the testing I've done.
So when I exhaust the external offsets branch (and there is only one more thing I can think of to test), I would have a working system in a couple of days either by borrowing another working experimental config or by going a more conventional known good route.
However, in the meantime, I have gathered a lot of data to help understand the torch voltage behaviour which I hope will eventually pay off..
So the limitation for my THC is really the limitations of the experimental external offsets branch and its included PID component and my own lack of knowledge. Those that have reported success have used the Linuxcnc PID component which is more sophisticated than the one I am using, The other constraints could be the external offsets method of applying adjustment using a count as is done with a MPG jog wheel.
As far as logging data goes, screen dumps from Linuxcnc's included halscope tell most of the picture to those who understand the Linuxncnc environment and the signals that are shown. Its still not as good as being able to evaluate a live capture in halscope itself. All of the items with the exception of amperage and material can be logged in halscope. It is possible to pixel count to establish a scale for the screen dumps.
Finally, with what I know now, I don't think a whole series of cuts are required to calibrate for a new material. From what I've learnt, I think I could do that with a single 6" long cut while Linuxcnc logged key data at 1000 times a second for subsequent analysis.
I hope I have answered most of your questions.