Unable to get negative BAXIS movements to post in code

[nlehman]

I have flipped every switch and configuration that I can think of trying to get Creo to output a negative B-axis movement.  The machine is currently set to shortest path in Creo, and has all the correct boxes checked (I have tried them all I am pretty sure) in GPOST, but no matter what I have tried, I am unable to get the "-" value in front of my B-axis movements in my generated code.

What am I missing?

This is our current FIL that was made for us, but even if I remove the FIL and run default GPOST, I still do not get the negative values for the table rotation.  The way our table operates, it has 0-360 and negative controls the direction.

$$ ****************************************************
$$ * R O T A T E S E C T I O N *
$$ ****************************************************

CIMFIL/ON,ROTATE
XX = POSTF(20)
ROT4 = POSTF(7,4)
ROT5 = POSTF(7,5)
IF(ROT4 .EQ. (ICODEF(BAXIS)) .AND. ROT5 .EQ. (ICODEF(ATANGL)))THEN
ROT6 = POSTF(7,6)
IF(ROT6 .LT. 0)THEN
ROT6 = -ROT6
XX = POSTF(10,6,ROT6)
XX =POSTF(20)
ENDIF
ENDIF
RAPID
XX = POSTF(21)
XX = POSTF(13)
ROTFLG = 1
CIMFIL/OFF

[KenFarley]

Are you sure about the angles you are getting from Creo? If angular measurements being passed to the machine are in the range 0 to 360, they've always got to be positive. You're saying that the sign passed to the machine with the angle specification is indicating the direction of rotation, i.e. "-" means counterclockwise and "+" or no sign means clockwise. Is that correct? It's hard for me to understand what is actually being passed to the postprocessor without knowing what the intended motion is. We don't have the necessary modules for me to try this myself.

As for the FIL code, you could try commenting out the bit of the code that is changing the sign of the angle to positive when it gets a negative value. Just put $$ at the beginning of the pertinent lines, like this:

$$ IF(ROT6 .LT. 0)THEN
$$ ROT6 = -ROT6

Then see what the results in the G-code file are, etc. Probably the default postprocessor does this angle "correction", too.

[nlehman]

Yes correct, "-" means counterclockwise and "+" or no sign means clockwise.

So basically our machines pallet can go 0-360 degrees, and the plus or minus sign controls the direction (actualy the lack of a sign is CWS, and - is CCWS)

So I commented out that code that you had suggested, and it still does not give me a minus value.  What it does do though in the code is make all my B90 sides now B270.  I am not sure what is going on with that..  I am pretty sure that is what that code was written for, I remember telling the guy that had wrote that FIL for us that all the B90 sides where coding out on the B270 side and that the B0 and B180 side were fine, if that helps at all.

[KenFarley]

I think I know what is going on after you commented out the code. It's probably a standard thing that these controllers only accept values in the range 0 to 360. When you commented out the "correction", it passed, for example, a "-90" value. Since the software knows that only angles of 0-360 are okay, it "interprets" your angle specification and makes it the angle equivalent to -90, which is +270.

This is still a problem for you, and I understand why. Your machine expects you to tell it what the final angle is, but its nomenclature requires the specification of the "absolute" angle and a "direction". For example, if you are at 30 degrees and want to go to 60 degrees, there are two ways to go, travel the 30 degrees in the clockwise direction, or travel the 330 degrees in the counterclockwise direction. They end up at the same place, but the journey is radically different. The postprocessor has to stop trying to interpret what you're sending it and just put out the exact values you are supplying it.

Perhaps someone with experience with setting up postprocessors for 5-axis machines knows how to set parameters to stop the angle correction. That's not me, we only deal with 3-axis. But, a way that it could be done is more complicated outputs based upon the B-axis coordinate being processed. You might have to just output the actual G-code line with the FIL file, instead of passing it to the usual "processor". Pseudocode for it would be something like:

IF (B angle) >= 0.0 THEN

  Just process the line normally

ELSE

  Output the complete command being processed, i.e. with G01/GO2/G03, X, Y, Z, A, and B values.

END

This might not be an easy thing to solve...but you probably know that already.

[nlehman]

Thank you for the response.  I understand what you are saying about the way the post seems to be generating the b axis directions.  However what I do not understand is the way it is trying to correct seems to be for a -359  to +359 system, the system that we have is 0-360 with the -+ dictating direction, even though in GPOST we clearly have it set to "0 and 359.99 +/- indicates direction".

It seems like it is acting like it is set to the highlighted part in the picture instead.  As for the pseudocode you had mentioned, I am not fluent enough to write code in the FIL, but I am not scared to try..

[KenFarley]

I was thinking you'd have to intercept the GOTO commands to deal with this, which would be pretty complicated, but looking at it, it seems that when you are rotating about the axis, you are indexing it, not doing a simultaneous motion in X, Y, or Z. If that's correct, the FIL code you'd need is much simpler. You'd have to build a text line that has the necessary M- or G-Codes that do the rotation, adding the "Bxxx.xxx" where necessary. Presumably it's something like

M<code to unlock>

G<code to rotate> B<angle>

M<code to lock>

I'm not familiar with the syntax of your particular machine, so don't know if this is the correct command structure.

[nlehman]

The syntax of the machine for indexing is fairly simple, it does not require a clamping code (or unlock).  The code to index the table CLW to the B90 side would simply be "G00B90" and to index it to the B90 side CCLW would be "G00B-90".  I guess that I have never mentioned that this is a Dynapath Delta 50 controller.

[nlehman · Accepted solution]

Ken, thank you for your help.

I wanted to update this thread for other users with the solution.  I was not aware that Creo also has the ability to handle some post processing before handing it off to the actual POST.  In this case, creo was using ROTATE before then handing it off to the POST to further try to process, causing errors (I am not really sure what ROTATE is).

The solution was to turn off "rotation" in your work center portion of Creo which turns on MULTAX (another term I am not really sure of), this then hands off to the POST and allows the POST to calculate the B rotation without Creo's input.

So basically as I understand it, I was originally trying to calculate B movements with two different softwares touching it, that was the cause of error.  Thanks to Fred down at AustinNC for helping with this.

turn off rotation to turn on multax