Rules for THC On and THC Off

Having problems with or questions about SheetCam? Post them here.
rodw
Posts: 39
Joined: Fri Feb 15, 2019 3:35 am

Re: Rules for THC On and THC Off

Post by rodw »

It was not so much the ohmic sensing that took time but to implement it required replacement of the drag chain to make room for a larger torch lead and the ohmic wire. We use 3 optoisolated relays with 24 volts on an isolated power supply. and some 1000 volt diodes. 2 relays and diodes are used to isolate both legs (to torch and table) until such time as we actually want to probe and the second switch field power to an ohmic sense input.

Anyway you spurred me on and I revisited method 2 and solved the maths last night but have not experimented to see if the calculations will result in a workable solution. I will mention you could follow the same approach in the Sheetcam onArc() method where a bit more is known about the trajectory so it would be easier.

Yes, one solution suggested was to create a filter on the gcode files that ran as they were opened and modify the code in python. This was not something I wanted to do because with sheetcam in the mix it is more efficient to control this in the generated code where the post processor provides you with hooks where you can modify the code as you've described. With LinuxCNC we use M64/M65 which will toggle a pin on and off to enable/disable the THC instantly. Making decisions about cutting speeds will never be perfect from gcode as the laws of physics will prevent attainment of desired cutting speed on short segments at the trajectory planner when the code is parsed. Also, the code is parsed in a read ahead buffer so the interpretation may be a long way ahead of the actual motion so its not possible to physically map the two in real time.

I really would encourage you to get to know the sheetcam post environment. A lot of what you want to do can be done there.
stivemaster
Posts: 35
Joined: Sat Apr 13, 2019 6:46 am

Re: Rules for THC On and THC Off

Post by stivemaster »

I have the feeling that you did not understand what I mean! Analyzing the contour that can be done by python software does not just recognize the parts of the contour, you know? It creates new parts that are running at different speeds. These new parts of the loop will be executed in a stream at a constant speed. So can be predicted how they will be executed by the CNC controller. I think there is no point in discussing, the controllers that can not run in motion and see ahead in the code. They do not work right anyway, right?

For the ohmic contact - the separate adapter is very important. So there is no need to protect the relay from the voltage of the plasma because its ground is different and the current does not flow!
rodw
Posts: 39
Joined: Fri Feb 15, 2019 3:35 am

Re: Rules for THC On and THC Off

Post by rodw »

It might sound nice but it certainly can't be done in LinuxCNC becasue LinuxCNC IS_THE_MOTION_CONTROLLER.
In Mach and other systems the motion controller is external to the PC. Eg an ESS smooth stepper board.
LinuxCNC has massively more resources at its disposal than these external boards (via a 64 bit CPU) but it has to run on a real time version of LinuxCNC.

The core of Linuxcnc is executed on the servo thread which is guaranteed to run exactly on time without fail by the Linux real time kernel. Usually this is running at 1 kHz but can be faster if the situation demands it (and your hardware is good enough)
Because Linuxcnc is the motion controller, as system integrators, we have full access to the servo thread. That is not possible with external motion controllers that only exist because Windows is not a real time operating system.

Python is an interepreted language and can't execute in Real time. It runs in LinuxCNC's user space where timing is not enforced. its not possible to predict whats going on in real time via the Python Interpreter.
Gcode is an interpreted environment
Motion is a real time environment

Gcode is parsed and tokenised in a buffered environment in accordance with the RS274ngc standard. Then the gcode thrown away as it serves no further purpose. Then the motion controller determines if the commands can be executed having regard for the laws of physics and the machine's velocity and acceleration limits. eg on short segments, honoring the commanded feedrate may not be possible. To say you can predict the motion from an interpreted language is simply not possible as you don't have a motion controller at your disposal and you are not operating in real time.

There is a reason why Tormach and CandCNC have migrated away from a Mach environment in favour of customised versions of LinuxCNC. It simply superior in all respects. I can assure you it works right!
User avatar
Les Newell
Site Admin
Posts: 3661
Joined: Thu May 11, 2006 8:12 pm

Re: Rules for THC On and THC Off

Post by Les Newell »

rodw wrote: Thu May 02, 2019 9:13 pm Anyway you spurred me on and I revisited method 2 and solved the maths last night but have not experimented to see if the calculations will result in a workable solution. I will mention you could follow the same approach in the Sheetcam onArc() method where a bit more is known about the trajectory so it would be easier.
Could you explain in a bit more detail what your arc method entails.

I had a thought earlier - would it be enough to turn off THC if the machine's acceleration exceeds a given value? It would be pretty easy to write a LinuxCNC hal module to work out the current acceleration and trigger an output when the acceleration exceeds a given threshold. This would trigger when cutting sharp arcs and when approaching corners.
rodw
Posts: 39
Joined: Fri Feb 15, 2019 3:35 am

