The diagnostic process continues by following a predetermined troubleshooting tree. The results are then reported to the operation, along with the test queries and evidence of a failure in the log. The network might be down, axis controller #3 may have lost power to the motor or the controller, and so on. The decision tree can be simple or complex, and as long as logged faults are encountered, continuous improvement is obtained. Transaction logging is used in reservation systems and other high-reliability applications to deal specifically with power loss. It is a time-proven technique.
Nonvolatile memory such as flash physically wears out with repeated write operations and is typically too slow to update. Disk drives must seek sectors, which takes from 5-10 ms and always operates by transferring data blocks when only 4 bytes might need to be changed. Also, sending data to the drive does not mean it is actually being safely stored in the write cache on the drive’s platter. It may temporarily be stored in the write cache on the drive, waiting to be written to the hard disk drive when the fault occurs.
Data items are rarely written onto the disk drive’s platters in sequential order. Instead, the drive optimizes the data write operation based on what is physically nearest to the disk drive’s current position of the head, not on a first come, first served basis. This limits the number of non-volatile write operations to about 100 per second. Most control loops are orders of magnitude faster than that. The highest speed nvSRAM available today can write 40 million, 32 bit words per second. This is at least 1,000 times faster than the fasted control loop time requirements.
Flash drives work like disk drives and transfer whole sector of 512 bytes each, even if only 4 bytes need to be written. It takes roughly 500 microseconds to perform the write operation, which results in an acceptable maximum control loop time of 2,000 loops per second. However, most applications will wear out the memory after 10,000 writes. Most control applications will reach this point after 5 seconds of operation. Obviously this is unacceptable.
Reliability is the primary reason battery-backed SRAM is not the best option. The cost of a robust solution for robotics can easily be $10k per system. This high cost makes battery solution penny wise and pound foolish. Battery backup is unreliable because of a number of factors, including:
1. Contacts: Batteries have mechanical contacts that can corrode and fail. The MTBF of mechanical contacts is orders of magnitude shorter than nvSRAM solution. In addition, vibration can degrade contacts, further reducing reliability.
2. Liquid electrolytes: Batteries work by ionic reaction, which means ions exist in liquid solutions. At high temperatures gas can be produced, resulting in electrolyte leakage failure and corrosion of the surrounding
environment possible compromising machine safety..
3. Seals: Lithium batteries have nonconduction seals between the cell’s positive and negative cases. These seals degrade with time and temperature and can fail many times before the battery’s lifetime-charge capacity is exhausted.
4. Wear: Batteries wear-out over time.
5. Periodic maintenance: Because batteries wear-out over time, they must be replaced periodically. This costs time and money.
→
|
