If it is a one time thing, i would drive the robot to the desired joint position, then record it in cartesian, and do the linear move that way.
If this is a repeated thing you want to do programatically, short of writing the kinematic equations yourself, i am not sure if you might be able to do something clever with LPOS, JPOS, or PR's. Since a PR can represent a point in both Joint and Cartesian, you may be able to perform a linear move to a joint representation PR[]. I have never tried this, but it would be my first experiment. Then you could set up a single move L PR[x] 50mm/s Fine (or whatever), with a set of lines before performing a PR[x] = JPOS to set to Joint representation, then PR[x:1] = R[1], PR[x:2] = R[2], etc...
Kinematic equations would be the most difficult way, but basically guaranteed to work, and can be easily shifted by user and tool frames once created. (i have not touched a kinematic equation in 3 years, and i was not great at them then, so good luck)
What is the application, maybe there is a better way?
I have recently talked with Fanuc about this in depth. The short answer to your question is yes. You can use joint position data and move to it in a linear move. The controller first calculations the XYZWPR data for the point with the given tool. Then it calculates the linear move from the location it is at before the move.
Just be aware that the robot will take the shortest joint angle when doing linear moves. If your move says J6 should be at 365°, and the robot's J6 is sitting at 0°, the robot will move J6 to 5° instead of the 365° stored in the point.
Just be aware that the robot will take the shortest joint angle when doing linear moves. If your move says J6 should be at 365°, and the robot's J6 is sitting at 0°, the robot will move J6 to 5° instead of the 365° stored in the point.
This is really important and a major drawback of linear moves. Always unwind your robot if you are doing multiple linear moves in a row or you will probably end up hitting axis limits.
I have recently talked with Fanuc about this in depth. The short answer to your question is yes. You can use joint position data and move to it in a linear move. The controller first calculations the XYZWPR data for the point with the given tool. Then it calculates the linear move from the location it is at before the move.
Thank you very much
As far as I understand, there is no guarantee that the robot will move to the exact joint angles I want, right? I can only be sure that the final *cartesian* position is the one corresponding to the joint angles I want.
The reason why I want to use joint position is avoiding the exact problem mentioned by Nation, that the robot will end with + or -360 degrees with respect to the J6 value I specify. If there is no guarantee that the final angles are those specified, I could use cartesian in the first place.
Display More
If it is a one time thing, i would drive the robot to the desired joint position, then record it in cartesian, and do the linear move that way.
If this is a repeated thing you want to do programatically, short of writing the kinematic equations yourself, i am not sure if you might be able to do something clever with LPOS, JPOS, or PR's. Since a PR can represent a point in both Joint and Cartesian, you may be able to perform a linear move to a joint representation PR[]. I have never tried this, but it would be my first experiment. Then you could set up a single move L PR[x] 50mm/s Fine (or whatever), with a set of lines before performing a PR[x] = JPOS to set to Joint representation, then PR[x:1] = R[1], PR[x:2] = R[2], etc...
Kinematic equations would be the most difficult way, but basically guaranteed to work, and can be easily shifted by user and tool frames once created. (i have not touched a kinematic equation in 3 years, and i was not great at them then, so good luck)
What is the application, maybe there is a better way?
thank you
The application is painting.
I have the kinematics and generate a sequence of joint angles (very close to each other). The reason why I would like to use linear movement to joint position is to specify the speed in mm/sec referred to the tool (instead of a percentage, as it seems mandatory for joint movements)
Have you tried using Linear Wristjoint. "Wjnt"
That forces the linear movement to use the actual turn numbers.
On another note, Ignoring turn numbers by default is a very good thing for linear movements. Imagine if you offset a linear movement over the surface of a table and it unexpectedly flipped, crashing into the surface, because it changed turns. If Wjnt was the default behavior I think many people would have issues.
Sent from my SM-G930V using Tapatalk
Display More
Have you tried using Linear Wristjoint. "Wjnt"
That forces the linear movement to use the actual turn numbers.
On another note, Ignoring turn numbers by default is a very good thing for linear movements. Imagine if you offset a linear movement over the surface of a table and it unexpectedly flipped, crashing into the surface, because it changed turns. If Wjnt was the default behavior I think many people would have issues.
Sent from my SM-G930V using Tapatalk
An additional issue with that is that is that the joint speeds are based on how far they need to go to meet the linear speed requirements, which means that large joint angle changes over short linear distances are very violent and frequently overspeed the joints, causing emergency stop behavior. Hard to identify after the fact because the move SAYS it was relatively slow.
I would suggest using regular linear moves for a small-ish number of points, then backing away, doing a joint move to unwind, then moving back in and doing a few more linear moves.
An additional issue with that is that is that the joint speeds are based on how far they need to go to meet the linear speed requirements, which means that large joint angle changes over short linear distances are very violent and frequently overspeed the joints, causing emergency stop behavior. Hard to identify after the fact because the move SAYS it was relatively slow.
Thank you for pointing out that issue.
So, assuming that the wrist angles changes are sufficiently small that the joint speed are not exceeded during the linear movement for the given linear speed, a solution to my original request could be:
L P[1] 1000mm/sec CNT100 Wjnt
where P[1] is expressed as J1...J6 ?
Otherwise I must use joint movements, and find a way to calculate the percentage speed in order to get the required linear speed...
I believe that should accomplish what you are aiming to do. I would be careful with T1 mode, as i do not know what behavior occurs with joint moves (as far as speed goes).
We have almost all welding applications, and some times we want to step through a weld in Teach mode to verify without resetting the line that an adjustment fixed an issue, or to complete a weld that would otherwise be scrap. The weld must be performed at a specific speed (like painting). With a linear move, the T1 mode puts a cap on the speed, but any speed below that cap is uneffected. I do not know if the same is true of joint moves (it is possible, if this is not the case, that a joint move in T1 will move at a different speed than a joint move in Auto) so be sure to validate your speeds in both T1 and Auto before turning it loose. Unless you have T2, in which case, ignore all this.
Can you explain why you need to store the data in joint data? Joint data doesn't reference any TCP or User Frames.
On occasions I need to store data as joint data, but it is because I need to rotate the wrist a specific direction and speed but the location is different do to part diameter. So after a new part is started the first position it goes to is a calculated location offset by the radius of the part being processed. Once the robot goes to that location the joint data is recorded and then the wrist data is changed to create 2 new positions. One that is -540° and the other that is +540°.
