4th axis engraving ??

[Gary Campbell]

Terry, et al...
I didn't intend to resurrect this older thread, but it may be relevant. With Terry's Wrapper aside, and assuming that I have a viable CAM application (Vectric) that will output rotary wrapped code. Assume the code originated as X to B or X wrapped around Y. X remains at 0, on the axial center of the rotary axis

There is a discussion ongoing where one user proposes G93 may be the only way to accomplish the following, but my position is that most controllers can accomplish it via G94

Assume machine position is X0 Y0 Z1 B0
If given the line: G1 Y10 Z1 B720 F120 There appears to be 2 scenarios:
1) Where B is rotated at 120*/min and line execution time is 6 minutes
2) Where Y and Z move at 120 ipm, rotary is synced and line execution time is 5 seconds.

The difference seems to be in the ability to "sync" or "slave" a rotary axis to the linear.

Can someone in the know inform me which of the above would be true using UCCNC, or provide an example of a scenario that would be true?
Thanks in advance, Gary

[Gary Campbell]

Terry...
That's what I had assumed because I had heard of "no current support for rotary axes", but wanted to make sure. Thanks for the clarification.

That definitely places UCCNC in the minority of todays popular (router) controllers, regardless of price.

[cncdrive]

Terry is right, that there is no specific "rotary" axis in the UCCNC.
All axis are handled as linear axis which does not mean that you can't do rotary work, you can: https://www.youtube.com/watch?v=Ox4SrYt-qEY

And non of your points 1. or 2. is the case.
When you code G1 Y10 Z1 B720 F120, then all axes will move syncronised and all axes will reach the target point the same time and the feedrate F120 is on the vectorial sum of all axes which is a virtual space of YZB axes in this case, but it could be upto a 6 dimensions space of XYZABC in case you code all axis in once.
It's hard to visualise this, because the space in this world has 3 dimensions only, but if you think into it I'm sure you will understand.

To do so called specific "rotary axes" support a software could have 2 options (The UCCNC does not support any of these at the moment):

1.) To support rotary axis in a way when it is defined how to compensate the movement distance on that radial axis. So, that the feedrate will be calculated on the surface of the cylinder around the rotary axis.
E.g. to define that the A axis is rotary and it's center line is at Z=0 and so the software will then know the geometry, the circumference of the axis, because it then knows that the radius is defined by the Z axis.

2.) To support kinematics and so the user let the software know the properties of the machine, around what lines are the rotary axes are bending around in the workspace and also how the axes are connecting to eachother. A good example is a rotary BC table where the table can bend to one direction and there is a table on the top of it which can rotate around.
So, then the software knows the kinematics of the machine and so it could make the required matrix transformations to execute different motions, e.g. linear interpolation and orientation commanded moves.
Another example is a robotic arm where the joints connect to eachother and so doing a linear interpolation with set feedrate which requires matrix transformations on the geometry to calculate how the joints have to be rotated to do the commanded linear or other movements with the set feedrate.

Ofcourse the first point is much simpler to achive than the second. I know, because I've studied robotic arms a long time ago when I was in college, we even had to do exam in which calculations like that had to be done on paper. It's not easy math I can tell you, especially when you have to do it on paper.

[ger21]

To do so called specific "rotary axes" support a software could have 2 options

Don't forget about G93 mode.

[cncdrive]

Gerry, yes, I know, I just always considered G93 as a special and infrequently used code.
One reason for that is that I have not seen any CAM programs so far which have used it, second it wastes lots of data space with the requirement of codeing the F feedrate on every single motion code line which might be OK with some hand coded short files, but will quickly qrow the file size when the code is from lots of line segments when a drawing is wrapped around a cylinder with enough arc resolution and the code looks not so nice when there is an Fxxxx on every lines.
And the third reason is that even some CNC controller manuals mentioning it as a rarely used code.

[cncdrive]

Hi Terry,

I was talking general about this type of application.
I've tried to concretize as few as possible.

I'm not saying that everybody using the Z=0 as the center line for a rotary axis. I'm just saying it as an example for usage. And I said it only to let see that the controller must have somekind of information about what the actual cylinder diameter is. In other words the controller must have some information about the machine kinematics. Even if it is only that the Z=0 is the center line and the Z distance is the cylinder diameter, but that is still information. Without any informations the controller can't have an idea about what the actual diameter is and so then how could it do a feedrate on the cylinder of that axis...
OK, there could be other ways (like inverse time feed G93), but this was mentioned as one way...

