Skip to main content
N
nlehman13-Aquamarine
13-Aquamarine
March 2, 2018
Solved

Unable to get negative BAXIS movements to post in code

  • March 2, 2018
  • 1 reply
  • 7587 views

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

Best answer by nlehman

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 multaxturn off rotation to turn on multax

1 reply

K
KenFarley21-Topaz II
21-Topaz II
March 2, 2018

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.

N
nlehman13-AquamarineAuthor
13-Aquamarine
March 2, 2018

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.

K
KenFarley21-Topaz II
21-Topaz II
March 2, 2018

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.

    Terms & ConditionsCookie settingsAccessibility statement