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.