Can a component know the diameter of an arc its cutting

More
7 years 7 months ago #127397 by rodw

andypugh wrote: It might be better to treat this as a geometry problem rather than circular motion.


Andy thanks. I had a few minutes this morning and threw halscope into the mix so will look a bit further before I give up. I think the rate of change might remain at 0 which kinda makes sense as the delta changes should be identical each servo cycle given a constant velocity and a constant circular shape. The other algorithm looks interesting.. I just thought of it but maybe skipping a random number of servo cycles would mean the time period would vary so its not all identical..

I had some issues today which shot my plasma plans for the weekend apart. Business comes first.

Please Log in to join the conversation.

More
7 years 7 months ago #127465 by rodw

andypugh wrote:

rodw wrote: Yeh, I think there is an error in the way I calculate the difference between the heading rate of change but I've not found it yet as I ran out of time util tonight


It might be better to treat this as a geometry problem rather than circular motion.
The needs three points, but we are already considering three points anyway to get heading rate of change.
stackoverflow.com/questions/22791951/alg...ngles-given-3-points

And a rather interesting version:
math.stackexchange.com/questions/133638/...points-actually-work


Well I've had a look at this using the latter interesting version that looked simple until I got to calculating the angle a.
Imagine we are traversing a circle, we end up with the latest side A, the previous side B and a chord from the earliest point to the current point being Side C.

The approach I took was to calculate the slopes for B and C convert them the inclinations (angle for the slope in radians). By subtracting the inclinations (atan of the slopes), I think we end up with angle a (aa in my code). Heres what I came up with:
Code:
FUNCTION(_) { static float last_x1 = 0.0; static float last_y1 = 0.0; static float last_x2 = 0.0; static float last_y2 = 0.0; static int cutting_arc = 0; /// True if cutting an arc float a,b,c,k,aa; // length a,b,c; area k; angle aa mtype = (Motion_Type_T) type_in; switch(mtype){ case ARC: if(cutting_arc > 1){ a = sqrt(pow((xpos_in - last_x1),2) + pow((ypos_in - last_y1),2)); b = sqrt(pow((last_x1 - last_x2),2) + pow((last_y1 - last_y2),2)); c = sqrt(pow((xpos_in - last_x2),2) + pow((ypos_in - last_y2),2)); aa = atan((last_y1 - last_y2)/(last_x1 - last_x2)) - atan((ypos_in - last_y2)/(xpos_in - last_x2)); k = 0.5 * b * c * sin(aa); arc_radius = (a * b * c)/ (4 * k); last_x2 = last_x1; last_y2 = last_x1; last_x1 = xpos_in; last_y1 = ypos_in; } else{ last_x2 = last_x1; last_y2 = last_x1; last_x1 = xpos_in; last_y1 = ypos_in; last_heading = heading; } cutting_arc++; is_active = (cutting_arc > 1: 1,0); break; default: cutting_arc = 0; is_active = 0; break; } }

So am I on the right track with angle aa?

Please Log in to join the conversation.

More
7 years 7 months ago #127466 by tommylight
G2, G3, I, J, K ????
Could any of those be used to drop the feed rate ?
Even if that works ( it should, just did not think about it, just got the idea now ), there remains the problem of small segments that are short straight lines ( i do have the gcodetools for inkscape set like that on one of the machines ). Not very important for now.
The benefit of this would be that all the radius’s would be cut slower, the downfall is even large radius’s would be slower, unnecessarily.

Please Log in to join the conversation.

More
7 years 7 months ago #127467 by Mike_Eitel
I have one ( silly?) question:
Isn't it typical for small holes that the acceleration of both axes is quite high and with sinosoid relation. Big holes need more time.
m5c
Mike

Please Log in to join the conversation.

More
7 years 7 months ago #127468 by rodw

tommylight wrote: G2, G3, I, J, K ????
Could any of those be used to drop the feed rate ?

Trying to do this at the HAL level not in Gcode so it just happens in the background according to some sort of Algorithm

tommylight wrote: The benefit of this would be that all the radius’s would be cut slower, the downfall is even large radius’s would be slower, unnecessarily.


Tommy, not so. Andy's idea was to use lincurve to set a table of feed rates which would be used to control adaptive feed so we can modify the result based on an algorithm I think lincurve allows 16 different levels. eg. for this radius range , use this speed override.

Mike_Eitel wrote: I have one ( silly?) question:
Isn't it typical for small holes that the acceleration of both axes is quite high and with sinosoid relation. Big holes need more time.
m5c
Mike


Possibly, I'm not sure but for small holes, with plasma you might just spot the holes and drill to size anyway.

Please Log in to join the conversation.

More
7 years 7 months ago #127470 by tommylight

rodw wrote: Trying to do this at the HAL level not in Gcode so it just happens in the background according to some sort of Algorithm

Far be it for me to keep you from doing that ! :)
I never said it was a good idea, just an idea.
Then again i might give it a try to modify gcodetools to do just that. To many projects, not enough time.

Please Log in to join the conversation.

More
7 years 5 months ago #132431 by rodw
Hmm, I finally revisited this problem and came up with the solution. I was a bit stuck on the Area of the circle
Code:
Radius of an arc (R) with 3 points on the circumference of an arc (x1,y1; x2,y2; x3,y3) R = (A* B * C) / (4 * K) Where: A = distance between point 1 and 2 B = distance between point 2 and 3 C = distance between point 3 and 1 K = area of the triangle K = (x1 * ( y2 - y3) + x2 * (y3 - y1) + x3 * (y1 - y2)) /2 A = sqrt(pow(x2-x1),2) + pow(y2-y1),2) B = sqrt(pow(x3-x2),2) + pow((y3-y2),2) C = sqrt(pow(x3-x1),2) + pow((y3 - y1),2)

Now I just have to code it!
(And Hope it Works!)

Please Log in to join the conversation.

Time to create page: 0.155 seconds
Powered by Kunena Forum