12.6 Best Programming Practices |
In this chapter we aim to present hints, tips, and recommendations to help you get the best performance from your SP-ICE-3 Card.
Do not use polling to obtain dynamic data.Servicing requests from applications via the ClientAPI while list-execution is in progress entails an increased workload for the SP-ICE-3 Card's CPU, which then has less time available for its main task of calculating new items for the FIFO.
If this extra workload becomes excessive, it may result in FifoUnderflow errors being reported (see: 12.7 Exceptions and Errors), and list-execution being aborted.
Consequently, it is generally not a good idea to use any form of polling to obtain the current execution status, or to monitor the scanners, or to retrieve any other kind of dynamic data asynchronously from the card.
It is a particularly bad idea to use polling at high repetition rates.
 Important |
|---|
If polling is an absolute requirement for your application, RAYLASE GmbH strongly recommends that the polling interval should be at least 100ms (preferably longer), but even so cannot guarantee that FifoUnderflow will never occur. |
Use the Event Driven programming model whenever possible.Modern applications avoid the problems mentioned above by making use of the Event Driven programming model, which, in the case of the SP-ICE-3 Card, is directly supported by methods available in the SP-ICE-3 ClientLib API.
Such methods include amongst others:
See also: 12.6.1 Using a ListDone Callback.
The scanner monitoring facilities described in 14 Scanner Communications and Monitoring.
Most of the Sample Applications provided with the SP-ICE-3 Software Installation Package, and many of the code examples shown in this Manual, demonstrate use of the Event Driven programming model with the ClientAPI.