Re: Rules for THC On and THC Off

Post by rodw »

Les Newell wrote: Fri May 03, 2019 10:21 am
I had a thought earlier - would it be enough to turn off THC if the machine's acceleration exceeds a given value? It would be pretty easy to write a LinuxCNC hal module to work out the current acceleration and trigger an output when the acceleration exceeds a given threshold. This would trigger when cutting sharp arcs and when approaching corners.
Les, yes, doing a corner lock in a linuxcnc component is is pretty trivial code . Here is how I did it. But there is one gotcha here

Code: Select all

author "Rod Webster";

pin in  float current_vel                "Current Velocity (motion.current-vel)";
pin in  float override                   "Current Override (halui.feed-override.value)";
pin in  float cut_vel                    "Desired Cutting Velocity Units/min)";
pin in  bit enable = 0                   "Set TRUE to enable corner lock";
pin in  bit override_is_pct = 0          "Set TRUE if override value is a pecentage, FALSE if it is a fraction";
pin in  float threshold                  "Percentage of Cut velocity that triggers corner lock hold (1-100 percent)";
pin out float min_vel                    "Calculated minimum Velocity (from cut-velocity)";
pin out bit is_active                    "True if Corner lock is enabled and holding";
pin out bit override_is_active           "Convenience, TRUE if feed override is set";


function _;
license "GPL";
;;

#include <rtapi_math.h>

FUNCTION(_) {
  double override_val = 0;
  if(override < 1.0 || override > 1.0)
    override_is_active = 1;
  else
    override_is_active = 0;
  if(enable){
    if(override_is_pct)
      override_val = override / 100.0;
    else
      override_val = override;
    min_vel = ((cut_vel*override_val)/60.0)* (threshold/100.0);
    if (current_vel <= min_vel && current_vel != 0)
      is_active = 1;
    else
      is_active = 0;
  }
  else{
    min_vel = 0.0;
    is_active = 0;
  }
}
The gotcha is that there is no way to get the commanded velocity which is set by the F code. The motion.requested-vel pin is set by the trajectory planner for that particular segment. This can be significantly lower than the F command if the trajectory planner is unable to honour the users requested velocity. Gcode can send a number back to Linuxcnc HAL using M67/M68 so you either need to call that on every F command in POST or a better way is to REMAP the F command using the standard LinuxCNC python remap method (there are included sim examples to show how this is done). There is a branch called state tags which if adopted will create a new tag structure so data like this can be retrieved in HAL.

So my arc idea was to monitored the motion.motion-type pin which tells us if we are cutting an arc. I surmised it might therefore be possible to do some maths to calculate the radius of the arc in real time. Andy proposed a method based on circular velocity. This was able to accurately determine the current velocity but I had no luck getting consistent results for the radius. As you can appreciate, its hard to debug things in a component on a 1kHz servo thread!

Then an alternative method was proposed just using basic trig solving for the radius of a circle passing through 3 points. My first attempt at this failed because I could not find or solve one formula. I found what I was missing. It sounds like a better method but my time is limited right now so I have not revisited this.

I have to say many components of an advanced THC can be written in small components such as what I've shown. Sampling torch voltage is just as trivial but you need to hold off until the machine is near the F code velocity for the reasons discussed above.
User avatar
Les Newell
Site Admin
Posts: 3661
Joined: Thu May 11, 2006 8:12 pm

Re: Rules for THC On and THC Off

Post by Les Newell »

That's why I suggested monitoring the acceleration rather than the velocity.

The basic code would go something like this

Code: Select all

pin in  float current_vel                "Current Velocity (motion.current-vel)";
pin out bit is_active                    "True if Corner lock is enabled and holding";
pin in  float threshold                    "Acceleration threshold";

variable float lastVel = 0

FUNCTION(_) {
double accel = current_vel - lastVel;
lastVel = current_vel;
is_active = fabs(accel) > threshold;
}
The above is completely untested and just to give you an idea of what I mean. Ideally you want to scale the calculated acceleration by the actual period to allow for timing jitter.
rodw
Posts: 39
Joined: Fri Feb 15, 2019 3:35 am

Re: Rules for THC On and THC Off

Post by rodw »

Initially, I thought your idea could work becasue if at the commanded feed rate acceleration will be 0. But on a short segment at say 80% of the F command, I think it might see the change in acceleration and trigger spuriously. Thats why we started to use remap becasue when we just worked on motion.current-vel, there would be divots in the cut because the machine thought it was at cut height but the voltage was way too low so it would correct height violently when it shouldn't.

Don't get me started about pauses by the motion planner with changes in direction but that ones been fixed.
User avatar
Les Newell
Site Admin
Posts: 3661
Joined: Thu May 11, 2006 8:12 pm

Re: Rules for THC On and THC Off

Post by Les Newell »

