6.1.4 Device Driver Procedures

The software basically knows two types of procedures: A 'PUT' procedure sends one or more parameters to the physical device after coding them into the format the physical device expects. A 'GET' procedure sends a request to the device, reads the reply and decodes one or more variable values from the data received. A procure never can be both, 'PUT' and 'GET' at the same time.

As mentioned in chapter 'Device Drivers' , all procedures of the driver are called on a regular basis. The procedures are called in the same sequence as they appear in the driver definition file. Procedures which actually have no work to do, are skipped by the driver.

A procedure links to one or more variables, the 'WATCH' statement in the driver definition file defines the variables a procedure shall link to. Thereby, a procedure may link to multiple variables but each variable may be 'watched' at maximum by one 'GET' and one 'PUT' procedure. If now one of the 'watched' variables receives a new value an operator wants to set at the device, the variable marks the 'PUT' procedure which it is linked to as 'dirty'. With the next cycle, the driver recognizes this flag and does not skip the procedure this time.

Hence, setting the parameter at the physical device by the procedure happens not synchronously when the parameter message arrives. The physical equipment setting is done decoupled from the arrival of the message, but synchronized with the polling activities the device driver does on a regular basis. This ensures, that the device driver always finishes any pending polling command before it sets a parameter at the device.

While the method of a dirty flag for a 'PUT' procedure is a quite simple rule to determine which procedure shall be run and which shall be skipped, things are a little bit more complicated with 'GET' procedures. There also is a 'WATCH' statement for 'GET' procedures, but the dirty flag is managed in a more sophisticated way here:

1. When the program starts, all 'GET' procedures wake up with the dirty flag set. The driver has to inquire all parameters from the device when it starts.
2. The same applies after a communication failure. If the device didn't answer for some time, an operator might have replaced a faulty device against a new one which will have different settings. The device driver marks all 'GET' procedures as dirty if a communication failure occurs.
3. Each variable contains a timer, programmed for CYCLE interval, the driver description file individually defines for each variable. If the timer expires, the 'GET' procedure watching this variable is marked dirty. This way, each variable is read on a regular basis using an individual polling cycle.
4. Once a variable has been written to a device in a 'PUT' procedure, the 'GET' procedure watching this variable is marked dirty. This enforces a variable to be read back after it has been written to the physical device. This specially is important with variables having a quite long polling cycle programmed. A read back of the parameter eventually would happen minutes later.