Trying to update to metric

[blackbolt9]

Previously everything has always been run in english (G20) mode and therefore everything in the control is setup that way as well (offsets, tool data, etc.). I'm trying to convert over to using metric (G21) mode and programming in metric from this point forward since previously drawings have needed to be manipulated to program them. It obviously makes more sense to not make those changes and program in metric, however, I will still need to be able to run the old english programs without making any changes to do it, the operator will be unaware of whether they are running an old english program or a new metric one.

I have already written one program in G21 mode and ran it at the machine to verify that everything could work. It appears that after running a metric program the tool data shows up in mm and after running an english program the tool data shows up in inches. So it appears that the contorl does make a conversion. However, when I run my metric program the tool is nowhere near the table. It appears that X and Y locations are correct but I have not been able to verify this since the tool is so high that I can't cut anything to actually verify tool offsets in metric mode. Am I missing something that needs to be compensated for in Z when running in metric mode? Is that another "G" command or do I need to make a compensation in my programming? I'm guessing there is an easy fix for this but I don't know enough about the controllers to come to the right conclusion.

BTW, I have 4 similar machines. Two of them have the Fanuc 15-M controller and the other two have the Fanuc 180i-M controller.

Thank you for your help and suggestions in advance,

Tom

Searched "180i-m" and "15-m" but didn't come up with anything.

[angelw]

Set bit 0 of parameter 5006 to 1 for tool compensation values to be automatically converted. However, when this parameter is changed, the tool offset data has to be reset.

Regards,

Bill

[christinandavid]

Check those tool table figures - from what I've heard recently, the control may be simply moving the decimal place around ie not converting the values, just changing the input resolution...

A quick fix to keep your old programs working may be to use a scaling g-code (if you have the option, you may be able to specify the scaling factor for each axis individually) in the program. (Never tried it myself...)

My advice is to edit your old programs so that everything is in metric - I know it may sound long-winded, but every other approach is inviting a balls-up every single time the job is run.
At least if you convert the programs you only have opportunity to balls-up on the first run....as long as someone else double-checks the figures, you should be ok.

This reminds me of the JSF drawings...they took metric components and converted all the dimensions to totally obscure imperial equivalents...then us poor operators had to convert back to nice round figures (we used metric mode as a rule)...and then the CMM reports were pumped out in imperial. There were balls-ups a-plenty that day.

DP

[blackbolt9]

I don't remember the numbers now. I think they were totally different numbers though, not just a moved decimal place. I will try to double check that tomorrow.

I would love to just rewrite the old files, but we literally have thousands. Thinks several gigs of programs when each program is usually less than 100kb! No way that is going to fly. I guess I will keep working. It seemed like the X & Y values scaled correctly using the G21 command but the Z did not. I am starting to wonder if it is because we set X & Y offset values with a G54 command but are not offsetting the Z value with it. That tells me the Z value is a global variable and we may just have to add that to our G54 line to make Z scale correctly as well. If I come up with something I'll update the board.

Thanks!

Originally Posted by christinandavid Check those tool table figures - from what I've heard recently, the control may be simply moving the decimal place around ie not converting the values, just changing the input resolution... A quick fix to keep your old programs working may be to use a scaling g-code (if you have the option, you may be able to specify the scaling factor for each axis individually) in the program. (Never tried it myself...) My advice is to edit your old programs so that everything is in metric - I know it may sound long-winded, but every other approach is inviting a balls-up every single time the job is run. At least if you convert the programs you only have opportunity to balls-up on the first run....as long as someone else double-checks the figures, you should be ok. This reminds me of the JSF drawings...they took metric components and converted all the dimensions to totally obscure imperial equivalents...then us poor operators had to convert back to nice round figures (we used metric mode as a rule)...and then the CMM reports were pumped out in imperial. There were balls-ups a-plenty that day. DP

[stevo1]

Originally Posted by angelw Set bit 0 of parameter 5006 to 1 for tool compensation values to be automatically converted. However, when this parameter is changed, the tool offset data has to be reset.

Bill,
What do you mean by "reset"? Does the tool offset table get cleared when changing this parameter? Just curious for my own info as I had no idea that there was a parameter for this.

Is there a reason for this setting? One would ass u me that if you wanted to switch the machine from inch to metric with using G21 why would you NOT want your offsets to change to metric. Sounds like an easy way to get FUBAR.

Stevo

[angelw]

Originally Posted by stevo1 Bill, What do you mean by "reset"? Does the tool offset table get cleared when changing this parameter? Just curious for my own info as I had no idea that there was a parameter for this. Is there a reason for this setting? One would ass u me that if you wanted to switch the machine from inch to metric with using G21 why would you NOT want your offsets to change to metric. Sounds like an easy way to get FUBAR. Stevo

Stevo,
I agree, it seem like a superfluous parameter; logic would indicate that the conversion of the offset should occur no matter what.

Its my understanding that if the bit is changed, then the offsets have to be set again. I'm not sure what happens if this step is omitted, whether the conversion is not initiated until this is done, I'm not sure of.

I set this on a machine recently that came from a shop that carried out their work in Imperial mode and the new home for the machine swaps between the two systems regularly. As the machine came with no tools, I set the tool offsets as the tools were being loaded, so the decision was made for me with regards to resetting the offsets. The next time I'm in front of a machine I'll see what happens if the bit is changed and the offsets not reset.

Regards,

Bill

[angelw]

Originally Posted by blackbolt9 I would love to just rewrite the old files, but we literally have thousands. Thinks several gigs of programs when each program is usually less than 100kb! No way that is going to fly. Thanks!

Having converted programs with G21 and G20 at the start of each respective program is the safest way in my opinion. My own Editor/Comms package has a function that will convert programs either ways between Metric and Imperial mode with just a couple of key strokes, and even incredibly large programs are converted very quickly. I'm sure there would be other systems around that would do the same.

Regards,

Bill

[sinha_nsit]

Originally Posted by christinandavid ... from what I've heard recently, the control may be simply moving the decimal place around ie not converting the values, just changing the input resolution...

I also heard this.
It appears that offset setting done in one mode (say mm mode) becomes useless if the program is in the other mode.
But, considering the flexibility provided by the control, there must be a way out, so that there is no need to repeat offset setting when mode is changed.

[stevo1]

My interpretation of the offsets based on what Bill has said and the PDF posted is that changing this parameter will probably initiate having to powercycle the machine and when doing so it will clear the offsets and they need to be reset. I ass u me that this is a onetime deal.

I had Fanuc series 10,15,18 that had to switch back inch to metric and vice versa all the time. I never had a problem with the offsets or anything for that matter. I was just unaware of this parameter. It must have always been set. I always did as Bill stated. For the programs that ran in metric I put G21 at the beginning of the main program. The ones that ran in inch I put G20 at the beginning. Never was a problem.

Stevo

[sinha_nsit]

This means that offset values automatically get converted in the other unit. It is not just decimal shift. Might be parameter dependent.
What happens to the values set in parameters for reference position etc.?

[stevo1]

Originally Posted by sinha_nsit What happens to the values set in parameters for reference position etc.?

All of the reference position parameters that I have ever set have been in metric I believe this has to do with metric or inch ballscrews. I don't think it matters. These are not converted.

Stevo

[blackbolt9]

Originally Posted by stevo1 For the programs that ran in metric I put G21 at the beginning of the main program. The ones that ran in inch I put G20 at the beginning. Never was a problem. Stevo

This is what I'm currently doing. Just need to figure out why my Z-position is screwy when running a G21 metric program.

Thanks,
Tom