[yaji63]

Does anyone know in what parameter the Serial number of a Fanuc controller reside ?

I have 2 machines with Fanuc OiMD controller and i have programs which have to be run only on a specific machine. I do not want a program meant for one machine to be accidentally run on the other machine. I intend to use macro variable statements and identify the machine with its control serial number (which i presume is the only unique identifier) to permit the usage of a particular NC program on the machine.

Thanks in advance for the help

[fordav11]

there is no macro variable for the serial number. it doesn't exist

[dcoupar]

I've never seen the serial number or any other unique identifier stored in a parameter.

You could set a unique value in one of the common variables (#500-#999) for each machine and protect those variables from being changed or cleared with parameters 6031 & 6032 (range of variables to be protected), then check that variable at the start of each program.

[yaji63]

I've never seen the serial number or any other unique identifier stored in a parameter.

You could set a unique value in one of the common variables (#500-#999) for each machine and protect those variables from being changed or cleared with parameters 6031 & 6032 (range of variables to be protected), then check that variable at the start of each program.

Thanks for the info. I did have an idea about the #500 and above but i did not know that they can be protected from clearing.

[texaspyro]

I don't think the Oi series supports params 6031/6032. They are not in my Oi parameter manual.

I have seen people key a program to a particular machine by putting some uniquely identifying info in an unused entry in the tool (or offset) table and testing for that.

[fordav11]

we just keep separate directories for each machine on our file server and call up those programs automatically via the software. if an operator wants a program from another machine directory he must manually copy it to a temp directory then send it to the machine.
he knows he must convert whatever is required to get it to run. in most cases it will run with minor changes like tool and offset numbers.
if an operator tries to run a program from a different machine without checking it first then it's a sign that it's time to hire a smarter operator

[dcoupar]

I don't think the Oi series supports params 6031/6032. They are not in my Oi parameter manual.

I have seen people key a program to a particular machine by putting some uniquely identifying info in an unused entry in the tool (or offset) table and testing for that.

They're in the 0i-D parameter manual, which is what he said he was using.

[yaji63]

we just keep separate directories for each machine on our file server and call up those programs automatically via the software. if an operator wants a program from another machine directory he must manually copy it to a temp directory then send it to the machine.
he knows he must convert whatever is required to get it to run. in most cases it will run with minor changes like tool and offset numbers.
if an operator tries to run a program from a different machine without checking it first then it's a sign that it's time to hire a smarter operator

I do agree with your statement about hiring a smart operator but unfortunately finding one today is pretty tough which is why I' am trying to make things idiot proof

[stevo1]

The only sure way I see this being done to make it error proof is to do it via macro variables but then you will have to add that variable to the machine and lock it as Dave has already stated. You could also do this via custom M or G code in the machines.

If you did it like Dave stated you would do something like this. Machine #1 can run program O0500 but Machine #2 cannot. In machine #2 you can set parameter 999=1 and then lock that variable from being changed via parameter. Then write your program O0500 to the following code at the beginning and end of your program.
O0500(main program)
IF[#999EQ1]GOTO1000
…
…
M30
N1000#3000=1(FORMATTED FOR MACHINE #1)

I suppose you could say that you need to set #999=0 in machine #1 and lock that as well so that does not get changed and not allow you to run the program intended for machine #1 in machine #1.

>>>>>>>

Now if this is going to be a regular occurrence of programming that is only allowed in machine #1 or machine #2 then I would look at doing a custom G or M code so that all you have to add at the beginning of the program is add the custom code.

The following G-codes and custom programs are only examples and you would have to make sure that your machine is not using the G-code I specify or the program number being called.

G201 is the custom code to allow programs only to run in machine #1
G202 is the custom code to allow programs only to run in machine #2

Set parameter 6050=201(this will call program 9010 when G201 is programmed)
Set parameter 6051=202(this will call program 9011 when G202 is programmed)

Now write and store programs 9010 and 9011 in the machine #1 as follows:
O9010
M99

O9011
#3001=1(PROGRAM NOT ALLOWED)
M30


Now write and store programs 9010 and 9011 in machine #2 as follows:
O9010
#3001=1(PROGRAM NOT ALLOWED)

O9011
M99

Now that the programs are all set all you have to do when you create a program that you want to only run in machine #1 is program a G201 as the very first line of code. If you want it to only run in machine #2 then program G202 as the very first line of code. Now if it does not matter which machine it runs in then do not use either G201 or G202.

The above seems complicated but once you set the custom codes and program in place you only have to use G201 or G202 in the programs that you write.

Stevo

[stevo1]

I do agree with your statement about hiring a smart operator but unfortunately finding one today is pretty tough which is why I' am trying to make things idiot proof

I think what you are trying to do is the right thing regardless of the caliber machinist that you have. You are error proofing a process due to unique circumstances of machine capability. I would do the same thing to avoid myself from accidentally running one of my own programs in the wrong machine if I was randomly proving something out on a Sunday with no one around.

I have many journeyman machinists working for me making $25hr+ with 30+yrs experience. However most of the forgings we put on the table are worth 50k+ before we even put a tool to them. Hiring smarter machinists…???...not an option……. I wouldn’t trust Einstein before I added a few error proof checks similar to what you are asking for.

Stevo

[fordav11]

while I like your advanced approach you're over complicating a simple problem.

our 'program for each machine in the same directory' system works very well. our transfer software simply does not allow any other programs from other directories to be accessed from that machine.
the machine number/make/model is at the very top of each program. it's impossible not to see it.
A quick meeting with all machinists can ensure everyone knows what to do.

if you want a program for a specific machine just write it and put it in the required directory. if there is no program for that part in that directory the operator can not make that part. period. the operator then goes to see the programmer who writes the program for that machine and saves it in the required directory. problem solved. forever.

you could make things idiot proof but an idiot will still screw it up. that's why Windows is at version 7 now and version 8 is not far away. it does not matter what you do, it will never be idiot proof. for example your alarm #3000 occurs sure. But the G201/G202 can simply be deleted and the program will continue. .... sorry, not idiot proof.

the solution is to create less idiots with the appropriate training and education. Ultimately it is the company that will benefit from it.

[dcoupar]

if you want a program for a specific machine just write it and put it in the required directory. if there is no program for that part in that directory the operator can not make that part. period. the operator then goes to see the programmer who writes the program for that machine and saves it in the required directory. problem solved. forever.

So how do you idiot proof putting the program in the correct directory? I've known several programmers who could be classified as idiots.

[stevo1]

Ford,
I don’t think that I was over complicating this because it is what the OP was asking for.

You beat me to it Dave. I was typing up the same question.

An operator changing or deleting a code in a program I think is more error proof then someone accidently putting the wrong program in the folder. I know because I have done it dragging a program to the obsolete folder and accidently dropped it in a different machine folder. If you do not catch yourself the only way anyone is ever going to know is some day in the future when the operator walks up and says. “I crashed the machine and scraped the part, I don’t know what happened”.

Call me over complicated but I just don't take those chances with the kind of dollars we deal with in material.

Stevo

[yaji63]

Thanks Stevo for putting out some code which i can end up using. I do use some amount of custom macro in my programs. I have a data server on the machine and have a practice of generating main programs and sub programs where the main program holds all the prep codes and sub holds only the cutting codes (this is common practice i presume). I already fool proof the program to some extent by having a code for the component in the main as well as sub and if in case the sub is not meant for that component it will return an error code and alarm.

The thing about looking for unique identifier was because i have couple of programs where the cutting parameters are different for different machines due to chatter issues. I want to define RPM and feeds based on the machine which it is being used and the automatically apply those cutting parameters upon identification of the machine. With this i dont need to depend on the operator goof up on cutting parameters and bring me a part full of chatter which will not be acceptable.

Thanks also for all of you guys who have been posting over here. Seems like idiot proofing is something which excites most of the folks in here

[fordav11]

So how do you idiot proof putting the program in the correct directory?

We use PC-DNC Plus software to link our server to EACH machine separately.
our job sheets list the machining operations and program numbers for each operation.

It's impossible to call the wrong program because each machine only has a rs232 link to one unique directory containing all the programs for that machine. each machine has its own unique directory.

With over 100000 programs that we have it'd be easy to call any old program without this barrier in place.

As a result the scrap count from using the wrong program is zero.

**That's** how to idiot-proof program downloading from a server

[dcoupar]

We use PC-DNC Plus software to link our server to EACH machine separately.
our job sheets list the machining operations and program numbers for each operation.

It's impossible to call the wrong program because each machine only has a rs232 link to one unique directory containing all the programs for that machine. each machine has its own unique directory.

With over 100000 programs that we have it'd be easy to call any old program without this barrier in place.

As a result the scrap count from using the wrong program is zero.

**That's** how to idiot-proof program downloading from a server

** That ** wasn't my question.

[stevo1]

Ford,
That is great. I have the exact same setup as you do and there is no way that you can pull a program from another machine. But there is nothing stopping the programmer from accidently dropping a program meant for one machine into another machines folder.

It sounds like you are the man in charge of that operation and setup and you also have a great success rate of 0 mistakes out of 10000 programs. What happens when you move up or on from this position and a person of lesser skills takes over and makes a mistake?

Thanks also for all of you guys who have been posting over here. Seems like idiot proofing is something which excites most of the folks in here

You’re welcome for the help.

Error proofing is something that comes with many years of hard lessons. Ford brings up a good point about keeping the operators up to speed and on the same page as the process is developed. So error proofing really applies in 2 concepts. 1 is for the operators that really just push buttons. You need to put yourself in their shoes and run thru all the scenarios of “what if I did this” and the outcome of doing so. This is where macros really come in to play. 2 is you also have to protect the process from the knowledgeable people as well. An example would be most of the experienced operators have the machine knowledge of unlocking parameters and programs so you have to put some countermeasures in place to avoid any catastrophes.

You say that it is really a S&F issue and not so much a code issue. There are a few other ways to do this without having to go thru a bunch of custom codes but it will depend on how your process is setup for these machines. If you are running production on these machines and the same tools always stay in the magazine you can use a S&F program for your tooling. I have this set on most all of my machines.

I have a spate program O7000 that I use that is called in the tool change macro so when I call the tool it sets the speed and feed for that tool from program O7000. This works great so you do not have to hard code the S&F throughout the program. This is also benifical if you switch to say a better 1/2endmill that you can increase the S&F on so you don’t have to go change all the hard code in every program that uses the 1/2endmill.

Here is a simple example (leaving out many settings) but the basic idea.

O0100(main program)
M6T15
…
…
M3S#19
G1X()Y()F#9
…
M30

O7000(S&F program)
(TOOL DATA - INCO)
N1G500F.5S315
N2G500F.5S315
…
N15G500F5.S1500
…

You set all of your tool S&F in program 7000. N1 is for tool 1 N2 is for tool to and so on. G500 will call a custom macro that will keep running until it reaches the modal T() that you called in the M6 line.

So if machine #1 can run a 1/2endmill at a F5 S1500 set it so in program 7000 and if machine #2 runs it at F2.5 S1000 then set it so in program 7000 now you can use the same program O0100 in both machines.

Stevo

[stevo1]

Sorry Dave. Was typing when you posted. I asked the same question.

Steve

[jackson]

I have a Fanuc I turn... does anyone know what parameter unlocks O9000 programs

thank you

[fordav11]

not familiar with that control.
try bit 4 (NE9) of parameter 3202
it should be labelled NE9