First off, let me say routerguys (and motorguys) should read no further.
Now I'm not an electronics engineer or anything, but from what I'm seeing, there are 2 advantages from using voltage to frequency conversion.
1. The calibration data on my THCAD says I've got 802,800 steps from 0 volts to 10 volts internally eg. 0 volts = 122.9 Khz, 10v = 925.7kHz
2. Presenting a frequency to LinuxCNC is a very convenient way to introduce a voltage to LinuxCNC as it can simply be hooked up to the (spindle) encoder input where raw numbers can be read in software.
So from my perspective, I'm not the least bit concerned with 10 bit, 12 bit or 16 bit resolution so I tend to side with beefy here. I just want results! Linux obligingly gives me this frequency in a float which can count to 3.4 x 10^38 which is infetestimatley larger than the paltry maximum value of 802,800 I need (by about 32 zeros).
So I guess the next thing to address is the questions about PID. From a LinuxCNC perspective, it does PID for motion control standing on its ear. Thats its strength. You can throw any servo motor at it and it will control it accurately using PID based parameters. This implies that the integrator has to know how to tune the PID loop (now thats something that makes my eyes glaze over). It also implies that LinuxCNC does this at 1 kHz frequency. Thats the standard timing for the servo thread which is integral to LinuxCNC's HAL (Hardware Abstraction Layer) SO thats where the 1000 times per second comes from. People have said that you can't possibly control an axis movement at that speed. Well you can and thats what I think might set LInuxCNC apart from an architecture point of view. eg. If the adjustment velocity is not right 1 millisecond ago, you can speed it up or slow it down right now.
So then in response to the question about what are you controlling? Well thats simple. We are controlling torch height (the distance from the torch tip to the material). PID does not care what input it receives. It can be the number of bananas in the Congo at this point in in time IF that is closely correlated to torch height. So in our case, we have chosen torch voltage because there is a close correlation between that and torch height over the narrow range we are interested in.
Does LinuxCNC use PID, PI or the number of bananas in the Congo? Well. we use PID. Now for Torch height control for various mathematical reasons that make my eyes glaze over, "I" is not useful to us becasue it is controlled by an outer loop. PID has two inputs in our case. The command (being what we want the torch voltage to be (at our desired height). I call this the setpoint). Of course the other one is the feedback signal which in our case is not the number of bananas in the Congo but measured torch arc voltage.
How are you employing Hysteresis? Some people call this the dead band. ie if the torch voltage falls in this range then do nothing. These parameters exist in LinuxCNC's generic PID component but the developers are so supremely confident of the PID control embedded into the THC component I am using, it does not exist at all. So the PID algorithm has complete and utter control of the Z axis.
What PID algorithm are you using? Well whatever the developers saw fit to implement. They did include an optional experimental pid derivative gain calculation based on:
"Control System Design", Karl Johan Astrom, 2002 Eqn 6.2: limit high frequency gain of derivative term Eqn 6.17: derivative estimation using backward difference. Now my eyes glazed over again just reading the reference title! Now with no disrespect to Karl, I found that this is not as good in our application as the default PID control.
When time is held constant (which is the case when using a CPU timer interrupt such as the LinuxCNC servo thread), the standard PID algorithm reduces to less than 20 lines of C code. I found this pretty amazing given the amount of mystique around PID control. Google it if you don't believe me.
How does LinuxCNC do it now? Well, the new experimental development branch I'm using which is not yet incorporated into the LInuxCNC core allows external offsets on an axis. That means external to the trajectory planner. It's not just been implemented for torch voltage control and I'm assured it has many other eye glazing over uses.
In our case, my take on it is something like this. The torch is blindly cutting away at say 2.0mm off the plate when it meets an aberration on the material surface. Say it finds a warped plate which means all of a sudden it is 1.8 mm away rather than 2.0mm. the Torch height control component applies an offset of 0.2mm to the commanded Z position so the next time the trajectory planner looks, it sees that the torch is off course and adjusts the torch height so its back on the commanded height (of 2.0mm) without even knowing the external offset is applied.
Time will tell if this will actually work but after I received some suggested revisions for my metric based machine yesterday, and a few tests, I am super confident my machine will be cutting +- 0.5mm or better as soon as its missing ArcOK is restored. I may have have to engage the Pom to make me a new Arc OK signal
). Whilst I understand your perspective from a commercial aspect I have no such aspirations, and this is firmly a hobby of which I have just an interest in, and little time for extensive r&d (I already have THC), but can still be interested in "if there is a better way" / attempting to understand how it works, or one may think it works or ought to work.
