You could teach like normal (x, y origin) but your frame will be rotated 90 degrees. You could either live with that or do the math to correct it.
Why do you need to do it that way?
Is it possible to do transforms on UFrames in TP? Something like:
UFrame2 = UFrame1 * PR[1] (with a 6DOF transform).
Yes, you can do transforms with TP, although it is a bit involved.
Here I wrote something to rotate a frame by its own Z.
Re: Rotating a User Frame by its own Z axis
I was lazy, and only did the rotation aspect of the multiplication. Shouldn't be too hard to expand it to cover translation as well.
In that thread, in the post below mine, Hawkme goes over how to do the same thing with the vision support tools option, which would cover translation.
The Z vector is intrinsic based on where you teach the Y vector with regards to the X vector. Just remember the right hand rule when you are teaching the frame.
PR[4,3]=90 should be PR[4,5]=90 if you want to rotate around Y. This assumes that PR[4] is in LPOS format.
R6 will store an error code if Matrix fails. aka, you pass it an uninitialized PR or something like that.
Maybe it has something to do with the strange way it is copying the uframe into the PR, it is not the usual XYZWPR, instead its NX, NY, NZ, OX, OY, OZ, AX, AY, AZ, LX, LY, LZ, this is however the only of the 3 pr's that uses this format, is that an issue?
This is just the 4x4 matrix representation of the frame. Anytime you set a PR equal to a User or Tool frame it will be stored as a matrix rather than a cartesian position unless you change the system variable to $PR_CARTREP to true before initializing the pr. In this case, you actually want the matrix value (hence the PRs "A MATRIX" comment) so what are seeing is correct.