And no, point 1. does not apply to the UCCNC nor to any other controllers which doing linear interpolation. That would apply only for G1 B720 F120, but not when other axes are also moved in the same line, because the feedrate is calculated on the movement vector in the N dimensions space, where N is the number of axis moved and the vector lenght and direction is the summary of all vectors on all moved axis. So, mathematically point 1. does not covers it.
To understand it just think in e.g. 2 dimensions and let they be X and Y. And let's make a move from X=0 Y=0 to X1 Y1 with a feedrate of 1.
So, the feedrate on the movement vector will be 1 units per minute and in the mentioned point 1. it is assumed that this movement will finish in 1 minute, but it is not.
It will finish in 1.414 minutes, because the length of the movement vector is 1.414 units, because by the Pythagoras equation the length is c = sqrt(a^2 + b^2) = 1.414 units which will be finished in 1.414 minutes with the 1 units per minute feedrate.

The same way in point 1. when B=0 and then B720 and F120 will not finish in 6 minutes when other axes are also moved together, because the summary length of the movement vector is not 720 units for the same reason as I above described...

[Gary Campbell]

Balazs...
I agree that although more than viable, G93 practical uses are limited in todays world.

OK, of course I defer to your greater knowledge where my scenarios 1 and 2 do not apply. Please provide the line of code with either feedrate or execution time for the alternative, as I asked. An alternative may be more than adequate, but I simply am not aware of what it would be.

Your explanation leaves me wondering if UCCNC is truly "unitless". If this were the case, wouldn't the XY axes interrelate to the rotary axis in the way that the Z might to a 50 or 100 times longer Y or X that operates at a much higher feedrate? Z can be 6" travel with 100 u/min max, Y can be 240" travel with 1000 u/min and B can be 1,000,000 units travel with a 144,000 u/min feedrate. Can they all be given a G1 move and arrive at the same time based on the XY feedrates? If not, you are seriously behind the development of other controls.

[cncdrive]

The path is not 720 units long, but the total vector lenght on the YZB axes, so execution time will be not 6 minutes, but more than that even if we neglect the acceleration and the decceleration path and assuming an infinate acceleration and decceleration then still it will be not 6 minutes, because the path is not 720 long.
And the axes ofcourse will finish the movement the same time, because G1 is linear interpolation.

I've made a drawing to let you see that the length of the path is not 1 when e.g. a G1 X1 B1 is coded, but the length of the path is 1.414.
And so programming a F1 will not finish that path in 1 minutes, but in 1.414 minutes, because the programmed feedrate is always the feedrate on the path and so going through a 1.414 units long path with 1 units/min feedrate will take 1.414 minutes and not 1 minute.
The same is when you code more axes, e.g. 6 axes. The movement vector is then on a 6 dimensions space and is not a single dimension line and so the length of the path in the space is not 720 when you code B to move from 0 to 720 and when you code other axes to move the same time creating a multidimensions path. So, the execution will not be 6 minutes but always more than that, because the path will be always longer as long as you coding other axes also.
I'm sure there are better ways to explain this, but I don't know how.

[cncdrive]

Gary,

I don't really understand what you want to say or ask.
But G1 is linear interpolation. When you program a feedrate and a linear interpolation move then all axes will pick a speed to move the axes in the N dimensions space (where N is the number of axes programmed to move) on the summary vector in the N dimensions space with the programmed feedrate. So, ofcourse X will operate on a higher speed than Y if the X is more far from the endpoint than how far Y is from the Y end coordinate. If it was not like that then it was not linear interpolation.
The axes are syncronised together to do their own full distance of travel and to finish the same time with making the tool to travel with the F feedrate along the programmed line in the N dimensions space. This is how linear interpolation works in G94 mode with any CNC controls.

[cncdrive]

Your explanation leaves me wondering if UCCNC is truly "unitless". If this were the case, wouldn't the XY axes interrelate to the rotary axis in the way that the Z might to a 50 or 100 times longer Y or X that operates at a much higher feedrate? Z can be 6" travel with 100 u/min max, Y can be 240" travel with 1000 u/min and B can be 1,000,000 units travel with a 144,000 u/min feedrate. Can they all be given a G1 move and arrive at the same time based on the XY feedrates? If not, you are seriously behind the development of other controls.

Sorry, but I don't really understand this. Please give me an example G1 code which would do that with any CNC controls?
Based on the RS274 standards a linear interpolation feedrate is always understood on the programmed path and not on the XY plane only.
And why the XY plane, why not the XZ or why not the YZ or why not the XYZ etc. I mean what defines which axes are the path and which axes are not the path for the path feedrate?
How would you program that in a CNC software? There is nothing for that g-code wise.
And again there is no specific rotary axes in UCCNC, but I have described it in details a few posts back.