Interrupt Communications Method
The interrupt method overall is the most efficient of the three methods. The software
communications method uses a hardware interrupt to notify the application that a response or
unsolicited data is available. This allows for greater efficiency and response time, since the drivers
do not have to “poll” the buffers for the data. Additionally, the interrupt method allows for data
record caching.
The interrupt method uses bus level interrupts (IRQ) from the controller to notify the PC that data
is available. This requires that the Controller be configured with a valid interrupt line. For DMC-
1600 controllers the interrupt is configured automatically. Firmware version 2.0m (and greater) is
required for the “communications interrupt” method to be available. For complete information on
the different communications methods, select the
More Info
button on the Communications
parameters dialog box.
Data Record Cache Depth
With the “interrupt communications” method enabled, the driver will cache data records for
retrieval via
. This makes it possible to not 'miss' any data records, even if the
DR command has been configured to refresh the data record every two milliseconds. For example,
a program could poll at a relatively long frequency (say every 50 milliseconds), and not miss any
data. The cache depth can be set when the interrupt communication method is selected. The data
record cache functions like a FIFO. Reading the data records removes them from the cache. If the
cache is full and a new data record arrives from the controller, the new data record is placed in the
cache and the oldest data record in the cache is discarded. If multiple handles to a controller are
open, the first handle to retrieve the data record(s) will possess the only copy available. When an
application needs only the most recent data record available, the cache depth should be set to 1.
Stall Thread and Delay Thread Methods
Users can also choose between "Delay" and "Stall" methods. These methods affect how the
software "waits" for a response from the controller when a command is sent. If a controller is
configured with the "Delay" method, the thread waiting for a command response gives up its time
slice, allowing other processes running on the operating system to proceed. This method can
slow communication, but results in negligible CPU utilization. The second method, the
"Stall" method, uses the opposite strategy. The thread that performs I/O with the con
maintains ownership of the CPU and polls the controller until a response is received. This
approach is essentially the same method employed in previous versions (< V7) of the Galil
communication DLLs and drivers. While the "Stall" method does not have to wait for its thread to
become eligible for execution, it does result in
troller
while communicating with
the controller.
Data Record Refresh Rate
Under the
PCI Bus Parameters
tab, the rate at which the data record is sent to the software
drivers can be configured. The period between refreshes can be set from 2 - 256 ms (assuming the
standard TM setting of 1000 is set). The Galil communications .DLL will use this value to send
the appropriate DR command to the controller when a communications session is opened.
Additionally, for DMC-1700 users, the dialog box (shown in Fig 4.6) allows the user to select
between two Data Record Access methods: DMA or Secondary FIFO.
DMC-1600
Chapter 4 - Software Tools and Communications
•
47
