Saving proven programs.

[crazy^millman]

Kind of off topic, but not really.

 

So I just took 588 programs out of the unproven folders today. I then compared them to the proven folder and only about 50 of them were saved. These are long term projects some with frozen planning. I am the bad guy and not understand after I have done this for the 5th time in the last 3 years. I have 1000's of files that have never been saved over that have run good parts. Every time I do this oh we will get better and never do. Then it is programming has not do their job and have not provided us books and are holding us up which is complete BS, but since I am here only 3 days a week it seems to only come up when I am not here. (For you Thad ) So I would think 1 week after a job is done should be plenty of time to save a program to the proven folder.

 

My question is should I really care if people are not doing their job?

 

Should I just say oh well what is the big deal?

 

What is the standard method are some of your shops?

[[email protected]]

quote:

---

What is the standard method are some of your shops?

---

I'm the ONLY one here with full access, so if it dont get done its my fault.

We have repeating jobs and I have files for those jobs and proven programs. The only time I change something on a proven program is when we upgrade tooling or I see where it can be sped up.

[Millertime]

If they are not doing their job just file merge new programmer then overwrite the existing then save as proven programmer.

[swanny]

production must suck!

[Millertime]

I dont have a problem with production as long as I'm not the slacker standing their pressing the green button 1000 times

[mayday]

every machine here is networked. Programmers resposibilty to save proven prg from machines and update tool sheets with changes. There is no oops forgot here. lots of our prg numbers are customer mandated. you better save em

[Jim at Gentex]

quote:

---

My question is should I really care if people are not doing their job?

---

Ron, you are obviously a man with a good work ethic, so yes, things like this will bother you.

 

If keeping track of proven programs prevents future re-writing, that saves time and money.

 

It's a balancing act between the time and money saved by managing the files properly vs. time and money spent by duplicating a program that's already been done.

 

In my experience, it's best to task one person with the responsibility of making it happen. That way when it doesn't get done, there is only one person you need to address about it instead of a whole group.

 

Yes, it can be frustrating at times.

[Nick Eaton]

Hi All,

Just thought i'd throw my two cents worth in.

The best system I have worked with was when I worked in a shoop which did not save "G code" files.

When the job was done the file was deleted from the control.

Next time the job was run a fresh posting was executed.

No problems with duplicate and "junk" files to confuse the issue.

The "latest and greatest" prog was always running

This requires:

1)Updating source file religiously, especially during prove out.

2)Clean posts.

Using (especially heavily editted) "g code" files means that if you want to move to a new machine, say from vertical to horizontal, or if you loose the "G code" file, you are back to square one on set up and prove out.

This system worked great. Only one out of 6 or 8 shops I have worked used this. The rest used (somtimes heavily editted) "g code" files......nothing but trouble......

Cheers

Nick

[Tyler Robertson]

I think some of this can be solved or improved with a good file management software.

 

A lot of companies just rely on a network & file server and peoples' organization to keep things running.

A proper file management software can track and analyze who generates files, who updates files, who last 'signed out' a file, any revisions to them, etc. and can also roll back files to previous versions.

 

This is by no means the best, but here's some common features: http://www.m-files.com/eng/features.asp

[specv]

When a job is complete here the operator has a tear-down checklist, Prints back in the print folder, gages back to inspection dept, tools back to the tool crib, programs downloaded. Its just part of tearing down a job and not really that difficult.

 

Then the engineering dept takes the downloaded programs and put them in a write-protected folder.

 

It works quite well, if they forget to download them the supervisor periodically checks the machines to make sure there are no programs in them that are not currently running.

[Joe788]

I have a separate folder that's only for proven G code programs. Within that folder are all of the sub folders labeled by customer. When the job is complete, the programs get downloaded into the correct foldes. The file name consists of the program numbers, part number, and date downloaded. The next time that job runs, the program is loaded back into the machine. When the job is completed, the previous G code file is moved into the "old" folder, and the new download with the current date is saved.

 

It's been working great for years.

[Guest]

In a previous life.

 

gcode were not saved at all, if changes were needed, they were approved and made, the operator returned the setup documentation with the made changes, the Mastercam file was updated to reflect the changes.

 

Never had to worry about out of date gcode files, the Mastercam file was the only file kept to date.

 

 

Never had different operators doing different things.

 

