Forcing A0 output for each tool change in MPMaster under 2017

[Carbonwerkes]

Hey guys

Hopefully an easy question. Using MPMaster uner MC2017 on a 4axis VMC. For whatever reason, it isn’t outputting an A0 for initial positioning after a tool change. I get the X/Y/Z values, but no A if the value of A is 0. So, if there is an A-axis bias from a prior op, then problems…

I have tried a few things I have found via search here- for example frc_cinit   : 1

Just wondering if there is a basic codeblock that perhaps I need to uncomment, or if there is a pass parameter, etc. Ive not had luck pecking at this, so I though perhaps someone here with far better knowledge of the post might be able to point me in the right direction-

Any help is appreciated, as always.

Thanks guys- enjoy the week

[Leon82]

Usually in the tool change block they have for example a pfxout for x axis to force it to output

Yours may not have the f so it may say pxout.  You will have to know how your a axis is labeled in there.

 

It may be more complex than that depending on the post

[Leon82]

I took a look at the 2018 copy I have. The pfcout is there but there are conditions where it doesn't like if lock_codes=1 .....

 

Perhaps it could be a miscellaneous integer

[jlw™]

Do you have the A axis defined in the machine def?  Are you getting other A axis output?

[Colin Gilchrist]

Look in 'prwtt$':

           #sav_rot_on_x = rot_on_x    #Uncomment this line to output rotary axis value even when it's not used   

Remove that pound sign, and let me know if that didn't fix your problem...

[Carbonwerkes]

Hi Colin

That does seem to have fixed the problem in play here. So, firstly, let me say thank you for your time and insight; it is not the first time you come to the rescue- and it is appreciated. I do pay it forward- Im just not qualified to do that here.

Secondly, although the comment assigned to this call in the post seems innocent enough, are you aware of any implications this change may cause that might lead to trouble? Hard to imagine this would be used in some conditional check and eliminate the Y axis lol. But it seems strange this would be omitted by default- since I cant see a reason to not use it 'if' the system is defined as 4+ axis.

To the others that commented on this thread-
Yes, the system did output A values for any operation that had any A change in that block of code. So, if later in an op the table rotated, the system would generate an A0 for the initial positioning. It simply neglected to do so if there were no operations that leveraged an A move.

This isnt normally a problem, but it became a problem where I had broken out a multi-op process into separate files to permit the selection of some conditional feature which had to happen in sequence. And in that, often the rotary would be offset, and it was easy to miss that, or for an operator to assume the table would return to A0 if they canted it to attach a component etc.

Best to all-

[Colin Gilchrist]

No worries my friend. Glad it fixed your issue.

Regarding your concern of screwing something up: this change will not in any way hurt your Post output.

This "feature" is simply a lazy way of being able to code the Post to "function as a 3X Post when all operations are programmed from the "Top Plane". I tend to setup my Machine Definitions with 2 Axis Combinations: a 3X Axis Combo, and a 4X Axis Combo. That serves the same purpose: to give you 4X output when you want it, and only output 3X code when you need it.

