Quality assurance for CNC programs - Help needed.

Eric Stevens wrote: ."..by reasons of a very simple defect in a very complex series of parameter based programs written over a period of years..."

Really. I mean your kidding right? I would compare that to stacking playing cards up way too high then blaming the resulting collapse on a single card.

It's always the "simple defect". That's why one tries to keep the code, well... simple.

That said, one could write yet more macros to check the existing macros for accuracy...

-- Bill (Trying to reduce the macros and variables in my life...)

Eric Stevens wrote in news: snipped-for-privacy@4ax.com:

I doubt you will find anything specific to CNC, however, CNC macro programming is basically the same as any other programming. It really doesn't matter what type of programming you are doing, the same basic rules and methodology still apply, the only real difference, in the grand scheme of things, is the syntax, command names and definitions. And one rule is to always check operator/user input for out of range variables. Sadly, this rule is rarely followed in CNC programming because of the extra time it takes to program, and depending on the macro's purpose. In a job shop where you may have a macro for boring, but may be working on a

I know what you mean but this is beyond that.

The major demand for the machine is a range of cast bodies which can be anything from C.I. to 316. They come in 4 sizes. Each size has a range of simple variations which mean there is about 28 of each. Much of the machining is hand coded (about 7000 lines in all) but some is so complex that it has been machine coded. I don't know how many lines but more than 30,000. What the machine actually does and how it does it is determined by feeding the program a long list of parameters which guide its weaving through the maze of options.

Somewhere along the line someone pressed the RESET key at the exactly the wrong moment. On all but that machine that would not have mattered but on that one machine it cleared a number of # variables which would not have been touched on the other machines in the same circumstances. This only mattered on the one 20 line program.

Until after the accident nobody knew that the machines were configured slightly differently and would behave differently. In another programming environment this might have been discovered, recorded and perhaps the machine would have been reconfigured. But it seems to me that the general CNC environment seems oblivious to the need to guard against this kind of problem which is why I am asking if anyone knows of any procedures for properly documenting the programming environment.

I can't go into more details but it killed an entirely innocent man. This is not a joke which is why I am asking for help.

Eric Stevens

Sorry to hear about the machinist. Sucks when you catch a workpiece. Beyond the manual that comes with a machine, there isn't really much in the way of what you're looking for. Who set the machines up in a different manner?

Later,

Charlie

Eric, The CE safety standard is what you are looking for. Look over mode 4.

Two different makes of machines, both using FANUC controls. Two different suppliers, with both suppliers thinking their way of doing it is standard.

Eric Stevens

I do have some CE documents. Could you tell me which one you have in mind?

Eric Stevens

I'll look and give you a specific reference. You have answered the question at hand in another part of this thread. You can clamp spindle RPM on a tool by tool or global basis on any Fanuc later that an 11M. Unless the tool in question was being moved from one location to another or the code reinitialized the tool changer, preventing this sort of an accident is as easy as water flowing down hill.

I'll let you draw the appropriate inferences and conclusions from here..........

Eric Stevens wrote in news: snipped-for-privacy@4ax.com:

Unfortunately, most controls leave 90% of everything up to the machine tool builder. This will partially fall back on the MTB and control manufacturer if the control was configured to allow this type of event to happen without an alarm or warning somewhere. Hitting reset should stop all motion, program execution, etc, but should not make it drop program data in transfer, especially without a transfer alarm of some type.

It is extremely unfortunate that a life was lost because of this.

We had a machine where a firmware/software bug allowed the spindle to continue operating at speed even with an E-stop pressed. The other drives shut down as designed, but the spindle did not and the door was allowed to be opened. This was corrected by the MTB and the Control mfg. The chances that the particular set of exacting circumstances and sequences that caused this bug to rear it's head were probably along the lines of 1 in 10,000,000, but it DID happen. Fortunately, nobody was hurt.

The probability is that you will need in-house specifications on how the control is to be configured prior to purchase.

That applies in most cases but the tool concerned was that of an empty pot used by the program to allow manually loaded tools. No single speed limit was suitable for all. The speed for the particular tool was loaded in the program into a parameter the programmer did not realise could be cleared by the RESET key. (It wasn't cleared on their other Fanuc CNC machines in which #1003 was set differently).

Eric Stevens

OOPS! #6001

Eric Stevens

I see. It still would have been possible to limit the RPM of that tool to say 300 or something less hazardous but only if you used it in the same position each time. No matter.

I have an offline solution that addresses this sort of thing. It translates your parametric macro's to NC code and you can check and run that without worry.

Thanks for the offer but that particular problem has already been attended to. I'm more concerned about establishing proper procedures so that kind of thing cannot happen again. Hence my enquiries about codes, standards etc.

Eric Stevens

I'll poke through my CE/NMTBA stuff and see what's there.

I would appreciate that.

Eric Stevens

Was the guy fully trained ERIC

I stress that this is only a rumor but a friend of mine knows the "trained" operator of this machine (still alive). I was told that he was sick that day & his trainee was allowed to run the machine. I hope the wrong people or systems aren't getting the blame here. Perhaps the trainee was over confident & managements lack of knowledge of cnc lead to him been allowed to use it. Probably an accident pure & simple. Please read the first line of your first post. (Eric's post that is.)

Kev

OK but I'm not part of the management. All I know about CNC is what I've picked up by osmosis. However, since 1961 I have been writing computer programs at all levels in Fortran, PLAN, Assembler, Basic (several), Pascal, C, C+ etc and in this particular case I know what I don't know. Someone with no formal training and without this experience might not know what they were getting into.

Eric Stevens

I understand that a mid program restart may have been involved. If this was the case & the program was a large complex macro I would be very nervous about doing this & I've had years of experience. Add to this a machine which carries counterweighted boring bars, doors open (which means the interlocks may have been bypassed) & an inexperienced operator, it sounds like everything was against you. I can't see how a code of practice for the programs or machine control configurations could help. They are all to many & varied & easily reconfigurable as you pointed out by machine parameter changes. Even if you set them all up to behave the way you want (according to your code of practice) it would only take a smart operator to change a parameter & then all your programs behave differently. Also a machine repair could involve reloading default parameters. In this situation the program code or machine configuration may have been partially to blame. It can never be perfect. Even NASA managed to miss an entire planet because someone programmed in imperial instead of metric. This is why these machines have guards, door interlocks & experienced operators. Even if all the above problems were addressed you could still,quite easily have an experienced operator remove two tools from the machine for tip changes & then put them back the wrong way around. If one was a spot drill & the other your big boring bar, then you could have the same accident. Program code of practice wouldn't help here but machine guards would. 2.5mm of panel steel could mean the difference between an injured man & a dead one.

Kev