I’ve recently heard this comparison used a number of times and the parallels are quite interesting. USB was designed to help standardize a dizzying array of connectors and configurations of supplementary devices that developed during the age of the Compaq vs IBM. It always took days to configure and establish communication between devices and then finally you could never get all the functionality that the device promised because of your PC’s specific configuration. USB revolutionized the personal computer by allowing for a standard interface for simple devices from hard-drives to keyboard lights, and best of all by offering a device drivers the functionality promised could be delivered. If the device broke, you bought a new one, plugged it in and it worked.
In typical sensors all you get is ON or OFF… we just hope and assume that the prox is working, until something doesn’t work properly. The part is seated but the sensor doesn’t fire or the operator can’t get their machine to cycle. This can sometimes be tricky to troubleshoot and usually causes unplanned interruptions in production while the maintenance teams attempt to replace the sensor. On some recent customer visits on the east coast, I have had a number of interesting conversations about the customer’s need to collect more information from their sensors; specifically questions like:
- How do I know the sensor is working?
- How do I predict sensor failure?
- How do I know something has changed in the sensor application?
- How do I get my sensor to provide adaptive feedback?
- How do I plan preventative maintenance?
- How can I increase the overall equipment throughput?
- How can I increase my process reliability?