cabs not updating?

[ahaslam]

Colin, if you read this I fear you will find your self shaking your head because I have a feeling this is related to the modality function you just explained to me in some way or another.

 

I am working on creating a post for a HMC and the base is the mpmasterx9 that just came out. I have made lots of changes along the way but for the most part the variable names are the same. I am having a problem with the pcout which I have set to work on my B axis. Program a part and things are great until you try to transform a tool path. When it hits the pcout I am getting the tool paths original cabs and not the new abs. I have found that I can force an update in my pcout and it will work but I don't understand why it isn't seeing the change with out a !cabs

 

I am not going to post the pcout here because it is the same as mpmaster but there is one thing in it i don't get.

if index = 0 do all the things.

 

index is set by rot_index

 

rot_index is set by param 17408

 

I don't know how to figure out what setting in mastercam runs the 17408, MP.pdf says: index axis true/false.

 

Am I barking up the wrong tree?

[Colin Gilchrist]

Hi Austin,

 

You've got a few different things going on, so I'll address them one at a time.

 

In 'pcout', the block starts with an if statement, but there are two logic conditions. The ampersand logogram (&) represents the "Boolean AND" condition in the MP Language.

if index = zero & rot_on_x,

The first condition "index = zero", checks to make sure you are not in "indexing" mode. This "indexing" mode is activated by the Properties of the Rotary Axis in the Machine Definition. When "axis positions to fixed increments only" (radio button in the Rotary Axis Properties),  is selected, then it enables "index" mode inside the post. The other three options for Rotary are "signed continuous", and "signed direction, absolute angle (0-360)", and "shortest direction, absolute angle (0-360)".

 

So again, the first option means "fixed angle indexing only", and the last three are "continuous" options. The first "signed continuous" option means the rotary angle can wind up (greater than 360), and is also signed, so you could get -6000 degrees, or 9999.0 degrees, and MP keeps track for you, based on the Tool Path you are using (really only applies to "vector based" 5X toolpaths).

 

The "0-360" options limit the output. The first one is signed +-360. (you can get negative angles)

The second 0-360 is "shortest direction", and the output is limited to 0-360 (positive only).

 

OK, so the first condition checks to make sure you aren't in Indexing mode.

 

The second condition is just the name of a variable 'rot_on_x'.

 

When you read the logic as a statement in English, the statement reads: "if the variable 'index' is equal to zero, AND, the variable 'rot_on_x' is any value other than 'zero', THEN"

 

In the logic statement, there is a bit of MP Language "short hand" going on. Putting a numeric variable name as part of a Boolean "IF" statement, without a "condition" is a short cut way of saying, "if the value of the variable is not zero, then the statement is "true".

 

So the full statement is really saying "IF we are not in Index Mode, AND, our machine has a rotary axis attached, THEN" do all the logic in between the brackets.

 

The key variable is 'rot_on_x'. This variable is set in the 'pset_mach" (set machine) post block.

 

The post first sets the variable to 'zero', then reads the Machine Definition. If there is a Rotary Axis attached (but only one!), then rot_on_x gets set. There is some additional logic that checks the orientation of the rotary axis, and eventually 'rot_on_x' gets set to '1' if it is a VMC, and '2' if the machine is a HMC.

 

So that is what allows you "into" the post block.

 

Ok, so what about 'cabs'?

 

That variable is a User Defined variable. It gets it's value from MP, "auto-magically", because MP is setup to calculate the rotary value, based on the orientation of your Tool Plane. The internal variable 'c$' is set automatically by MP. But if you go to 'pxyzcout', that is where the values for output first start being calculated.

 

If you are doing Tool Plane Positioning, then the post calls 'pxyzcout0'. This post block looks at the type of cut you are doing, and the Machine type (vmc vs hmc), and then sets 'csav' to either 'c$', or '-c$'.

 

Wait, what? Why is there 'csav' and not just 'cabs'???

 

The intermediate variable 'csav' is used because based on your Rotary Axis Continuous Type, the value gets manipulated. After the return from 'pxyzcout0', (slightly further down inside 'pxyzcout'), the post calls 'pcoutrev'.

 

