Data Acquisition (DAQ) and Control from Microstar Laboratories

Knowledge Base: Control

  • See the list of other topics for category Control

Q10010 Continuous operation through Windows crash

Tags: Help, DAP, DAPL, continuous process control, monitoring, Windows crash

Applies to: All DAP and DAPL versions

I have an online process that must be monitored 24-7-365. The Windows system crashes from time to time, and must be restarted. Can DAP processing sustain through a Windows reboot?

The short answer: yes, but you will have to do some work to accomplish this. And it isn't perfect.

Processing will stop in the event of power supply loss. Otherwise, processing can continue and data communication channels will reconnect after a host restart. Data transfer protocols on the host PCI and USB connections were not designed for fail-safe recovery, so the DAP connections cannot be more reliable than that. Any data that arrived at the host but weren't processed can be lost. The USB "hot plug" connections are designed for disconnecting and reconnecting, and are superior to PCI, but still not perfect.

Ordinarily, DAPcell software on the PC host will request a RESET operation from each DAP board at boot-up time, which is what most applications need, but not applications that are supposed to continue running. There is an undocumented configuration option to bypass the usual DAP board reset. Contact us and ask for technical support if you get serious about doing this.

To give you a rough idea of the level of risk, take for example a DAP 5000a, a common favorite for control processing. If this board is in a Windows XP system that crashes and reboots daily, over a period of 20 years you could expect about 50-50 odds that the DAPL system was dragged down with the host once and unable to reestablish the connections.

Small packet transfers that complete very quickly can reduce the exposure to data loss. A "pull" style of transferring supervisory data is particularly interesting: the DAP does not attempt to transfer any data until it receives a request, and it will rarely receive a request from a crashed host system. Hence, DAP operation continues unaffected.

The vast majority of applications need the DAP to be in a known clear state when the PC host boot up, so virtually all of the programming examples show this. Applications that need to reconnect to "live" DAP processing must first reestablish the communication pipe connections, then poll the DAP status through the DAPIO32 programming interface. The DAPL system and processing should be RESET and reloaded only when necessary.