Machine checking macro

[Bob W.]

I thought of a useful macro that I plan to add to all of my machines and posts.  Basically it runs in the program header and verifies that the program is about to run on the correct machine.  Here is how it goes:

 

1.  In my shop I have two identical Makino A51 horizontal machines (machine #1) and one Makino PS95 VMC (machine #2)

2.  The post for each machine would be modified to set a macro variable in the program header to a value that corresponds to which machine the program will run on...  #600=2 (Makino PS95)

3.  The post would also be modified to add a macro call to the program header.  G65 P9961 (machine check macro).  This macro would verify that the value of #600 is 2 (for PS95) or it will throw an alarm out with an incorrect machine message.

4.  At the end of the program #600 would be set back to zero so programs that don't feature this functionality would be flagged and updated.

 

For a shop with numerous machines this would work very well as a safety measure to make sure a program doesn't get run on the wrong machine, especially if the tooling is different on each machine (T350 on machine 1 is a drill, on another machine it is a shell mill, etc...).  In a nut shell, if a program is posted for a Haas it will only run on the Haas and will get flagged it one tries to run it on a Mori.

[Guest MTB Technical Services]

I thought of a useful macro that I plan to add to all of my machines and posts.  Basically it runs in the program header and verifies that the program is about to run on the correct machine.  Here is how it goes:

 

1.  In my shop I have two identical Makino A51 horizontal machines (machine #1) and one Makino PS95 VMC (machine #2)

2.  The post for each machine would be modified to set a macro variable in the program header to a value that corresponds to which machine the program will run on...  #600=2 (Makino PS95)

3.  The post would also be modified to add a macro call to the program header.  G65 P9961 (machine check macro).  This macro would verify that the value of #600 is 2 (for PS95) or it will throw an alarm out with an incorrect machine message.

4.  At the end of the program #600 would be set back to zero so programs that don't feature this functionality would be flagged and updated.

 

For a shop with numerous machines this would work very well as a safety measure to make sure a program doesn't get run on the wrong machine, especially if the tooling is different on each machine (T350 on machine 1 is a drill, on another machine it is a shell mill, etc...).  In a nut shell, if a program is posted for a Haas it will only run on the Haas and will get flagged it one tries to run it on a Mori.

 

 

Bob,

 

What you have done in such a short time is really impressive effing amazing.

You are doing some things that I haven't seen any other company with the courage to even attempt.

They mostly dance around the edges and talk all day about 5S.

It would be great to read a detailed article about how you started and the process

you used to get where you are now.

 

You are practicing Kaizen/Lean in a much more efficient manner than the Japanese.

I am really surprised Makino doesn't hold you up as a poster child.

 

Kudos!

[jlw™]

That's good stuff. At a previous job where I had 5 palletized machines and one that had 7 in a carousel. I also checked for correct pallet with macros.

 

Used probing routines to check part placement and verify manual actuated fixtures were properly effected.

 

You can get as fancy as you want or as simple as you want but it's practically limitless ad to what one can do.

[Bob W.]

Bob,

 

What you have done in such a short time is really impressive effing amazing.

You are doing some things that I haven't seen any other company with the courage to even attempt.

They mostly dance around the edges and talk all day about 5S.

It would be great to read a detailed article about how you started and the process

you used to get where you are now.

 

You are practicing Kaizen/Lean in a much more efficient manner than the Japanese.

I am really surprised Makino doesn't hold you up as a poster child.

 

Kudos!

Thanks for the compliment Tim, I appreciate it.  It is funny how this process works.  My goal is to move forward and grow to a certain extent, but we have always had limited space and manpower so I have been forced from day one to find more efficient ways to do things to get more out of my machines and personnel.  When there is only 1200 square feet available there isn't room for 8 VMCs (unless you are newbeeee) so the obvious answer was the HMCs.  Then there is so much going on and so much back and forth by the employees that safeguards need to be put in place to prevent mishaps.  Nobody here is really assigned to a machine so running the shop is a group effort.  Two employees will be moving around keeping three machines running so standard processes, methods, and tooling are a must.  Employee A needs to be able to step in front of the machine employee B was running and seamlessly take over if they are off to lunch or taking a break.  Not sure it is the best way to do things but it works and we push some serious volume when firing on all cylinders.  It is challenging for the employees because it does seem to be a departure from the norm.  We are constantly refining and improving to make things better, easier, and more bulletproof.

[civiceg]

How are you getting files onto each machine? 

[Bob W.]

How are you getting files onto each machine? 

We load them via USB and store them on the machine's data server (for A51 HMCs).  The VMC doesn't have a data server so we run them from compact flash cards.  I never did network the machines because I didn't want them to be available via the internet.  I guess I'm a little paranoid that way.  Once we get a robust firewall I will be more open to that.  File management is something we could do better.  We do a pretty good job with the newer stuff, within the last two years, but some of the older files are a mess and need updating.  The repeat production projects are pretty nailed down though.

[civiceg]

I can see your problem now. It becomes almost non existent with having directories for each machine on a network and having your post directed to the respective folder. 

[Bob W.]

I can see your problem now. It becomes almost non existent with having directories for each machine on a network and having your post directed to the respective folder. 

I'm not sure how we would make that work.  When we do a project the file structure has the CAD and NC within the customer and part folder as follows:

 

Customer/ part/ Rev/ CAD/ NC

 

So if I want to find the op2 NC file for part ABC I can track it down in a few seconds on out server.  Once all of the posting and reposting is done and the part passes Vericut it goes to the machine via USB.  Once on the machine it gets run and proven and it resides permanently on the machine with a copy in the customer's folder.  The machine copy is the master and if the file gets deleted from the machine the NC in the directory will be re-run through Vericut and sent back to the machine and re-proven.  All files on the machine have been run and proven with ZERO exceptions.  Posting to a machine directory seems counterintuitive because I want the NC close to the CAD, CAM, and drawings for the part.  We haven't had issues with machine mix-ups but I am all for making it impossible.

[xiowei]

sdfghj

[bd41612]

We don't use a checking macro, but, we have a different file extension for each different machine type.  When the program is loaded it is easy to find the correct program.  It's not idiot proof, but if you use ".A51" for your horizontals and ".PS95" for your vertical it would be easy to see.  Set up the NC file extension in the control definition, and then set your editor to recognize that extension for you can have the editor display in the format you want (colors etc.).  Nothing wrong with the macro, it is a good idea.  On horizontals for probing, I always put a tram hole in each fixture, with a unique diameter and location, only a few thousandths are necessary for deviation, the probe the hole when the pallet comes in.  In the program would be an argument that would determine if the fixture was the correct one.  I've also used the probe to check for the proper work piece, verify the load on critical hard to load parts etc. and even to determine which program to run for parts that share a fixture.

[THEE THAINZ™]

Bob,

I tried to PM you but your in box was full. I'll give Kevin a try later.

      Thanks

          Tim

[Guest MTB Technical Services]

I'm not sure how we would make that work. When we do a project the file structure has the CAD and NC within the customer and part folder as follows:

 

Customer/ part/ Rev/ CAD/ NC

 

So if I want to find the op2 NC file for part ABC I can track it down in a few seconds on out server. Once all of the posting and reposting is done and the part passes Vericut it goes to the machine via USB. Once on the machine it gets run and proven and it resides permanently on the machine with a copy in the customer's folder. The machine copy is the master and if the file gets deleted from the machine the NC in the directory will be re-run through Vericut and sent back to the machine and re-proven. All files on the machine have been run and proven with ZERO exceptions. Posting to a machine directory seems counterintuitive because I want the NC close to the CAD, CAM, and drawings for the part. We haven't had issues with machine mix-ups but I am all for making it impossible.

Bob, take a good look at a PDM system.

You can keep all the files together in the structure you want and the benefit is that there are vaulted. I've done what you need to do with PDMWorks enterprise and it works great.

[Bob W.]

Bob,

I tried to PM you but your in box was full. I'll give Kevin a try later.

      Thanks

          Tim

Fixed my inbox.

[Matthew Hajicek - Singularity]

 

 

Customer/ part/ Rev/ CAD/ NC

 

Try Customer/ part/ Rev/ CAD/ NC/ Operation/ Machine/

 

or Customer/ part/ Rev/ CAD/ NC/ Op# - Operation name - Machine/

 

A hypothetical example:

 

01 - ROUGH BACK - HX400

01 - ROUGH BACK - HX500

02 - ROUGH FRONT - HX400

02 - ROUGH FRONT - HX500

03 - HEAT TREAT - OUTSOURCE

04 - FINISH FRONT - QUASER

05 - FINISH BACK - QUASER

 

Under each of those I would have the NC, the setup sheet, and screen grabs from verify and compare.

 

Also, since we have an HX300, two HX400's and an HX500 which are all similar but different, I have one post for all of them but it asks me when I post which machine I'm posting for.  Then it adds the machine name in the header and does whatever logic tweaks are needed for that machine.