Early arc shut off

[cnc_freak]

Hello.
In a plasma cutting xy table, the plasma arc is controlled by M3/M5 on, off.
Sometimes its necessary to turn off the arc some ms before the actual part ,(contour), ends.
Is there a way, that KmotionCNC , for example 300ms before executing M5 ,to enable an output bit?
The post processor, normaly issues the M5 after the completion of the part, so it is to late to handle this on the M5 function.
Also the post proccesor, has the capability to make something in a given distance before the condure ends, for example 5mm before, but this is not good beacause it is dependand from the cutting speed.
Any help appreciatted.

[TomKerekes]

Hi cnc_freak,

I can't think of a simple solution to predict the future Here are some ideas:

#1

Also the post proccesor, has the capability to make something in a given distance before the condure ends, for example 5mm before, but this is not good beacause it is dependand from the cutting speed.

Doesn't the CAD/CAM know the current feedrate and could use that to adjust the Distance?


#2 - maybe KFLOP monitoring speed and when a deceleration occurs it could calculate the time to be fully stopped and when this becomes less than 300ms turn off the laser? The deceleration time from the slowest feedrate would need to be more than 300ms. Slowdowns around corners might be an issue.


#3 KFLOP knows the amount of motion downloaded to its buffer and how much motion time has been executed. The difference would be the amount of time remaining. Normally the buffer contains approximately the buffer lookahead time specified in the Trajectory Planner. ie 3 seconds. Whenever the buffer is flushed the time remaining will count down to zero. When 0.3 seconds remains you could turn off the Laser. Here is an example of how to display the time remaining:

Code: Select all

#include "KMotionDef.h"

main()
{
	double T0=0;
	for (;;)  // loop forever
	{
		double TimeRemaining = CS0_TimeDownloaded - CS0_TimeExecuted - CS0_t;
		
		if (TimeRemaining > 0.0) // Print only with time remaining
			printf("%12.6f Time Remaining = %f\n",Time_sec() - T0, TimeRemaining);
		else
			T0 = Time_sec(); // Time stamp last time we weren't executing motion
		
		Delay_sec(0.1);  // print only so often to avoid flooding the Console Screen
	}
}

And what was printed on the console (last portion of a ~13 sec Motion). First column is Job time. Lookahead time was set for 3 sec (minimum). Note time remaining fluctuates between 3~6 seconds then ramps to zero.

Code: Select all

    6.344197 Time Remaining = 3.337733
    6.444907 Time Remaining = 3.237023
    6.545618 Time Remaining = 3.136313
    6.646327 Time Remaining = 3.035603
    6.747037 Time Remaining = 2.946223
    6.847747 Time Remaining = 6.060432
    6.948458 Time Remaining = 5.959722
    7.049167 Time Remaining = 5.859012
    7.149877 Time Remaining = 5.758302
    7.250587 Time Remaining = 5.657592
    7.351298 Time Remaining = 5.556882
    7.452007 Time Remaining = 5.456172
    7.552717 Time Remaining = 5.355462
    7.653427 Time Remaining = 5.254752
    7.754138 Time Remaining = 5.154042
    7.854847 Time Remaining = 5.053332
    7.955557 Time Remaining = 4.952622
    8.056267 Time Remaining = 4.851912
    8.156978 Time Remaining = 4.751202
    8.257687 Time Remaining = 4.650492
    8.358397 Time Remaining = 4.549782
    8.459107 Time Remaining = 4.449072
    8.559818 Time Remaining = 4.348362
    8.660527 Time Remaining = 4.247652
    8.761237 Time Remaining = 4.146942
    8.861947 Time Remaining = 4.046232
    8.962658 Time Remaining = 3.945522
    9.063367 Time Remaining = 3.844812
    9.164077 Time Remaining = 3.744102
    9.264787 Time Remaining = 3.643392
    9.365498 Time Remaining = 3.542682
    9.466207 Time Remaining = 3.441972
    9.566917 Time Remaining = 3.341262
    9.667627 Time Remaining = 3.240552
    9.768337 Time Remaining = 3.139842
    9.869047 Time Remaining = 3.039132
    9.969757 Time Remaining = 2.938422
   10.070467 Time Remaining = 2.837712
   10.171177 Time Remaining = 2.737002
   10.271887 Time Remaining = 2.636292
   10.372597 Time Remaining = 2.535582
   10.473307 Time Remaining = 2.434872
   10.574018 Time Remaining = 2.334162
   10.674727 Time Remaining = 2.233452
   10.775437 Time Remaining = 2.132742
   10.876147 Time Remaining = 2.032032
   10.976858 Time Remaining = 1.931322
   11.077567 Time Remaining = 1.830612
   11.178277 Time Remaining = 1.729902
   11.278987 Time Remaining = 1.629192
   11.379698 Time Remaining = 1.528482
   11.480407 Time Remaining = 1.427772
   11.581117 Time Remaining = 1.327062
   11.681827 Time Remaining = 1.226352
   11.782538 Time Remaining = 1.125642
   11.883247 Time Remaining = 1.024932
   11.983957 Time Remaining = 0.924222
   12.084667 Time Remaining = 0.823512
   12.185378 Time Remaining = 0.722802
   12.286087 Time Remaining = 0.622092
   12.386797 Time Remaining = 0.521382
   12.487507 Time Remaining = 0.420672
   12.588217 Time Remaining = 0.319962
   12.688927 Time Remaining = 0.219252
   12.789637 Time Remaining = 0.118542
   12.890347 Time Remaining = 0.017832
