6 axis milling - How does the post solve the additional rotary?

[Watcher]

Hi folks...

 

Watching a video on YouTube I was just reminded of my curiosity about machining involving 3 or more rotaries...

 

https://youtu.be/0ULLQ6N1ruM?t=4m20s

 

Notice that the table moves as well, not only the C axis in the head... so in this machine you have a 'C' in the head and another in the table... plus the 'A' in the head (Or whatever name they gave it...)

 

I get how to find the first pair 'C' and 'A'  from IJK and turn them into ABC... my doubt is, how are the IJK vectors generated in the neutral file (NCI, APT, etc) so that the table´s 'C' is also there... 

 

I have a few theories but if someone with a better multiaxis PP knowledge could chime in I´d appreciate...

 

#1 - The vectors IJK are meant, each, for a rotary axis. The problem with this theory in my head is that in the machine above, the two 'C' axes have their rotation axes parallel to each other, in any direction. This causes some sort of singularity as well as far as the logic can tell me. IJK are by design distinct directions from each other.

 

#2 - These are processed by especial CAM systems that can, not only calculate the positions of the head and table, but also add some extra data in the neutral file so the post can solve the extra rotary. This theory is somehow stupid for me because for a long time robots are programmed in regular CAM systems using advanced PPs and they´re always able to solve it.

 

Can someone shed some light about how that extra 'C' on the table is solved by the post using XYZIJK data? I´m not asking for the math... just the explanation...

 

I believe robot programming deal with this on a daily basis... but this is a grey area for me...

[jlw™]

Mastercam can not do it with out doing it in the post.  The software is only capable of 5 axis output.  However, you can do as I do and input the value into misc real and use that in the post.  It  will take a little extra work in every single file but you can do it.

[Watcher]

Mastercam can not do it with out doing it in the post. The software is only capable of 5 axis output. However, you can do as I do and input the value into misc real and use that in the post. It will take a little extra work in every single file but you can do it.

I don't think you can solve it using MIs in continuous motion like in the video...

 

One thing that crossed my mind was if you have a motion in C that is let's say, 30 degrees, the post would move C1 15 degrees and C2 15 as well... but that seems to be very unpredictable... what you see is not what get...

[huskermcdoogle]

Looking at the video it was just the camera perspective that made it look like the head C was moving.  I believe it was parked and the table was moving.  If you look how the head is pointed at the window, it seems to me to be parked.

 

If you had the time, I suppose you could spend the time to split the about "Z" movement between two rotaries, this would in turn lower accelleration on that "result".  However you would also need to be aware of other axis movement/acceleration.  I am guessing you would not be using tcp in this case and would let the post figure it all out.  It would be interesting to see if any controls out there these days can handle tcp with three rotaries, vs just two like normal.  I have a machine with three rotaries...  Would be interesting to see if I could apply wsec or tcp on my rotary table as well.

[AlbertZini]

[Watcher]

I initially thought it was only the table... but it's not... move forward to 4'52" and you should see it...

 

Looking at it again I'm not so sure anymore... But anyway, my question stands, from the PP perspective...

[Watcher]

Looking at the video it was just the camera perspective that made it look like the head C was moving. I believe it was parked and the table was moving. If you look how the head is pointed at the window, it seems to me to be parked.

 

If you had the time, I suppose you could spend the time to split the about "Z" movement between two rotaries, this would in turn lower accelleration on that "result". However you would also need to be aware of other axis movement/acceleration. I am guessing you would not be using tcp in this case and would let the post figure it all out. It would be interesting to see if any controls out there these days can handle tcp with three rotaries, vs just two like normal. I have a machine with three rotaries... Would be interesting to see if I could apply wsec or tcp on my rotary table as well.

I'm 100% sure that Heidenhain and Siemens can handle TCPM and WSEC with up to 7 axis properly configured. I worked in a project with a Czech Heidenhain guru from TOS Varnsdorf - He made our 7 axis HBM to dance with up to 7 axis, including heads.

[Watcher]

I'm more convinced now that it is indeed a 6 axis machine...

 

Look at the picture in the bottom of the page... The angle of the head related to the sheetmetal and table...

 

 

http://www.trimill.cz/products/vertical-milling-machines/5-axis-with-rotary-table

[Newbeeee™]

That Zimmerman machine has some serious acc/dec for such a big girl...

[jlw™]

My bad, you could do it postitioning but you have to know where you want to position it and program it to kenimatics. It could be done psotioning. You could also do it where you switch it woth mosc real/int between AB and AC mode but ABC output will not be possible out of mcam.

