I work with software for SMT equipment, and I have been thinking about how machine alarm logs can be made more useful for troubleshooting.

A basic log normally includes the time, alarm code and machine status, but this is often not enough to understand an intermittent problem. For example, a placement error may also depend on the feeder position, nozzle, component package, vision result, retry count or the previous machine action.

The difficulty is deciding how much information to record. Too little data makes troubleshooting difficult, but recording everything creates a large log that operators may not want to read.

For people who work with automated equipment, what information do you find most useful in an alarm or event log?

My current list would be:

• Timestamp and alarm code
• Current program or job
• Machine operating state
• Feeder and nozzle identification
• Component reference and package
• Vision or inspection result
• Retry count
• The last few actions before the alarm

Would you add anything else, or remove some of these items?

 

I’d also add the board ID/panel position if that information is available.

 

I work with software for SMT equipment, and I have been thinking about how machine alarm logs can be made more useful for troubleshooting.

A basic log normally includes the time, alarm code and machine status, but this is often not enough to understand an intermittent problem. For example, a placement error may also depend on the feeder position, nozzle, component package, vision result, retry count or the previous machine action.

The difficulty is deciding how much information to record. Too little data makes troubleshooting difficult, but recording everything creates a large log that operators may not want to read.

For people who work with automated equipment, what information do you find most useful in an alarm or event log?

My current list would be:

• Timestamp and alarm code
• Current program or job
• Machine operating state
• Feeder and nozzle identification
• Component reference and package
• Vision or inspection result
• Retry count
• The last few actions before the alarm

Would you add anything else, or remove some of these items?

Since storage is cheap and you can't predict what is useful I would concentrate more on presentation of the data than on limiting what is logged. There is even an opportunity to have an AI log analysis that incorporates all of the data. Current models are very good at things like that.

So, log it all and work on how to present it to the operator—don't cut off the possibility that somewhere in the data is the answer.

 

If there is a "machine opertor", you also need enough information to identify them. An operator that is familiar with a machine may sense that something is wrong long before a failure or "out of spec" incident happens. AND some operators are impressed when you ask them "what do YOU think it was?" Consider that nobody else interacts with the machine 40 hours a week, every week. THAT is a lot of "familiearity time."

 

If the motions are servo controlled, a log of the position feedback sensor can show any trend changes. So a log of sensor deviation from an avareage would probably be useful. Also a count of machine cycles since the last adjustment, or other service, was done. And also , the cycle time.

 

Thanks, these are all useful points.

Board ID and panel position are obvious ones that I missed. If the same position keeps having a problem, that could narrow down the cause quite quickly.

I also like the idea of keeping the full raw log, but only showing a short and useful summary to the operator. Maintenance staff could then open the detailed event history when they need it. AI analysis could be useful here, although I would still want to keep the original events so its conclusion can be checked.

The operator point is a good one too. Maybe the system should allow a short note when the alarm happens, such as “unusual sound” or “feeder did not look normal.” Someone who runs the machine every day may notice something before the sensors do.

This has given me a better idea of how the log could be structured. Thanks.