You could put in a timer to ignore very short accelerations. If it only decelerates for a short time the speed won't have changed much.
stivemaster
Posts: 35
Joined: Sat Apr 13, 2019 6:46 am

Re: Rules for THC On and THC Off

Post by stivemaster »

I think I will refuse to offer because it is not clear what the benefits of what I offer.
That's why I will ask again - if the software succeeds in dividing the contours and the islands and the holes in this way, What is the problem with the CNC controller to execute the movement and the red plots stop the THC?
Attachments
THC.pdf
(6.82 KiB) Downloaded 166 times
rodw
Posts: 39
Joined: Fri Feb 15, 2019 3:35 am

Re: Rules for THC On and THC Off

Post by rodw »

stivemaster wrote: Fri May 03, 2019 6:02 pm That's why I will ask again - if the software succeeds in dividing the contours and the islands and the holes in this way, What is the problem with the CNC controller to execute the movement and the red plots stop the THC?
Well for the most part the corner lock/velocity antidive code I posted together with a THC on delay will solve your problems without need for any other complexity.

After extensive data collection using Linuxcnc's software oscilloscope (halscope), I have found that a THC on delay of about 1.5 seconds after arcOK seems about right for the initial establishing spike in voltage to subside. This is 8mm mild steel at 80 amps. E:feedback is arc voltage and E:arc-ok is the arcOK signal and we sample the arc voltage when the THC is enabled. If the current velocity is not near commanded velocity, we wait until it is before enabling THC and sampling.
arc plot.png
arc plot.png (96.48 KiB) Viewed 4822 times
You can see the THC is enabled at the point where the blue error line starts to be plotted (1.5 seconds after arcOK goes true). This period could be shortened a bit in this instance but 16mm thick material is a bit slower settling.

Lets look at your simple square. The leadin will mostly occur within the ArcOK delay and there will be a ramp up from 0 to your cut speed based on the trajectory planner logic. After 1.5 seconds, the THC is enabled and the arc voltage is sampled. Torch height is now under THC control. As the cut approaches the corner, the trajectory planner will reduce velocity in preparation for the change of direction. Once the velocity falls below the threshold (say 90% of commanded velocity after allowing for feed overrides), the THC will be disabled. The corner is negotiated and the trajectory planner accelerates back to commanded velocity. Once it gets over our 90% threshold, THC will be enabled again. As the cut is completed the TP will slow the cut speed and the THC will be disabled at the end of the cut

Looking to the inside cut rectangles, the same rules would apply. THC would most likely be enabled becasue some of your long side cuts would be at speed. There is no reason to slow them down.

Circles are mostly self managed by the same logic becasue the trajectory planner is unable to get to cut speed so the THC is never enabled. You can augment this with Sheetcam's automated cut rules and tie the cut velocity to a percentage of circle diameter based on different sizes. This is quite useful and would solve your problems on the bottom right. Maybe the large hole is cut at 80% of cut speed and the smaller ones cut at 60% with those rules.

The problem I had was with arcs on chain cut holes in 16mm plate. Lets look at the example on the top right again as the corner arcs are similar to what I had. You have 3 arcs on the outside corners, transition in, circular cut and transition out. I would be quite happy with the cornerlock managing the transitions. But I found I could not set up a rule in sheetcam that ignored small arcs and modified the circular cut. This is what led me to explore the possibilities of calculating the arc radius in real time (eg 1000 times a second). This would allow me to build much more sophisticated rules to modify cut speed and THC enabling than sheetcam provides. Time will tell if I can achieve this.
stivemaster
Posts: 35
Joined: Sat Apr 13, 2019 6:46 am

Re: Rules for THC On and THC Off

Post by stivemaster »

Bravo rodw, you obviously do a good job with Linux. I used to have expert help before, but I came to your conclusions and even ahead. That is exactly why I make my suggestions!
I tried 1000/3000 / 6000mm / min and looked at the machine's distance to speed up or slow down. The results were such that if you add distances - 8/10/15 mm THC will work correctly.
I already talked to a Python programmer, and he thinks it's no problem adding lead in and lead out to contours, islands in them and holes. Maybe automatically, by clicking on the contour. You can add items as part of the lines and to connect with logic. That means I can handle myself without Sheetcam.
But I want to try Sheetcam because it has many features, it is known to many people and it is already prestigious.
And what needs to be done is not so complicated:
After determining the distance that is needed on the acceleration machine, this distance is set to a variable. We assume it is 10mm.
Then Sheetcam after setting the cutting direction and lead in, places this distance 10mm automatically after lead in. Then it is assumed that the machine has already accelerated and the THC is allowed. Then, on any change in the direction of the line including the arc with R <10mm before the point of change of direction is placed these 10mm, and after it too.
If a loop, for example a hole, is made up of elements with R <10mm, then the whole THC Off.
I think it's simple, what do you say?
Post Reply