It is inside 'pcoutrev' where the value gets checked, manipulated (sign can be changed, and 360 degrees added/subtracted), and then 'cabs' gets set inside here.

 

-------------------------------------------------

 

Ok, so that's how 'cabs' gets its value.

 

So what about the Exclamation Point? (!)

 

That is the "Update Variable" modifier. It is not the Force Output Modifier. That would be the Asterisk (*). Putting an Asterisk in front of a variable forces the output to the NC File regardless of Modality.

 

The Update Variable modifier does the opposite! The Update Modifier takes the current variable value, and copies it to the "previous" variable value, without outputting to the NC file!

 

So by putting update on the variable, MP makes the previous match the current, and then the variable does not get output due to Modality.

 

I think where you are getting confused is that you want to "Force" output of the Rotary Axis B Address.

 

Instead of trying to modify the 'pcout' post block, just change the post block name from 'pcout' to 'pfcout'. There is already an existing post block for "forcing" out the Rotary Axis Address. If you go look at the 'pfcout' post block, you will see that the structure of the logic is exactly the same as the 'pcout' post block, except that there is an Asterisk in front of 'cabs'.

 

So, why have the logic at all? Why not just put "force cabs" on the output line? (*cabs).

 

The reason is that the post processor is setup to maintain two different output modes, Absolute and Incremental. Inside 'pcout', there is an "IF/ELSE" logic statement that checks the value of 'absinc$'. IF the value is 'zero', then 'cabs' is output (and the Incremental value are UPDATED). IF the value is anything except zero (1), then 'cout_i' is output, and the Absolute variable (cabs) is UPDATED. This is an important feature, and shouldn't be broken without good reason. So the post writers made it easy on you by building two separate post blocks; one that uses normal modality to output, and one that always forces output, regardless of modality. All you have to do is change the 'pcout' call to 'pfcout', and it will force the output for you. Make sure you are doing that change at the Tool Change, or Null-Tool Change only. If you change it in the 'prapidout', or 'plinout' locations, then you might get all kinds of redundant B axis addresses popping up everywhere.

 

Ok, hope that helps shed some light on what you've got going on...

[rrichard]

Great guy you are Colin,

Thanks for all your helpful posts in here, I know everyone appreciates them.

[Colin Gilchrist]

Great guy you are Colin,

Thanks for all your helpful posts in here, I know everyone appreciates them.

 

I'm glad you find them helpful.

 

This forum has made a lasting impact on my career. I'm happy to give back to the place that really helped me in the beginning, when I needed it the most. I love to teach. I've taught Mastercam Classes since I was 21 years old, and the college where I studied asked me to come back and teach Mastercam classes.

[ahaslam]

I agree with Richard, your rate of return is phenomenal with this man. Colin continually supports those in need. I of all people am very greatful.
 
I should have noted this in the original post. The first thing I did was tried a pfcout. In my program I am starting with a B35 then move to a B-35. Like I had said, if I program it out right it works (B35 change tplane B-35). If I use tool path transform and then rotate the single tool path the 70 degrees the post doesn't out put a B-35. It doesn't out put anything. So I tried a pfcout. It spit out B35? So I switched back to pcout and stuck a !cabs in my post (only to debug) and it spit out a B-35. I just can't figure out why it will not up date only in tool path transform. NCI must be good because !cabs works. It isn't a pfcout vs a pcout thing, definitely a cabs update thing. I am thinking I missed a block call prior to seeing the pcout and in what ever block I missed there is a call to update.

 

Note Colin; alot has changed in my post from the last time you looked at my Z2G, I don't know for sure that I had this problem back then because I wasn't testing all the tool paths at that time. If you want to see it for your self I may have to send a new Z2G.

 

Thanks guys and enjoy the weekend.   I will be on Saturday Roll Call.

[ahaslam]

Okay, I figured out part of it. I wanted pindex and not my pcout or pfcout. Pindex has the cabs update I was looking for.