THCAD Noise / THC comp movement
- Rick G
-
- Offline
- Junior Member
-
- Posts: 26
- Thank you received: 155
I was focusing only on seeing that variation was "similar" on power source ON (0V) and cutting, but it seems different. I'm thinking that maybe, too fast movement on THC component is creating some kind of overshoot to Z axis and this is what creates Voltage variations...
It has been pointed out that too large a setting will cause the z axis to oscillate up and down or bounce.
Perhaps try with a much reduced correction setting to see if that stabilizes things .
You could also experiment with different thread speeds.
The THC comp also has a voltage tolerance setting, where is yours set?
It seems to me that if too large a correction is made the next voltage reading will be taken before the move is complete causing another correction to be made and so on till it overshoots and then start back down.
Perhaps a delay between corrections and completion of movement ...
Rick G
Please Log in or Create an account to join the conversation.
- azeri
- Offline
- New Member
-
- Posts: 11
- Thank you received: 1
THC voltage tolerance is set at 1V, if i lower the THC correction, the bounce dissapears, but Z movement for correction go too slow for high slopes, where i want the system to be able to cut.
I've always used THC on servo thread, any other recommendation ?
Best Regards,
Aitor.
Please Log in or Create an account to join the conversation.
- tommylight
-
- Away
- Moderator
-
- Posts: 19782
- Thank you received: 6686
forum.linuxcnc.org/49-basic-configuratio...-get-mesa-thc-values
Thc correction velocity
That has to be tested at different values till you find something that works quick enough but does not cause bunny jumping of the torch
Please Log in or Create an account to join the conversation.
- azeri
- Offline
- New Member
-
- Posts: 11
- Thank you received: 1
thanks for the link, but its thc.correction-vel 0.0001. I have now 0.01 and need at least 0.08 for what i'm looking for. Probably i would look for some THC Comp change/adaptation to try to get this overshoot off, or at least reduce it.
I know that if i put lower THC correction, problem dissapears, but it makes THC slower, and i need it faster than it's now.
If someone has some idea on how to evade the overshoot, or how to work on it, i'm open to it.
Best Regards,
Azeri.
Please Log in or Create an account to join the conversation.
- Rick G
-
- Offline
- Junior Member
-
- Posts: 26
- Thank you received: 155
The THC comp runs on the servo thread, and if that is set to 1,000,000 then that would be 1,000 cycles per second.
If the THC correction is set to .0001 and we are working in inches then each cycle correction is .0001".
That would mean 1,000 * .0001 = .1" per second (IPS) so 6 Inch Per Minute (IPM).
If all that is right then a THC correction of .01 would be 1,000 * .01 = 10 IPS or 600 IPM
A THC correction of .08 would be 4,800 IPM?
From the THC comp...
if(torch_on && arc_ok && vel_status){ // allow correction
if((volts + voltage_tol) > volts_requested){
offset -= correction_vel;
}
if((volts - voltage_tol) < volts_requested){
offset += correction_vel;
}
last_z_in = 0;
}
Perhaps modify the code to only apply a correction after so many cycles to give the z a chance to get into position.
So request a Z correction, wait 10 cycles before next correction can be made.
Rick G
Please Log in or Create an account to join the conversation.
- rodw
-
- Away
- Platinum Member
-
- Posts: 11045
- Thank you received: 3670
Eventually, software has to hit the mechanical world. I wonder if the OP has considered what he's trying to achieve. From the original post, he wants to move the Z axis 80mm per second or about 60% of the table velocity at his quoted maximum speed of 8250 mm/sec. Cutting Corrugated iron in our country requires the Z axis to travel 36mm per 76mm which means the Z axis must move 47% of the table direction so his criteria is not that unreasonable
But hang on a a moment. My build uses a 5mm/rev ball screw for the Z and a Rack and pinion for X & Y that travel 31.3 mm/rev. So at the same RPM, my Z only achieves 16% of the speed the X & Y can. So the logical question to ask. Is this machine capable of running the Z at 60% of maximum speed anyway? If not, the whole software config is an exercise in futility..... Perhaps the OP can quote some RPM's required to move at his desired speed.
Finally, I'd love to know where to find the source code that Rick was quoting from. I've always wondered how fast the Mesa Card can handle adjustments. This is the first time I've seen a thread discussing THCAD performance and I want to know more and do know my way around C..
Please Log in or Create an account to join the conversation.
- Rick G
-
- Offline
- Junior Member
-
- Posts: 26
- Thank you received: 155
Please Log in or Create an account to join the conversation.
- andypugh
-
- Offline
- Moderator
-
- Posts: 23216
- Thank you received: 4889
From the THC comp...
if(torch_on && arc_ok && vel_status){ // allow correction if((volts + voltage_tol) > volts_requested){ offset -= correction_vel; } if((volts - voltage_tol) < volts_requested){ offset += correction_vel; } last_z_in = 0; }
So, thc.comp uses a simple "bang-bang" controller. It might be that this system needs to use something a little more sophisticated, such as a PID controller.
It would be possible to modify the comp to use a PID controller, and that might be worth considering, but slightly simpler is probably to change the comp to make correction-vel into a pin rather than a parameter and connect that to the output of a HAL PID component.
Please Log in or Create an account to join the conversation.
- rodw
-
- Away
- Platinum Member
-
- Posts: 11045
- Thank you received: 3670
So, thc.comp uses a simple "bang-bang" controller. It might be that this system needs to use something a little more sophisticated, such as a PID controller.
It would be possible to modify the comp to use a PID controller, and that might be worth considering, but slightly simpler is probably to change the comp to make correction-vel into a pin rather than a parameter and connect that to the output of a HAL PID component.
Andy, thanks for the input. I did think the adjustment approach was a bit crude and wondered why it did not have some form of PID control.
I also noticed the hardcoded adjustment to requested_vel in the line immediately preceding the ones Rick quoted:
float min_velocity = requested_vel -(requested_vel*(velocity_tol*0.01));
Boy have I got some reading to do!
Please Log in or Create an account to join the conversation.
- Rick G
-
- Offline
- Junior Member
-
- Posts: 26
- Thank you received: 155
float min_velocity = requested_vel -(requested_vel*(velocity_tol*0.01));
The voltage / height relationship of the cut changes with speed and at too slow a speed the height of cut may be adjusted incorrectly by any THC if not turned off.
For example a requested cut speed of 200 with a tolerance of 20%
min_velocity = 200 - (200 * (20 * 0.01))
min_velocity = 200 - (200 * .2)
min_velocity = 200 - 40
min_velocity = 160
On my machine I have edited that line slightly to suit my panel.
I would like to point out that the THC and Mesa combination has worked great on my table since I installed it a couple years ago. It does exactly what it is supposed to do. I cut from thin gauge to 1/2" steel.
The author of this topic application is a bit different (corrugated steel).
A pid modification has been suggested in the past, but to the best of my knowledge no one has ever finished / posted one.
Rick G
Please Log in or Create an account to join the conversation.