and another on 2mm plate. one of my early THC tests. you can see its been annotated with where the THC was enabled.
https://www.cnczone.com/forums/attac...d=397176&stc=1
Printable View
and another on 2mm plate. one of my early THC tests. you can see its been annotated with where the THC was enabled.
https://www.cnczone.com/forums/attac...d=397176&stc=1
tjb1
Just so things are clear the pierce delay has no relationship to the THC servo delay other than they both start with the arcok (or ok to move) from the plasma power supply going true. You really need both. Sorry I have no knowledge of how uccnc works. Rod's halscope captures show it all.
John
Servo delay is how long we are waiting after receiving arc ok before acting on up/down signals? Pierce delay is just how long after starting the arc that it waits before moving to cutting height correct? I'm having trouble reading the text on those pictures.
I have no clue how linuxcnc works, but I think what you refering as "THC servo delay" is the same what I'm refering as pierce delay.
When the THC is turned on then the THC control (up/down) is disabled for a specified amount of time.
Or if your THC servo delay is different then please explain what it is.
tjb1
Correct! Pierce delay is the time from arcok to when the torch starts to descend to cutting height. THC servo delay (or what ever you want to call it, I am trying to be generic here) is the time from arcok until the THC takes control of the z axis height based on the arc voltage.
Yes that is my biggest gripe with halscope plots is that there is no data only way to easily share plot, screen capture only.
John
OK then we were talking about the same thing just named things differently.
It looks like the forum downsamples the images. E:command is the voltage set point you want to achieve (95 volts in this example), curvolt is the actual torch voltage from THCAD. The time scale is 1 second per each horizontal line. The blue line at the bottom is the error between the setpoint and the actual volts at a higher scale. You can see the THC is enabled below the desired voltage and the PID unit initially overcorrects before oscillating to settle on a stable value on the set point.
The gap between the actual volts and the desired volts is the reason why I now sample the torch volts. Initially I just grabbed one reading when the THC servo delay expired but now I have rewritten it to calculate a moving average of 100 readings (eg. average over the last 0.1 second). The averaging commences once we get an ArcOK so that we know we will have a full buffer of 100 samples by the time the Servo Delay expires. I've just bench tested that its working this morning and I'm off to confirm its working. Its a bit tricky to calculate the average in an Interrupt Service Routine as you can't use loops but I've come up with an algorithm that does it with some pointers and a buffer for the readings. We add the current reading and subtract the oldest reading and return that sum divided by number in the buffer. Time will tell how large the buffer (eg the number of readings averaged) needs to be.
One more thought. I would also experiment with the 1/32 divider on the THCAD (Don't forget to adjust your calibration values). Its possible the slower sample time might help generate a more stable signal due to the THCAD's Sigma Delta ADC.
Right now it is checking the frequency every 10 milliseconds, you still think it would be better to divide it? I think the gate interval would need to be higher then because I have less digits in the frequency count and dropping a higher amount (I haven't figured out what volts I would be losing yet).
I did a bit of work on the code today, added a min and max volt variable and lowered the min from 100 to 25. Also removed all serial commands and code timing and cleaned up unused variables.
If you are simply frequency counting you should use the 1:1 (~1 MHz full scale) THCAD setting to get the best resolution
The reason you do not lose resolution at lower frequencies (say 1:32) with a Mesa/LinuxCNC setup is that the THCAD frequency
is read via an encoder input and Mesa encoder hardware +LinuxCNC driver does n/t(n) velocity estimation which calculates frequency by counting pulses
_and_ the time between the first and last pulse per interval (not just pulses per interval) so its frequency resolution is independent of actual frequency
I've looked at switching to FreqMeasure but even dividing at the max, its still too high to use due to the 1k max (THCAD output at F/128 = 935 low, 7238 high) - https://www.pjrc.com/teensy/td_libs_FreqMeasure.html
For what reason did you use that mesa thc card?
I mean you could sample the analog voltage with an A/D converter on the Teensy. Isn't there an analog port on it?
You just need some resistors to divide the voltage and some capacitors to smooth it out.
Then you could get rid of the THC card making the controller much cheaper and easier to get for others. (in case you want to make a product out of it.)