When would you "not want" the A-Axis being output? If you have a VMC like a Haas, and you happen to remove the 4th Axis Rotary (say you are doing some large plate work, and don't have room for both the 4th Axis and the part on the table), the machine will give you an error if your code contains an "A0.".

So In-House Solutions added the bit of code that would allow the Post to "always force" the A-Axis output. Of course, if they made that the "default", then they end up getting a bunch of complaints from all the guys using the MPMaster Post for 3X work. So they made the decision to insert the code into the Post, but also to "comment it out", with a pound sign in front of the line of code. It is there "if you need it", but is ignored for all the other users who don't want it by default.

[Ewood42]

18 hours ago, Colin Gilchrist said:

When would you "not want" the A-Axis being output?...

Or... if you have an old machine that uses clamp/unclamp codes with long dwells to build up pressure, as was the case at my last shop.

It may only be 4 seconds per clamp and 4 per unclamp, but if you program it in a way that leaves off with the A axis at the start point of the next op, and you have 3 tool changes, you're talking about 20-25 seconds of wasted time in a program if it's calling the clamp/unclamp postblock with every A move. On a 5 minute part, that's a pretty large chunk of wasted time.

[Colin Gilchrist]

25 minutes ago, Ewood42 said:

Or... if you have an old machine that uses clamp/unclamp codes with long dwells to build up pressure, as was the case at my last shop.

It may only be 4 seconds per clamp and 4 per unclamp, but if you program it in a way that leaves off with the A axis at the start point of the next op, and you have 3 tool changes, you're talking about 20-25 seconds of wasted time in a program if it's calling the clamp/unclamp postblock with every A move. On a 5 minute part, that's a pretty large chunk of wasted time. 

Sure, there are plenty of reasons of why you wouldn't want to include the Rotary Address when outputting a 3-Axis Only program. The issue is this: if you have a program with A-Axis moves, on only some of the positions, then you really should be outputting the Rotary Address on each Tool Change. The reason being; it may cause some extra clamp/unclamp time, but if you have an operator that needs to re-cut an area, and they happen to search for a Sequence Block where no Rotary Address is present, but the machine isn't at the Zero position, then you've got a situation where you can crash the machine/tool/part.

So, my preference is to use the Axis Combinations to be able to quickly choose my output mode.

1. 3-Axis gives you only XYZ, with no Rotary Addresses.
2. 4-Axis gives you XYZA(orB), at Every Tool Change.

What I detest is the "mixed" output, where you get Rotary Addresses on only some of the Tool Change events. (This was the original issue Carbonwerks posted about.)

When you use MPMaster, you can get the "mixed" output by default, which is just something I don't care for, since I've had issues with this personally.

[jlw™]

It's been my experience that rotary moves need to be output at every possible restart point.  I only output block numbers at safe start points -force tool change- and then the block numbers are on my setup sheets (X+ - the free version).  Then in the name of safer practices if some one has to restart and cut a little air then they cut a little air.  I also program with this in mind since my average part run time is around 300 hours.  I use an op for every little thing since a good part is more important than cycle time.

[So not a Guru]

7 hours ago, jlw™ said:

It's been my experience that rotary moves need to be output at every possible restart point.  I only output block numbers at safe start points -force tool change- and then the block numbers are on my setup sheets (X+ - the free version).  Then in the name of safer practices if some one has to restart and cut a little air then they cut a little air.  I also program with this in mind since my average part run time is around 300 hours.  I use an op for every little thing since a good part is more important than cycle time.

This is exactly how I do it too. In a perfect world with perfect operators, it wouldn't be necessary, but that's not the world I live in.

The trouble with trying to make it idiot proof, is that they just build better idiots.

[Guest]

4 hours ago, So not a Guru said:

The trouble with trying to make it idiot proof, is that they just build better idiots.

#truth

[Newbeeee™]

Another vote for the A output every time at toolchange.

Some controllers revert back to G54 state at reset, some don't yada yada.

Belt and braces safety  first...

[Ewood42]

22 hours ago, Colin Gilchrist said:

What I detest is the "mixed" output, where you get Rotary Addresses on only some of the Tool Change events. (This was the original issue Carbonwerks posted about.)

True. I can see that being a problem for sure. I'm still getting out of the rock bit mentality. Production runs where you're running 100+ parts at a time, every second counts so I got into what are probably bad habits for other shops.

Across a hundred parts, 30 seconds per part is almost an hour of run time... and I also had a pretty good setup guy on the machine I set up for mixed output. Only ever scrapped one due to the mixed a output.

[Colin Gilchrist]

18 minutes ago, Ewood42 said:

True. I can see that being a problem for sure. I'm still getting out of the rock bit mentality. Production runs where you're running 100+ parts at a time, every second counts so I got into what are probably bad habits for other shops.

Across a hundred parts, 30 seconds per part is almost an hour of run time... and I also had a pretty good setup guy on the machine I set up for mixed output. Only ever scrapped one due to the mixed a output.

In high-production environments, I agree that you've got to watch every second, provided there is also a system in place to make sure every part you produce meets the quality requirements of the customer.

My background is in Aerospace, where typically the lot sizes are smaller, but the quality requirements are very stringent. Often, the cost of "poor quality" far outweighs the few seconds that can be shaved off a cycle time.

For Boeing, Sikorsky, P&W, Columbia, and many other Aerospace customers, they are now charging a flat $1,000 fee for every "submittal" to MRB. (Material Review Board) That means that every time you have a non-conforming part, it will cost you that $1K minimum, just to submit the discrepancy to the customer's quality department. In addition to paying that fee, you've also got to perform a RCCA (Root Cause and Corrective Action) to ensure that the problem is corrected and there is a new process put in place to prevent making the same mistake in the future.

That all sounds well and good, but you've also got to have a culture where your operators are trained to take action, and are held accountable. I can't tell you the number of mistakes I've witnessed, where the root cause was "somebody just wasn't paying attention, and entered a number wrong, or perhaps forgot to tighten a clamp securely". How do you write up a RCCA for "do your job correctly, and double-check your own work before you make a rookie mistake"?

[Guest]

3 minutes ago, Colin Gilchrist said:

How do you write up a RCCA for "do your job correctly, and double-check your own work before you make a rookie mistake"?

That one goes under training and rarely gets addressed via training  

[So not a Guru]

46 minutes ago, JParis said:

That one goes under training and rarely gets addressed via training  

RANT ALERT 

That's because too many companies put a premium on the lip service of training, without ever providing any, actual, meaningful, training.

To many managers have been lulled (by the term "Button Pusher") into believing that automation means, any unskilled mouth-breather can perform the work, without the need for the company to actually invest in training  the employee in more than how to clock in & out.

That is exacerbated by the millennial's generational belief that they don't need any training, due to the fact that they have been getting trophies their whole lives for breathing in and breathing out.

[Seedy steve]

On 9/12/2018 at 3:55 PM, Ewood42 said:

When would you "not want" the A-Axis being output?..

My new heartford mill has the fourth axis removed , so it stops with A0 and won,t run. I've had to edit each post as a result.

I tried with cimco to edit mpfan like mentioned here  to no avail, the code is not found even in part.

 #sav_rot_on_x = rot_on_x

also I saw the note in the post that says not to edit with cimco after 2018. I am using 2018... So i tried in the machine configuration like is suggested. also to no avail.

I found the A axis listed in the table group, unchecked the box , but it still posted the A0. 

so I went into machine axis combinations , found the A axis again but the box won't uncheck! ?

is there something that I am missing?

thanks in advance

[nickbe10]

36 minutes ago, Seedy steve said:

is there something that I am missing?

The thread is talking about the MPMaster post. This is available on this site and is considered a good starting point for many 3 and 4 axis posts.

You are trying to modify mpfan which is a "base" post from CNC software (Mastercam) - it is not that it is better or worse, it is just set up differently.

In order to avoid confusion I have a MD,CD and Post set up for each machine. If you set up an MD/CD combination without a 4th axis head in the tree the post should ignore the "A" outputs in the post, the logic is set up that way.

Colin's way of setting up axis combinations will also work because again if the combination does not include a 4th axis it will bypass the "A" output in the post.

The main reason people start with the MPMaster is that it has HSM code output logic built in, which saves a lot of time of modification if you have machines with this feature 

HTH

[Seedy steve]

so i figured out how to make a new definition without the fourth axis and tried a post with mpfan ... no luck, I still got the A0. 

I will see what goes on once the tech people here let me have mpmaster, hopefuly that will fix the problem.

( I call the machine mine but it's not. ) thanks again    nickbe10

[PcRobotic]

Quote

 

 

Not sure if you guys want this but for me I prefer this...

% 
N1(FIRST CUT HERE)
G0 G17 G40 G49 G80 G90
G91 G28 Z0.
T1 M6 (TOOL COMMENT HERE)
G0 G90 G54 X(Value) Y(Value) A0.  ========================> Work offset should appear all time when shows A0. or B0.  This is for safety issue
G43 H1 Z1. M8
(Cutting)
G0 G90 Z2. (END OF TOOL PATH HERE)
(*)
N102(SAME TOOL WITH SECOND OPERATION CUT)
G0 G90 G54 X(Value) Y(Value) A0.  ========================> Work offset should appear all time when shows A0. or B0.  This is for safety issue
G43 H1 Z1.
(Cutting...)
G0 G90 Z2. M9
G91 G28 Z0.
G28 Y0. M5

M30
%

=========================
# --------------------------------------------------------------------------
# General Output Settings
# --------------------------------------------------------------------------
force_wcs   : yes$  #Force WCS output at every toolchange? Force Work offset here, G54

[nickbe10]

On ‎11‎/‎10‎/‎2018 at 8:50 AM, Seedy steve said:

so i figured out how to make a new definition without the fourth axis and tried a post with mpfan ... no luck, I still got the A0. 

I fear in that case that the post has been "broken". That is a modification has been made which disrupts the "correct" output.

You mention something about "tech guys". Are you waiting for some sort of internal approval?

Starting fresh is probably a good idea at this point.

ALWAYS make a copy (and I date mine) before doing any mods, it is very easy to unintentionally break a post and not realize it until much later. Keeping copies means you can go back to where you were before the screw up, even after a time lapse. 

Have you got the MP documentation?

[Seedy steve]

3 minutes ago, nickbe10 said:

post has been "broken".

this is not likely since it's a new install, new machine . I am the only one who could have broken the post but i didn't change anything.

unless it was a virus... not likely either. I think.

I have mpmaster now, and I set it as default into the configuration file, but the machine def. won't see it . its not on the drop down list yet.

I double checked .. it is where the path describes. 

It seems that I do have admin. rights on this laptop that is new as well.

 

[Seedy steve]

It's all good now.. thx

mpmaster is doing what i hoped for.

I managed to find all the defaults to set up the master to work for me. ya don't get to say that to often in life!  lol

steve.

 

[motor-vater]

Love the community I was just firing up the computer to post a similar question, that will complement this thread so if you dont mind I'll ask it here. I am running a program on a haas with a rotary with 150 plus toolpaths and over 80 rotations. problem is the only way this thing repeats is to keep it spinning in the same direction or at least rotate back past its next position and then forward to the correct position. I tried signed continuous it still will change direction depending on the A value output. Also I would hate to eventually get to A-50000000 or something, I'm positive that that many rotations will eventually magnify any discrepancies in the back lash. Anyway to keep it rotating into position say CCW, while staying within a rotational envelop (Say A0 through A-540?) Hope you follow this. My son is late to jujitsu so I'll check back in a bit.

Edit: even if I could force tool change and get it to return to G91 G28 A0, I could work from there... Thanks All