[Watcher]

The Zimmerman head above is a proof that the kinematic model exists...

 

That being said, I'm not sure that Mastercam cannot program it with ABC output... I think this is solved at the post level...

 

People program robots with Mastercam... And other systems... CIMCO sells 6 axis posts... It's there... I just don't get it..

[Watcher]

Another thing that just crossed my mind is that maybe CAM systems and the post can't handle it indeed... In this case the post output raw XYZIJK and the control handles it...

 

Best example of this are parallel kinematic machines... They don't have rotaries but can be programed by any system 5 axis capable using XYZIJK... The motion is resolved at the board level in the machine...

[jlw™]

Daniel, it will have to be handled in the post and I don't see how it is possible as nothing will be passed to the post. Mastercam is 5 axis software. It can't even handle 4 linear and 2 rotary. It's just not there.

[jlw™]

My first guess would be Topsolid or Esprit.

[Watcher]

TopSolid is kinematic aware, which means it tries to solve the problem with the axes that are available in the machine... They programmed our 7 axis HBM nicely...

 

But in the end they're all '5' axis in essence... I mean... I'm almost 100% sure that it's not about the CAM system... Is how you solve IJK...

 

XYZIJK is a perfect solution... it is able to represent any possible orientation in the 3D space... I don't think more than this is required...

 

Now again, think about robots. Software programing them need to use motion planning algorithms to avoid singularities and respect certain constraints imposed by the programmer... not sure about how they do it currently but Mastercam used to be the foundation package for robot master...

 

So all in all, 5 axis systems are able to program more than 5 axis... But the trick is the post...

[Watcher]

Like Ron said this week, think about your arm. You can reach the same object in several different joint angles... This is called inverse kinematics... find out the angles in the joints that can get a vector oriented in a certain orientation and XYZ position...

[Rocketmachinist]

Here is another 6 axis machine.

 

[Watcher]

Colin,

 

Any insights here?

[Watcher]

If you look carefully to this Zimmermann 6 axis head, you´re going to notice it´s actually ABC. And they´re ortogonal to each other, which means that they fit perfectly into IJK definition... in the machine A0B0C0, the vectors are 0 0 1. I could bet my best beef these machines are programmed simply with Sinumerik TRAORI A3,B3,C3 or Heidenhain TN... only the vector normals and XYZ are passed to the CNC... the PP don´t do a thing... just prefix NCI coordinates with X= Y= Z= A3= B3= C3=... for example... In the example below it is TRAORI because it´s a Sinumerik 840D Powerline control....

 

More about these heads here:

 

 

I think that the original video I posted, it´s actually a table / head... it gives you the wrong impression...

[MIL-TFP-41]

If you look carefully to this Zimmermann 6 axis head, you´re going to notice it´s actually ABC. And they´re ortogonal to each other, which means that they fit perfectly into IJK definition... in the machine A0B0C0, the vectors are 0 0 1. I could bet my best beef these machines are programmed simply with Sinumerik TRAORI A3,B3,C3 or Heidenhain TN... only the vector normals and XYZ are passed to the CNC... the PP don´t do a thing... just prefix NCI coordinates with X= Y= Z= A3= B3= C3=... for example... In the example below it is TRAORI because it´s a Sinumerik 840D Powerline control....

 

Wouldn't that mean a simulation nightmare? I suppose a simulator would have to have that particular machine builders info on how it would interpret which rotary to move when......

[Watcher]

Wouldn't that mean a simulation nightmare? I suppose a simulator would have to have that particular machine builders info on how it would interpret which rotary to move when......

 

Not really... If you´re talking about embedded CAM simulation, their algorithms use inverse kinematics to find ABC based on IJK from the NCI... if there are degrees of freedom available, the better for them to find the solution...

 

If you are talking about simulating G-Code, it´s also a breeze for them... If you´re passing vectors, they find ABC as well... if you are passing ABC, then they don´t even have to compute the angles... just move the rotaries... VERICUT and NC-Simul handles this hands down... Their TCPM macros can handle crazy stuff...

[Zoober]

The way I see that Zimmerman, is the math is not more complex, they are just dividing the dual solution rotation combinations by splitting the AC by adding a B divisor.

That could actually be done with the existing post by simulating the seed start position and limits MI's with math.

Instead of forcing a re-position when you hit a limit, it engages the B axis to modify the vector so that AC can now achieve it.

But that area of the post is prolly binned, so this is just speculation.

This setup doesn't actually add degrees of freedom, it just divides them up into shorter move solutions.