Jogging Spindle Stop

#4 - A trick I have used in the past is to insert a digital time delay into the XYZ motion. If the XYZ motion is delayed by some amount, but the Laser Commands are not, then the Laser Commands will occur ahead of time relative to the motion. This is somewhat complicated. It requires a circular buffer to delay the motion. Trajectory Points are created every 90us. So a delay of 300ms would require a buffer length of 300ms/90us = 3333 samples. Several additional KFLOP Axes are required. For each axes that needs to be delayed, there needs to be a real axis to control the motor and a dummy axis that creates the un-delayed trajectory. A User Callback function executes every 90us to sample the Dummy Axes trajectory, delay it, and feed it into the motor axes destinations. Attached is such an example.


Do any of these methods seem appealing to you?

[cnc_freak]

#1. Yes the CAD/CAM knows the feedrate, but the user sometime change the actual cutting feedrate, by the time he cuts.

#2. Yes the corners would cause a problem.

#3. What happens when we have to cut a part with many holes, for example. We need at every end of the hole, 300ms before the M5 comes, to stop the plasma arc. The motion will continue to the next hole, after the M5 is issued, so the buffer will empty? Im just asking i have to check this.

#4.For my case its not a laser, but a plasma cutting machine.

Now about predicting the "future", is there a way to but a time stamp to every M5 that is in the program, before the program will be executed?
Can we execute in the background something like the simulation, and "see" how much time the whole code needs to be executed and predict when each M5 comes?

[TomKerekes]

#3. What happens when we have to cut a part with many holes, for example. We need at every end of the hole, 300ms before the M5 comes, to stop the plasma arc. The motion will continue to the next hole, after the M5 is issued, so the buffer will empty? Im just asking i have to check this.

This sounds like your best option. When MCodes (M5) are configured as Execute Actions (Not synchronous IO) then the Motion Buffer will always be flushed and emptied before the Execute occurs. If the Job has many holes the GCode should have many M3/M5 commands and the buffer should be filled and emptied many times so I would expect this to work.

#4.For my case its not a laser, but a plasma cutting machine.

Oops, I meant to say Plasma not Laser. But it should work the same.

Now about predicting the "future", is there a way to but a time stamp to every M5 that is in the program, before the program will be executed?
Can we execute in the background something like the simulation, and "see" how much time the whole code needs to be executed and predict when each M5 comes?

The current simulation doesn't do any Trajectory Planning. But you might be able create/modify code to do such a thing. I suppose a KFLOP C Program could monitor and search ahead through the Motion Buffer looking for embedded M5 commands and determine their timing.