Documenting shop floor edits made to CNC programs

[Brewster]

I am trying to find a better way to document changes made to programs on the shop floor. Ideally, these changes will be forwarded to the programmer so he can update his files. this way it can be posted to other machines with out re-inventing the wheel. Does anybody have a form to record these changes?

[Newbeeee™]

To be honest, I think I'd just create a word template (company header - form number, then list part number/issue/description/prog number) and leave the rest blank to let them fill it in with what they did.

Then run the new program through file compare with the old (or something like NCPlot as it is a great backplotter) to pick up the things they changed but couldn't be bothered to write on the form.

[Brewster]

Ok thanks. That might be the route to go then

[JerryBenoit]

We also require every program to be up-load to the DNC after each run at the machine, and then deleted at the control. Reason for this is to stop machinist from making edits and not carrying through in notifying us about the change. This would fall under process control. The DNC package we use is Cimco, which will compare the down loaded file to the server if there is any change it notifies us in programming. Each Job package that goes to the floor has a cover sheet that instructs the machinist the program he needs to run, tooling sheet, sketches, and any other documentation needed; wherefore each is control by version level. If a change is made, then it needs to be documented by the machinist, area supervisor, and a member of programming on the hard copy that is in the package. Please bear in mind our parts are high dollar and months go into one component. If there was a change, we then scan the hard copy. This is kept for reference with who made the changes and update the package, and if the change was to be carried to other machines doing similar work. Therefore, that is documented and a compare print out a compare of the program so the machinist will be able to know where the changes came from when he is running proven code.

With all this said, before you start making changes to how you document thing. Get a few people that you trust together and see what they think. Also, get the approval of those above you in any changes that you would like. Generally, people do not like change and they start to tear at those who do make changes. Be patient with everyone and make to changes small so they can digest them. When you back a year or two you will find those that resisted the changes are going to be the ones that complain the most when you do not follow the changes you made.

 

Jerry

[crazy^millman]

Jerry, Well said and good outline of an effective way to do this.

[Brewster]

Jerry, Well said and good outline of an effective way to do this.

 

I agree. Thanks Jerry

[Watcher]

CIMCO NC-Base.

 

This tool can track everything concerning NC-Programs.

 

Everything.

[Matthew Hajicek - Singularity]

There's a great little program called Beyond Compare that's great for comparing file versions. It'll pull up the old and new versions of the NC file, align them as needed, and highlight all the differences. You can text edit right in the comparison and copy lines from one side to the other, and it also does directory comparison and synchronization. It's been one of my must have tools for several years now.

[Newbeeee™]

^^^Thanks Matt - It looks good so I just bought it. Cheap as chips