Program and Machine monitoring

[patrickslaugh]

So I've had some issuses out in my shop with some parts being over cut ,and being crashed, and the operator says its the machine.
So the company i work for wants to put some sort of monitoring software/system on the machines to track what the machine is doing in comparision to the program.
For instance if the program is telling the machine to be at X2.0 Z2.0 but the machine is at X1.5 and Z 2.0 that would be something id like to know.
has anybody heard of any kind of monitoring software like that? 

[Guest]

I think the best bet would be verification software....not sure I've ever heard of that level of machine monitoring being available....

Maybe I'll learn something new 

[Colin Gilchrist]

Here is what I would recommend you do:

• Most controllers these days have a "Keystroke History", which records each key press on the control panel.
• You (or someone competent), is responsible for setting up the machine. This includes "tramming" in the Fixture, setting the Work Offset Location, Loading the (correct) Tools, Setting the Tool Length and Cutter Compensation values (cutter radius comp, or cutter diameter comp), and running the first part, through Inspection.
• So, you begin with a "known good setup", of machine, fixture, stock, and tools.
• The program will always do whatever you have told it to do.
• The only things that can get screwed up are these:

1. Loading the wrong tool
2. Having a Tool Setting issue (wrong holder, not tight, using a collet that slips, ect.)
3. Setting an incorrect Work Offset Value
4. Running the "wrong" part in a multi-part or pallet changing situation
5. Loading the part incorrectly for the OP/Fixture
6. Having an incorrect value for Cutter Comp (CRC or CDC)
7. Setting an incorrect TLC value (Tool Length Comp)

[patrickslaugh]

Colin is this something that is supported on Fanuc 15, and 18T controls?

[Colin Gilchrist]

The common thread here with "things that got screwed up", is that the Keystroke History will show you what the Operator did, and when they did it. So you can look and see "Oh, Billy here entered "0.5", when he should have been entering "0.05", and that is why the part is .450 too short!

I also recommend some kind of machine simulation program like Vericut, NCSimul, or ModuleWorks Machine Sim tied to your Mastercam Post. Each have pluses and minuses. No matter which solution you choose, someone will have to take the time to set up the software correctly. The question I always ask is: do you have more money or time available?

[patrickslaugh]

I know right J Paris I've been in the Machining Field for 20 plus years and have never heard of anything like it as well but the company i work for is wondering if it exsists so i've got to get out there and see if it does, besides i get paid by the hour lol. 

[Colin Gilchrist]

5 minutes ago, patrickslaugh said:

Colin is this something that is supported on Fanuc 15, and 18T controls?

Keystroke History? I believe so.

But the interface to the Fanuc Hardware (underneath), is governed by the PLC Ladder, which is setup by the Machine Tool Builder. So I honestly don't know the proper sequence to "dump" out the keystroke history for your machine. The steps should be listed in your Machine Manual.

I just helped one of our other Programmers do this on an Okuma P200M Control recently.

I do know you must have some type of "communications" available. (We use ProDNC.)

In general, you want to use the "DPRNT" statement, from within MDI or DATA I/O menus. Okuma, for example, uses either PUT or WRITE commands to initiate the download.

 

[Colin Gilchrist]

Has your company also considered adding Probing or Offline Tool Measurment capabilities?

Many of the newer Mill Turn machines also have "Crash Barrier" protection. This means if you are turning a part, and you want to ensure that the tool won't hit your fixture, or go where you don't want it to, the software allows you to draw a "boundary" in their 3D graphical software. You can control how "close" you want to allow the tool to get. So if your standoff is .100 for example, and the software detects that your tool is about to plunge "-5. inches" into the part, the Crash Barrier will throw the machine into an alarm state, and stop, preventing catastrophic failure. I don't know of this being available on a Fanuc 15 or 18 however...

[Ewood42]

One option (I've never actually convinced a shop to try this level of control by the programmer, but I've always wanted to)... just lock them out of the control, and use a probe to do in process checks and offset adjustments. Depending on how deep you're willing to go and experience with custom macro, you can do all sorts of crazy stuff with a spindle probe and writing directly to your offsets. Just make sure you prove everything out very thoroughly. 

At my first job as a programmer, I had problems with operators mis-loading parts then telling the foreman the program was bad. So I added some checks to the probe cycle results and a few additional measurements to be 100% sure the part was loaded correctly. If the part was not loaded exactly where it was supposed to be, the program would jump to the end and display a user alarm telling the operator what was wrong.