If it had to be posted to a different machine the changes were already incorporated.

 

IMO, managing multiple machines & gcode files is a nightmare waiting to happen.

[Guest SAIPEM]

I would recommend some kind of PDM solution like PDM Works Enterprise.

 

While it's primarily designed for SolidWorks, the vault structure and file viewers make it invaluable for maintaining version integrity of all associated files.

 

It is a GREAT piece of software.

[Matthew Hajicek - Singularity]

I have two copies of everything: one drive that everyone else has access to, and one that only I have access to. I use my local copy for my work, then sync it to the public copy when I'm done. If operators make a change, they save it back at the end of their run at the very latest. I use Beyond Compare to compare the two drives, which shows me what files were created, deleted, or altered. If I double-click on a file that was changed, it opens another window and shows me the differences. That way I can let the operators do what they want, and learn from their changes, but still have my original to reference or go back to until I decide which version (or which parts of both) to keep.

 

This two drive method has saved us quite a number of times when someone screws up when saving back, and saves a zero size file over the program. Then thinking it was saved, they delete the program from the machine. When I compare and find the zero size program I can restore it with a couple clicks.

[Newbeeee™]

Ron,

I assume there is a shop foreman/team leader/senior guy for each department or section.

IE turning charge hand, milling charge hand etc.

Get the boss to make it their responsibility to save proven progs.

You could drive it from the ISO/AS9100 side saying this *has* to be implemented because it is dictated by the QA system or customer requirements etc.

Yep, and only 1 prog in the control at a time (excluding subs of course).

[crazy^millman]

Well it seems I got my point across and now it is getting taken care of. I hate being the a$$hole, but when you have locked planning you can not repost programs for a part. Boeing, Lockheed, Spirit, or any of those catching you doing that and they will pull every bit of their work. I have them now coming back and asking about programs done 3 years ago so what does that tell you. I put it this way. If I get out there and dig a ditch and then you decide to cover it up I am going to take that personally. I take pride in my work and when someone can not take 2 minutes to do their job correctly it is unacceptable in my book.

 

Again I got my point across and now it is being taken care of. Just hate it had to become a point of contention today.

[Guest SAIPEM]

Ron,

 

I've been there.

Sometimes you have no other choice because its necessary to save management from itself.

 

The solution is to FORCE them into an electronic document control system like PDM Works.

 

The cost of PDM is nothing compared to the cost of losing the work. It's especially true in this economy.

 

What's nice about PDM Works is that you can go back and look at all previous versions at any time.

It makes audits and vendor compliance a breeze.

[SLJ]

We don't save any programs at the machine, period! Every time a job is setup, the G-code is downloaded from the working directory of the server. The operators have read only access. The programs are tied to the original customers engineering by sheet and rev level stamps as well as 1st article date in the header of the G-code file. The only way the programs get into the working directory is by posting from MasterCam into an Unproven directory, then when QA buys the part off the 1st article date is put into the header and it's transfered to the working directory by the programmers. That is, when we can get QA to fill out the database showing the date and machine they bought the part off. Got quite a few files waiting in the Unproven directory right now because of workload issues.

[Hitachi]

Our system is similar to what SLJ states, we post a source, verify in the machine, then the tape file on the server is moved to a qualified folder. We try to avoid having people make changes at the machine, if there is an issue to be fixed we do it on the spot then re-post and re-load the tape file.

The majority of people on the shop floor do not have access to source files and can only send tape files to the machine, they cannot be edited on the server. The system is not perfect but has some sense of organization.

 

Elco1971

X4 Mill L3 lathe L1 5X

SolidWorks 2007

AutoCad 2008

[Jim at Gentex]

I forgot to mention that we use PDM Works here too.

 

Makes file management very simple.

 

You can place your proven *.nci and *.nc files in the same folder as your *.mcx file. That way there is only one vault copy and everything stays current.

 

However, I think you still need that one person to be the 'keeper of the vault' in order to keep the system running smoothly.

[crazy^millman]

Well we have the one place and everything we do in programming is organized and kept right. It is when it leaves here that things go south quick. Our AS9100, DPD and MBD all start here so if there are flaws we would never pass an audit. We have 3 folders in which the system works. We have a MFG( for all manufacturing),Inspection and Original Model. I put a program in the unproven today and it was clean so guess it is working time will tell.