Preventing B-(minus) rotation from occuring in G68 mode when posting a file

[jfox-3]

Does anyone out there know how to prevent the B-Axis from going in the minus rotation when posting code?

I've tried a few different C/L commands that will move B in the plus direction before the programmed rotation occurs in the .ncl file.

We need to run in B plus most of the time for clearance reasons.

Our machine is a head/table machine (B head, C table)  The C-axis is parallel to Z-axis.

Thanks

[AustinN.C.,Inc.]

Jim,

It is tough to force a rotary head in a certain direction when the kinematic setup is head/table.  The easiest way in the post is to set the Automatic Re-positioning to take the alternate solution and set the B axis limits to 0 for minimum and that ever the Plus value is for Maximum.  That way the post will hit a the B limit if it computes a B- and switch to the B+ solution for the vector.

Fred

[rloss]

Jim,

in my posts (c-written) I have introduced cl-commands to let the user control the choice of angles of the postprocessor .

For example PPFUN / B+  oder B-  MODAL or SINGLE

Of course in simultaneous mode the issue is much more complex but I suppose you mean positioning mode because you metioned G68

Rolf

[AustinN.C.,Inc.]

There are built in commands in G-Post to do this also.  You can use ROTATE/BAXIS,ATANGL,+90 or -90 and it will basically force the B axis in that direction + or -.  This command should be immediately before the first move that positions the B axis.  It is best used when doing positioning but can be used before the start of a contouring move.

Fred

[rloss]

Hi Fred,

I am not familiar with the current state of G-Post. But the ROTATE statement rotates the coordinate system (and therefore coordinates).

Did you mean ROTHED instead maybe?

Rolf

[AustinN.C.,Inc.]

No I meant ROTATE.  This command does not rotate the coordinate system, just the axis that is specified.   If the rotary axis is a table and XYZ transforms are enabled (The default is yes) then the coordinates will be rotated based on the axis moving.  If you use ROTHED it just outputs the Bxxx.xxx but does not update the post that the head was reoriented.  ROTHED and ROTABL are positioning commands only and will not affect multi-axis motion.

Fred

[rloss]

Fred,

ROTATE is a cl-command that is in the cl-file from Pro/Manufacturing and it rotates the coordinates. It is not a CL-Word according to ISO 4343 but it is a "PTC special"

like the $$-> CSYS. When you activate cl_output_format TRANS_ROT or use subroutines you will get TRANS and ROTATEs in the cl-file and if you multiply all ROTATEs you will get the same matrice that $$-> CSYS shows. With TRANS_ROT format active you will see local coordinates (refering to NC-Sequence coordinate system)  whereas with multax mode (standard) you will see machine coordinates (refering to Operation coordinate system).

Or are we talking about something else ?

There is no standard CL-Word that I know of that would let you chose a special angle solution . But Cl-Data is a language and Pro/Manufacturing is showing the cldata and is open to enhancements. So as long as the post and the programmer understand each other everything is possible.

Rolf

[AustinN.C.,Inc.]

I was referring to the usage of the ROTATE command usage in G-Post.  I know that PTC can output the TRANS/ROTATE type output instead of MULTAX but we where discussing its usage in a MULTAX CL file.

This command is not specifically for making the post select one vector solution over the other but it can be used to influence how the post chooses the solution.

I actually think setting the travel limits in the Automatic Reposition feature is the best solution for what Jim is trying to accomplish!

Fred

[jfox-3]

Thank you both for the input.  I will give your suggestions a try and let you know how it works.