Also, (not sure what machine you're running) DMG Mori has remote monitoring software that will tell you what state the machine is in, a history of idle/run time, alarm history, and what lines of code are currently being executed. Combine that with keystroke history and you can keep a much closer eye on it. You can even set it up to send email or text alerts under certain conditions (idle for x minutes, specific alarms, etc.).

[Colin Gilchrist]

For most operators, besides "good mechanical practices" (not over torqueing, using the correct holder for the application, loading the tool in the correct spot, using a tool/holder with appropriate clearance, loading the part correctly, running the correct program/part/tool), the only things they usually have to do are: Set Location Zero Points (Work Offsets), Set Tool Offset Registers.

The only time where I've seen an issue that wasn't related to either a Tool Setting or a Zero Setting, is when there is something "foundationally" wrong. For example, if the fixture gets "bumped", and is now out of square, or is moved relative to the Zero point. Or, if a part got loaded wrong, or a clamp didn't get set properly.

Now, I've seen plenty of times where a Programmer made a crap program, and didn't take into account something like rigidity, or things like a "Non-interpolated Rapid Move". I've been bit by that one myself plenty of times (before I started using Vericut.) Or perhaps the tool or machining technique is just "bad" and that is causing a tool to pull out of the holder, or perhaps changing the radial immersion of the tool from a light radial cut, to "buried in the corner".

A program like Vericut can help you avoid most of these "programming" mistakes, but it can't do anything for someone typing in the wrong numbers into an offset register.

[Colin Gilchrist]

Another technique that I like to use is to use "G10" program lines in my NC Code, to "programmatically" set Work Offset Values, and Tool Offset Values. I can load in the G54, G55, G56, ect. offsets, and all the "known" tool lengths. We use Ball Locks on our sub-plates, so our fixtures generally repeat within about .0005. As long as the G10 values get properly updated in the Header of the NC File, it is basically impossible to screw up, and it takes a tedious task, and eliminates it completely.

Ewood,

I've done the programmatic updating of the Work Offsets, and Tool Length/Diameter settings, based on Probed values. In addition, after the hole is cut to final size, and the Probe has verified that the feature is "within tolerance", I call a sub program to "DPRNT" out the inspection data. I pass some local variables for Part #, and Feature #, and then use the Macro B machine variables for Date and Time. It makes for a "running inspection report", of each part being produced. Unfortunately we've only got this running on one part, and it was like pulling teeth to get our operators to accept what we were doing with the automation. They don't like it, but they grumble a lot less now that they realized it just means they can be even lazier than before.

One thing I really want to try, is an automated system that wirelessly adjusts fine boring tools.

https://www.rigibore.com/products/zenith

The Zenith system from Rigibore claims to do this, and I think it would be so slick if we could set or single point boring tools, a few thousandths undersized (on purpose), and have the probe measure and adjust the tool compensation.

[Colin Gilchrist]

Since Patrick is a new member, he has a daily posting limit. (Helps prevent Spamming of the forum.) He sent me the following message:

ive met my post limit on the site im not sure if im using it right.

but in this case the program has ran many parts that have had no issuses,and now on two seperate occasions the machine has done something to part one time it just up and started feeding into the case wall, and the latest it had up and started cutting a diameter big, and when the machinist turned the machine offthen back on started the program over, and finished the part with no oter mishaps 

It could be a drive board that is faulty. Or some kind of memory or circuitry problem. If that was the case, monitoring software wouldn't get you any benefit, unless it was a completely separate hardware architecture, that was reading all the signal outputs from the machine. (Encoder position)

I would just recommend updating the control unit itself. Either a complete machine rebuild, or just replace the whole machine. 

[Leon82]

Is there a magnet stuck to the control. I think years ago I ran into that problem with a FANUC control. I think it was the only explanation we had

[Guest]

The other question might be, is this program being dripfed?

Many moons ago I proved out a program, ran parts all good.....I uploaded the program to the storage location....2 days later, there was an order for 2 more...parts were alnost 30" long.......knowing I just did it 2 days previous, many of the tools were still set up....I sent the program to the machine....checked my height offsets and hit the button(should be easy, right?)

Program is humming along, all of s sudden I hear a 3/4 endmill get into a large cut and snap....

Long story short, it was milling a deep pocket and when it got the wall, it was supposed to move up on the Y, then further in the X....well it milled right through the side of the part.....after a bunch of research it was discovered that the RS232 communications cable was draped right over the fluorescent light and it was causing interference adding or dropping characters.......cable moved, lesson learned

Edited August 25, 2018 by Guest

[Colin Gilchrist]

24 minutes ago, JParis said:

The other question might be, is this program being dripfed?

Many moons ago I proved out a program, ran parts all good.....I uploaded the program to the storage location....2 days later, there was an order for 2 more...parts were alnost 30" long.......knowing I just did it 2 days previous, many of the tools were still set up....I sent the program to the machine....checked my height offsets and hit the button(should be easy, right?)

Program is humming along, all of s sudden I hear a 3/4 endmill get into a large cut and snap....

Long story short, it was milling a deep pocket and when it got the wall, it was supposed to move up on the Y, then further in the X....well it milled right through the side of the part.....after a bunch of research it was discovered that the RS232 communications cable was draped right over the fluorescent light and it was causing interference adding or dropping characters.......cable moved, lesson learned

I've dealt with similar issues, where the code stream would get garbled, and the machine would just take off to nowhere. For this reason I always try and specify the Predator Grizzly Cables. They are triple shielded. 

[So not a Guru]

18 hours ago, Leon82 said:

Is there a magnet stuck to the control

Years ago I had this bite us on a 0i control. The operator used a fairly large rare earth magnet to hold the work order against the control, which started doing some very random weird sh*t. After we removed the magnet (from the shop), the issues stopped.

[skyking01x]

We had the same kind of problem drip feeding programs to 3 machines.  We have a lot of aluminum heliarc welding in our shop and it was getting into RS232 links and you can imagine what happened, crash city!  My solution was to use fiber optic converters to send the RS232 back and forth, problem solved.  B&B Electronics makes the stuff I used.  www.bb-elec.com/‎

[Newbeeee™]

I got bit twice while I had my shop with randomness...

#1 was oimC and tool numbers had been reassigned, and the preselct on one toolchange had been forgotten to be updated.

So the machine would toolchange, start, preselect the next tool, machine away, go home, select the right tool, then toolchange, then continue.

I never realised this at the time as I would have corrected the preselect, and lucky I was working on a manual next to the machine. After about 20 parts, the machine went home, and just toolchanged and continued. Hell of a bang and I estopped it pretty quick.

The machine was a month old, and the tech then changed a threshold timer (opened it up) - he said it was right on the limit hence it worked 99% of the time...

 

#2 was a same model machine but different, and 2 years old. We had an issue where the side rack toolchanger got corrupted - out by one tool.

So say T10 was called in the prog, and the control said it was T10H10D10 in the spindle, but it was actually the previous tool in the spindle. All we could do was off/on and reset all the tools and this actually happened twice. We put it down to bad power, as occasionally the lights flickered and occasionally a phase would drop, but I don't know if this was the reason.

Then very soon after the second occurrence, the machine went home to toolchange and there was a heck of a bang as it overtravelled in rapid straight against its hardstop.

This happened twice in 2 days and the tech couldn't find anything wrong, it then happened again in front of him and nope, he still couldn't find anything wrong, so Fanuc were brought in.

Very quickly they diagnosed it. In the servo drive unit (the one big yellow spindlexyz unit), there's a big (80mm x 200?) hold up capacitor which had gone bad. So the machine was momentarily losing info going awol.

 

So, machines don't always do as they're told. But 99.9999999999999999999999999999999999999999999999999% of the time they do!

[Leon82]

8 hours ago, skyking01x said:

We had the same kind of problem drip feeding programs to 3 machines.  We have a lot of aluminum heliarc welding in our shop and it was getting into RS232 links and you can imagine what happened, crash city!  My solution was to use fiber optic converters to send the RS232 back and forth, problem solved.  B&B Electronics makes the stuff I used.  www.bb-elec.com/‎

We had one of the flex conduits come apart and expose about 3" of 3 phase supply wire and the wireless transmission began to go haywire.

 

One of the cranky old timers who happened to be an electrical engineer put some aluminum foil over it and it solved the problem.

 

Guy had some weird setups thought. Made very good setup sheets, but his process was terribly inefficient.

[pullo]

All these horror stories seem to be very related to the Fanuc control .  In the Heidenhain control , the program transfer when using the RS232 has a  BCC (Binary Check Code )  sent after every line , so as to eliminate transfer errors.  Would there be a Fanuc  parameter to  force something like that ?   There would then have to be a protocol for that of course in the  data transfer software (Cimco) ,  which I have not seen up to now, so I think I answered that question myself , or have I ?  NACK/ACK is definitely not that....

 

Gracjan

[Newbeeee™]

3 hours ago, pullo said:

All these horror stories seem to be very related to the Fanuc control .  In the Heidenhain control , the program transfer when using the RS232 has a  BCC (Binary Check Code )  sent after every line , so as to eliminate transfer errors.  Would there be a Fanuc  parameter to  force something like that ?   There would then have to be a protocol for that of course in the  data transfer software (Cimco) ,  which I have not seen up to now, so I think I answered that question myself , or have I ?  NACK/ACK is definitely not that....

 

Gracjan

But, and there's always a but....

There's more Fanucs out there than anything. Like cars. Why do I see Fords broken down? Because they make more...

[pullo]

You were asking for it  with that Ford ..... :))))))   Why is there less Mercedeses  ?

 

Gracjan

[patrickslaugh]

There are maganets stuck them holding the antenna for my y boxes for my DNC network, and all my machines have them, but as far as i can recall this is the only machine that has had the problem and it is the only machine that has a Fanuc 18-T control the rest are 15-T,and we are not drip feeding the programs.