NC File Management

[Frank Caudillo]

Good morning everyone,

I wanted to get some different opinions on the best way to manage NC files in a medium sized production shop. The way we do it now is by grouping ALL of the relevant files for a part together (Mastercam file, NC files, Vericut files, Source files, etc.). While we've been able to keep things fairly organized, I feel that it has its limitations, especially when the operators need to grab the most up-to-date code for a particular job. 

Short of going with a full blown file management system (we've looked at Wintool to manage our tooling as well as their NC File Manager), what has worked, in your experience, to handle this just in the basic Windows Explorer environment?

I've been thinking of having ALL of the NC files in one main folder that is then sub-divided by machine to make it easier for the operators, while retaining our traditional organization on the back end for us programmers. Any input would be greatly appreciated. Thanks!

[RaiderX]

keeping source and nc files seperated helps with user permissions and lends itself to AS9100 and MBD requirements.

I must ask what you mean operators need to grab the most up to date code. is old rev. code available to them? if so big no-no.. IMHO

only latest greatest verified or proven files should be made available to general population in a shop.

we do it old school, but am currently in a one man show at this point. doesnt set up well for the future but management needs to drive that.   ??

[Frank Caudillo]

6 minutes ago, RaiderX said:

keeping source and nc files seperated helps with user permissions and lends itself to AS9100 and MBD requirements.

I must ask what you mean operators need to grab the most up to date code. is old rev. code available to them? if so big no-no.. IMHO

only latest greatest verified or proven files should be made available to general population in a shop.

we do it old school, but am currently in a one man show at this point. doesnt set up well for the future but management needs to drive that.   ??

In a way, yes, old-revision code has found its way into machines at some point. It drives me up the wall and we're going through some growing pains at the moment, which is why I would like to figure out the best practices to implement going forward.

If a program needs to be updated, it is usually backed up and deleted from the control. Changes are made by the programmers and then when the job needs to run again the operator needs to get the newest revision code. Our current file organization makes this process cumbersome and not all the operators know exactly where to go to get the correct files. This is what I want to streamline.

I agree with the permissions side of things. If all the NC files are in one area, the shop floor computers need only have access to that one folder and everything else is off limits. Part of the problem is also just driving home best practices to all the employees on the floor. Everyone has to be on-board or the whole system falls apart.

 

[Guest]

Cimco DNC-Max with NCBase can help with file control revisions and serving only the latest revisions of programs.....

Some kind of database server is really the best way to go....sure, you can use permissions and such, the time overhead to really keep things up to date can become onerous...

Even with a DB program there will still be some overhead required....

I am not a fan of program changes on the floor....too many times I have seen that get WAY out of control....

 

[Frank Caudillo]

26 minutes ago, JParis said:

Cimco DNC-Max with NCBase can help with file control revisions and serving only the latest revisions of programs.....

Some kind of database server is really the best way to go....sure, you can use permissions and such, the time overhead to really keep things up to date can become onerous...

Even with a DB program there will still be some overhead required....

I am not a fan of program changes on the floor....too many times I have seen that get WAY out of control....

 

I absolutely agree that a server-based solution is the way to go and it is our end goal, however budgeting restrictions are putting that on hold for now.

I don't like program changes being handled on the floor either, which is why we've also starting implementing a program change request protocol where the operators need to bring any issues to their immediate supervisor before any changes are made or before it comes to programming for support. Trust me, I would like to see all of this locked down and running much more smoothly. 

Like I said, short of going full on with a server-based manager I just wanted to get a feel of how other might be handling things under similar circumstances.

[Guest]

4 minutes ago, Frank Caudillo said:

Like I said, short of going full on with a server-based manager I just wanted to get a feel of how other might be handling things under similar circumstances.

What we do where I'm at is this....

 

We create a job# folder with a date....all related files are in this folder...

 

When we post files, we copy them to a "Sent" folder...this is done to make sure there are no existing files being overwritten....with new parts this should not happen, with existing parts it alerts us of existing programs....

 

If the program numbers do not exist already, we copy them to our "Production release" folder,,,,,,they are ready to go to the floor

If the program number already exist, we copy those "proven" files out and save then in the folder with the previous date as "Saved From Machine" folder, then we copy in the new versions....

 

All the paperwork is kept in the programming area and must be gotten from there, all files can only be sent to the machine from the programming area.....one pf the programmer will send them to the appropriate machine.

 

When program are doone and proven, they are saved into the backup folder in the machines memory.....

These programs are then backup up and placed into the "Production Release" folder

It takes some time every month to keep it up to date

 

 

[Newbeeee™]

My company ran a folder called customers/part number and issue/

Then everything within but it was a small company so it was controlled.

A customer of mine had cimco and i got the oportunity of a big project for them so spent some time on their site using it.

I can confirm it rocks.

[Ewood42]

We keep MCAM files separate from NC code. Our parts are all given a unique assembly # when they're drawn (all of the parts I program are our own), and are sorted according to that #, broken up into groups of 1000 #s. Then subfolders separating the type of operation (milling, turning, MT, drill, etc.), then another set of sub folders for the specific machine. My post adds a "M00 (CODE UNPROVEN)" line to the top of every file I post to flag it as a new file. New files are only sent when requested by the production supervisor. After a program is finished (and this is what I find trips up most people on revs) the files are saved back and compared to the original code from MCAM, I determine what changes stay, merge/edit the file, then overwrite the unproven code... then IMMEDIATELY remove the file from the control (that's the goal anyway...).

 

At my last shop the operators were pretty bad about keeping common program files in the machine, and when a rev came around, I would have new code ready to go, but was never told when the part was up to run so they'd end up making old rev parts. Made for some pretty fireworks when stock size changed with the rev...

[Frank Caudillo]

35 minutes ago, Newbeeee™ said:

My company ran a folder called customers/part number and issue/

Then everything within but it was a small company so it was controlled.

A customer of mine had cimco and i got the oportunity of a big project for them so spent some time on their site using it.

I can confirm it rocks.

I've heard good things about Cimco's products and NC Base sounds like it would really help us out. I just wish it could also handle tool management. We're leaning towards Wintool to handle our tooling and they also have a file management module which we would probably add as well (since I would hate to have two different databases to manage).

3 minutes ago, Ewood42 said:

We keep MCAM files separate from NC code. Our parts are all given a unique assembly # when they're drawn (all of the parts I program are our own), and are sorted according to that #, broken up into groups of 1000 #s. Then subfolders separating the type of operation (milling, turning, MT, drill, etc.), then another set of sub folders for the specific machine. My post adds a "M00 (CODE UNPROVEN)" line to the top of every file I post to flag it as a new file. New files are only sent when requested by the production supervisor. After a program is finished (and this is what I find trips up most people on revs) the files are saved back and compared to the original code from MCAM, I determine what changes stay, merge/edit the file, then overwrite the unproven code... then IMMEDIATELY remove the file from the control (that's the goal anyway...).

 

At my last shop the operators were pretty bad about keeping common program files in the machine, and when a rev came around, I would have new code ready to go, but was never told when the part was up to run so they'd end up making old rev parts. Made for some pretty fireworks when stock size changed with the rev...

That's actually a great idea that I may have to integrate into our posts to ensure the operators are aware that they're running new code. We've also worked hard to get our posts dialed so that there's no hand editing of code so that we can backup and compare what the operators ran and if any changes were made during production. Being able to cleanly compare and see the minute differences in files has saved A LOT of headaches.

[Goldorak]

we use Solidworks EPDM here, the nicest things is that you can implant an approbation process via a work flow , plus you can filter the extensions  rights to evrey users 

 

Programmers can see all the files 

operators can only see the latest NC and PDF files that went through the complete approuval process 

 

[Frank Caudillo]

4 minutes ago, Goldorak said:

we use Solidworks EPDM here, the nicest things is that you can implant an approbation process via a work flow , plus you can filter the extensions  rights to evrey users 

 

Programmers can see all the files 

operators can only see the latest NC and PDF files that went through the complete approuval process 

 

We also have Solidworks PDM, which is primarily used by our engineering team. As programmers we also have access and I wondered whether or not that might be a viable option to handle all of our manufacturing data. Might have to look into that a little more.

Do you have all of your Mastercam files in the vault, as well? I thought about even putting our Mastercam posts and machine/control definitions in there, but I worry about that being more trouble than it's worth.

[Guest]

10 minutes ago, Frank Caudillo said:

We also have Solidworks PDM, which is primarily used by our engineering team. As programmers we also have access and I wondered whether or not that might be a viable option to handle all of our manufacturing data. Might have to look into that a little more.

It is...

You might need some API development but in a past life around SW2006, we were using it then to manage all files related to programming

[Goldorak]

29 minutes ago, Frank Caudillo said:

We also have Solidworks PDM, which is primarily used by our engineering team. As programmers we also have access and I wondered whether or not that might be a viable option to handle all of our manufacturing data. Might have to look into that a little more.

Do you have all of your Mastercam files in the vault, as well? I thought about even putting our Mastercam posts and machine/control definitions in there, but I worry about that being more trouble than it's worth.

Post , machine and control def need to be outside of the PDM, but the MCAM files are in 

we manage files like 

C:PDM

>Client

>>part number

>>> inspection report, drawings, SW and MCAM files, setup sheets and NC files 

[Frank Caudillo]

36 minutes ago, JParis said:

It is...

You might need some API development but in a past life around SW2006, we were using it then to manage all files related to programming

 

13 minutes ago, Goldorak said:

Post , machine and control def need to be outside of the PDM, but the MCAM files are in 

we manage files like 

C:PDM

>Client

>>part number

>>> inspection report, drawings, SW and MCAM files, setup sheets and NC files 

This is great to know. It would definitely be best to use an existing software vs trying to implement something completely new. Thanks guys.

[cncdude5x]

in shop I worked at in NH over 13 years ago - we had all files on server and we used predator for upload/download.   Programming room would create a program and also would assign a program number with a shared excel sheet - so that each program had a unique fanuc style number.  That NC file would go in out folder and used as needed to whatever machine ( we had many different cnc ).  On the floor the boss might allow hand edit but they preferred they come back to programming.  They wanted a one way path of flow of programs.  anyway if updates got made they sent program back to separate in folder for programming room to review if it had a note on setup sheet. If it was legit we would post a new code and mark setup sheet  as NEW program .  Or same deal on revisions -  NEW program (unproven).  in our cam files we used level 99 to keep notes for each other as 3 of us may make edits updates or changes.  Worked pretty good.  Floor machinists are supposed to delete file after use.  we had small memory in older machines so that wasn't an issue.  But we all know what its like saving stuff - how many copies of pics do you have of the same picture in your computer or remote hard drive? .   I am afraid of losing it so I know I end up with multiple copies - that is an issue on file management.  too many copies and which one is the latest.  I have my post put out a date and time at the top of NC file plus a tool list and a manual entry with stock size and basic setup info .   I like that M00 idea on UNproven programs .  

[huskermcdoogle]

I have been toying with the idea of adding the M00 into the post for unproven files.  If I were to do it I would have to put it as a user question in the post, that way I could turn it off on request, the only time I need a M00 unproven is if I make an update or change but don't have a part to prove it out on.  99% of the time I am posting seconds before I go out on the floor to prove it out, so its unneeded at that time.  Right now I add the M00 in manually when putting code in the server folder.

[Ewood42]

When I write a program for a part, I never know for sure if I'm going to be the one to prove it out, hence the M00 unproven in all files. Our scheduling is a bit... lacking. Often times I'll go days without anything new to write, then the production manager will hand me 5 travelers at once and I'll have to leave new programs to the operators. I have one good setup guy, and one that's kinda sorta okay (for the loose tolerance stuff we do) but does a lot of questionable stuff. Like, "holy crap how did that tool not explode after the first part" questionable stuff.

[cncdude5x]

Setup procedure and time.   I teach CNC Machining after 30+ years in the trade - going back to manual G=Code.   I am a big supporter of treating all programs as unproven when it comes to setup.  We may have programs that we run all the time ( either left in the control or downloaded again) or brand new or have updates.  Personally I think the brand new ones should go to your ace setup people.  So you can get good feedback and fixes.  the other programs - revisions and re runs - everyone should be able to setup. I mean prove out that on this day its ready to make parts.   You can have other issues - wrong tools and tool lengths that were not documented - wrong work holding (I find photos help a lot and have a digital copy that I may build into a Word doc).  and the bad offsets - crash situation. 

I know every boss wants that spindle turning and even in my career might get frustrated with me as I did a dry run with every setup and would make fixes as I went along. In the end I would usually have a good first piece only using one part - a machined that wasn't crashed and running before the other setup guys that just did a load and go.  These CNC machines run so good you can get complacent and then wham. I know I'm preaching to the choir.  So I teach to put all the marbles in your side.  If you have graphics  - use it. If you can quickly shift the Z axis up 2.00" and run in air - do it.   If you program so that H line is at Z1.00 and do single block on first cut run you can visually see if your length offset is good without slamming into part that is programmed at Z.1 or doing that red/green button dance around the whole first piece. (That part will have dwell marks and not good anyway).  If I see it run without part and no issues then if I put stock in I should be able to let it go with rapid at 5% and a finger on the brake.

That's how I teach it.  #2 rule is don't crash the bosses expensive machine. Have control - use the display for coordinates - don't guess.

But back to M00 (Unproven).  I still like it and when I am done as setup guy I would update proven with current date and my initials.