Sensoray 2600 - Manual (Page 16)

Sensoray 2600 Programming Guide
12
Transactions
Chapter 5: Transactions
5.1 Overview
The majority of middleware functions are associated with gateway and comport transactions.
A comport transaction consists of sending to a MM a single Ethernet packet that contains a single comport command, and then
receiving and parsing the resulting Ethernet response packet.
A gateway transaction consists of sending to a MM a single Ethernet packet containing one or more IOM action commands, and
then receiving and parsing the resulting Ethernet response packet. Gateway transaction functions are designed to insulate the
application programmer from the cumbersome details of network programming and packet parsing when conversing with the IOM
gateway.
Aside from the programming simplifications, the gateway functions also help to optimize I/O system performance. By grouping
multiple IOM actions into a single transaction, your application will realize higher throughput and lower communication latency.
Because high throughput and low latency are hallmarks of the 2600 system, an extensive set of functions are provided for
controlling and scheduling IOM actions.
5.2 Gateway Transaction Process
Gateway transactions are implemented using a three-step process:
1. Begin a new transaction. Every transaction begins with a call to S26_SchedOpen() , which returns a handle to an empty
“transaction object.”
2. Schedule the actions. Once a transaction object has been obtained, zero or more IOM actions may be scheduled into the
transaction by means of the numerous action scheduling functions. For example, your application could call
S26_Sched2610_SetOutputs() to program the 48 digital I/Os on a model 2610 digital I/O module, and then it could call
S26_Sched2608_GetAins() to fetch the 16 digitized analog inputs from a model 2608 analog I/O module. It is important
to understand that these functions only schedule the actions for later execution; the actions are not actually executed when
the action scheduling functions are called. Note that it is not required for actions to be scheduled into a transaction; it is
permissible to simply create the transaction object without scheduling any actions into it.
3. Execute the transaction. After all desired actions have been scheduled, a call to S26_SchedExecute() causes all of the
scheduled actions to execute in a single transaction. Actions are executed in the same order they were scheduled. When
S26_SchedExecute() returns, the 48 digital I/Os will have switched to their new states, all digitized analog input data will
be stored in an application buffer and, since it is no longer needed, the transaction object is released. If no actions were
scheduled into the transaction then the transaction object is simply released; in this case, no communication with the MM
will take place.
Here is some sample code that illustrates this process. Note that error checking, which should always be performed in robust
applications, is not shown here:
u8 douts[6] = { 0x01, 0x23, 0x45, 0x67, 0x89, 0xAB }; // Desired DIO states.
double ains[16]; // Analog input values will be put here.
// Obtain a transaction object for MM number 0.
void *x = S26_SchedOpen( 0, 1 );
// Schedule some I/O operations into the transaction object.
S26_Sched2608_GetCalData( x, 1, 0 ); // Get 2608’s calibration info.
S26_Sched2608_GetAins( x, 1, ains, 0 ); // Get 2608’s analog input data.
S26_Sched2610_SetOutputs( x, 2, douts ); // Set 2610’s digital output states.
// Execute the transaction and release the transaction object.
S26_SchedExecute( x, 1000, 0 );