I have a 5 axis machine with A head and B table. I have make the simulation based on sim07. The PLANE SPATIAL does not work well. When I move only the B axis (table) all is OK, but if I move the A axis (head) then the simulation doesn't work.
The problem here is that the Z axis depends on A axis, so when the A axis moves, the Z axis changes its direction. (see the pictures attached).
Have you any ideas to resolve the problem?. How can I tune the PLANE command to make the simulation work?
my first fast feedback is that I never face such a kinematic case before, so need more investigation if the OOTB PLANE implementation will support it.
I´ve a lot questions:
- Chain definition correctly in kinematic model? Using correct chain name? --> GV_strSwivelingChainName
- Origin of machine zero correctly? Move all axes to zero and check if the tool mount position matches with the machine zero
- GeoAxis definition in channel configuration correclty?
- Axis Limits correct? GV_dFifthAxisLimitMax/Min, GV_dFourthAxisLimitMax/Min
- Vector settings correct? GV_dFourthAxisX/Y/Z, GV_dFifthAxisX/Y/Z
- Axis names correct regarding kinematic type? GV_strFifth/FourthAxisName
- Axis names correct regarding kinematic type? GV_strRotaryAxisNameForQ121/122/123
Hi, Thomas, thanks for your interest.
I think all the variables are correct. In fact, if I simulate with a program where only the B (table) axis moves, then the simulation is correct.
GV_strSwivelingChainName -> Matches the kinematics definition (No errors when simulating)
- Origin of machine zero correctly? Move all axes to zero and check if the tool mount position matches with the machine zero. -> Yes. I have check it and is OK.
- GeoAxis definition in channel configuration correclty? Here I have some doubts, because the Z axis change its direction when A axis changes, but the definition of GeoAxis seems Ok.
- Axis Limits correct? GV_dFifthAxisLimitMax/Min, GV_dFourthAxisLimitMax/Min -> Checked and OK too.
- Vector settings correct? GV_dFourthAxisX/Y/Z, GV_dFifthAxisX/Y/Z -> Yes they are correct. In fact the simulation is all OK, is a bad positioning when plane spatial is aplied but the movemnts are OK, only displaced in space.
- Axis names correct regarding kinematic type? GV_strFifth/FourthAxisName -> Yes. A and B are the axis names.
- Axis names correct regarding kinematic type? GV_strRotaryAxisNameForQ121/122/123 -> A,B,C are the names I think there are OK. I don't have C axis, only A and B.
For an example of the machine, you can check the IR 9014220.
I've had this problem before. When working with channels and chains, the linear kinematics axes must have certain numbers.
Please check in the Machine Tool Builder for kinematics if the X axis has Axis number. 1; Y no. 2 and Z no. 3.
It is very helpful if you switch on the Axis Number column.
Hope this helps
Thanks Heinrich, but when I defined the kinematics I had already check that. The X axis es 1, Y is 2 and Z is 3.
You are right, there are methods that assume those numbers for axes.
Ive looked into the IR data and have a quick solution for you. At first, thanks for this interesting machine and the very interesting problem ;-) All you did upfront was correct! There was a enhancement needed in the linear offset iks calculation.
Please add the attached method to your MCF file. This method 'GMe_SwivelingCalculateLinears' is called from within the PLANE metacode. It calculates the linear offsets based on the given chain, the part and tool angle.
The solution was, that the IKSLinears have to consider the linear offset from the CYCLE DEF 7 values. I´m not sure if that implemenation is easy usable for an "easy" 5 axis machine too. When start working on the PR, we need to think about how we can implement this generally. But now you have a solution and you can make the customer happy (hopefully)
If you have further quesitons let me know.
Hi Thomas, many thanks for your response, but I must be missing something because I have created that method and now the simulation is even worse. The movement with only the C axis (table) now does not positioning correctly and the turn with the B axis (head) still fails to positioning correctly.
have you moved the $TOOL transfomration to the top of the stack as shown in the zipped screenshot?
Sorry... I see it doesn´t work when rotating the B table. I´ll look into it and give feedback.
Wow, sorry I didn't see the png.
Now, the B rotation is working well, but when the table (C axis) rotate, the simulation is not positioning correctly, the Z coordinate is moving inside the machine. The path seems to be correct but far from piece.
I just see you post modification.