Rockwell Automation 6008-SI IBM PC I/O SCNNR 6008-SI - Manual (Page 93)

Chapter 8
Block Transfer
8-3
qbt_data
data area, an array of 64 words. For a write BT, you must place the data in
this area before calling a library routine to queue the BT; and if the length
of data is zero you must be sure to have enough data for the module.
Programmer Alert
Your program can get itself into trouble by misusing packets. Here are the
pitfalls:
Improper declaration of packets: It would be natural for a function to
declare a packet as follows:
QBT packet; /* possibly unsafe */
But this declares the packet on the stack, which may not produce the
desired results. Suppose your program has a declaration like the above
in a function, say x, and calls a library routine to queue a BT. If x then
returns to its calling function, say c, then x (which contains the packet
declaration) is no longer active by the time the scanner comes back with
the confirmation. The interrupt handler still has a record of the absolute
core location of your packet, but that core location is now in use by
some other function’s stack. The library routines can detect some of
these situations, but not all. The running count of occurrences detected
is stored in global variable g_pkt_err.
You have two defenses against this problem. The way requiring less
thought, and providing absolute safety, is simply to declare all QBT
packets static. This ensures that the physical data locations are not used
by any other variables during execution, but may increase program size
unnecessarily. The other technique is to take note of the structure of
your program and locate packet declarations so that each packet is
declared in a function that definitely does not return to its caller before
the scanner has returned a completion status.
Improper reuse of pointers: A second potential problem is closely
related to the preceding one. If your program decides that the scanner
has not responded in a reasonable time, the program is generally free to
use the packet for a different BT. But suppose that your program simply
didn’t wait long enough. Then the confirmation of the first request
could come through and wipe out the information in the second request,
which is waiting for a confirmation from the scanner. Again, the library
routines catch some but not all of these situations, and count up the ones
they do catch in g_pkt_err. Generally, your program should not reuse a
packet that contains a status of SC_PENDING unless absolutely sure
that the scanner is not responding to that command.