macro lag?

[glenthemann]

I wrote a macro to create true spirals for use in my shop for things like threadmilling or some roughing. All the caclulations are correct and Ive used the verify function on the mill I tested it on and it is spot on for what I want it to do.

I control the spiral by the base radius, the number of revolutions I want, the step over per revolution and the resolution of the spiral (ie how many points along the 360 there are)

I tested it out running the mill and every time it gets to a point it stops and it seems it has to make the calculation before it moves so the spiral itself is "jumpy"

I guess this just comes down to the controls ability to do the math on the fly?

[ger21]

The router where I used to work could move faster than it could process the g-code, so with lots of small segments, it would stop until it got caught up again. Sounds very similar. If you cut the feedrate in half, does it still do it?

[christinandavid]

I have created a similar macro so I can perform these kind of motions using my milling head attachment set at an angle other than G18/19. It also means I can retain a basic kind of cutter compensation.

Found that once you take away the arc functions the possibilities for the cycle are virtually limitless (involute, helical, trochoidal, parabolic). Put in an argument for the 'working plane' of the polygon that allows other applications eg pecking, plung milling, ramping a slot.

Also incorporated some features to link the cycles together to create contours, an oscillating feedrate to reduce air-cutting and an incremental rotation to reduce cutter engagement in corners.

The main drawback is the amount of calcs per move, and you really have to streamline your macro, take out all unnecessary brackets and arrange your formula in the most efficient way possible.

I'm lucky my control is reasonably fast and as long as I don't set a crazy no. of points per pass I can feed at about 10m/min. One thing I did find helped a lot was removing the fractional part of the feedrate oscillation, so maybe if you can sacrifice some of the accuracy by using [FIX] function on your values it may help some.

DP

[psychomill]

Just a thought.... do you have to have "resolution" calcs involved?
Can you not feed in Z with an XY arc? That would take out a lot calculations the control has to process....

[glenthemann]

Originally Posted by psychomill Just a thought.... do you have to have "resolution" calcs involved? Can you not feed in Z with an XY arc? That would take out a lot calculations the control has to process....

Do you mean two seperate things by your post?

By "resolution" I mean the number of points per 360 degree rotation along the spiral. A value of 2 would have 2 points, and thus 2 half circles, which isnt very close to accurate. The higher the better, I'll work out a medium and then yes Ill most likely be able to remove that calculation.

As far as feeding in Z with an xy arc, yes I can do that but none of my calculations factor into the Z feed at all.

Ive rewritten my macro 2 different ways.. I think the problem was that I had 6 lines within my WHILE loop and the control cannot look that many lines ahead, so there was a pause until it reached the next G2/G3 move.

I simplified the calculations as much as I could and I have two other methods to try which include 2 lines and 4 lines within the while loop.

I was told to try not to have any calculations within the actual movement command, but I cannot get away with this otherwise, and in hindsight even if I do get rid of the resolution variable, I will still need a fixed value which will be part of a calculation.

I'll get back to you guys once Ive tested out my newer methods (its kind of a side project so I really only get some time on the weekend to toy)

Thanks for the replies.

edit::
Could it be the use of the while loop?

[christinandavid]

The while loop is definitely faster than if, goto.

The fanuc manual I have says it can do involute arcs using G2/3 - a few more arguments involved that sound like what you are using. No good in my case 'cause you still wouldn't be able to rotate it. I can stick to small linear increments because my control automatically adjusts to a smooth limited feedrate if it can't look ahead far enough.

DP

[glenthemann]

Originally Posted by christinandavid The while loop is definitely faster than if, goto. The fanuc manual I have says it can do involute arcs using G2/3 - a few more arguments involved that sound like what you are using. No good in my case 'cause you still wouldn't be able to rotate it. I can stick to small linear increments because my control automatically adjusts to a smooth limited feedrate if it can't look ahead far enough. DP

Well I can go with the linear increments, but that just means a lot more calculations, and if it is 'lagging' like it is with only 8 points per 360 then I could only imagine going the linear route.

Ill have to look into that involute arc function, im currently trying to run this on a milltronics centurion9, some differences from fanuc but Im going to port it over (few syntax diffs.. same stuff), so I want it to be as non machine specific as I can. What do you mean you cant rotate it? you mean the starting angle of the spiral? if you cannot within the function what if you were to perform a coordinate rotation before doing your moves? I also want to map the macro as a G code for use wherever and whenever as well, I just need to fix this current issue before I go doing such things.

For all I know I could be going about this arse-backwards, but figuring out code and simplifying things turns my crank so I'll keep at it until I get it just the way I want it.

[christinandavid]

Originally Posted by glenthemann What do you mean you cant rotate it?

For my milling attachment application I may need to pocket/slot or simply move in an arc at an angle that differs from the three standard working planes available on my control. In other words I am programming as in G19 mode but rotating with a G68 around the spindle axis (G17) to suit the current angular position of the milling head attachment. I'm pretty sure I can't use G2/G3 in this scenario, unless somebody out there knows otherwise?

Apart from that fact, using linear moves means I can move my 'circle centre' from one point to another point during the cycle, as well as altering the circle size, with interesting results. I can also set a width and length, so I'm not limited to 'circular' pockets!

DP

[sinha_nsit]

eight points in 360 deg is low resolution, and it should be pretty fast. In fact, for smoothness, less than 100 points may not be acceptable. Of course, the control should be capable of doing fast calculations. And, make sure that you are cutting in "cutting mode" (G64 on Fanuc 0i), not in "exact-stop mode". Manipulating "in-position" width also might help.