Communication Drivers

Writing a VTScada communication driver involves developing all components that are essential to the software including common driver widgets, error checking, and collection of statistics.

Because VTScada communication drivers are tags, their code must meet all of VTScada's requirements for a tag, as well as the requirements for a driver. The rules for all custom tag types are included elsewhere in the Programmer’s Guide. See: Custom Tag Types.

Older drivers often used two module files: one for the high level tasks that interfaced between the I/O tag and the VTSDriver module and one for the lower level tasks that were specific to the driver protocol. This model is obsolete. It is recommended that communication drivers be created within a single file.

Communication drivers tend to require large amounts of code. This is due to the complexity of the protocols developed for many hardware devices. The VTScada side of the equation is usually quite straight-forward, but it often happens that a large number of subroutines will be needed to handle all the details of a driver’s protocol.

This chapter describes the software design process as it applies to the creation of communication drivers in VTScada. It is organized as follows:

  • The fundamental concepts of how VTScada implements a communication driver are covered in the first few topics. If you have not written a driver before, start with Communication Driver Fundamentals.
  • The information you should gather before beginning to write code is listed in the topic, Communication Driver Design.
  • A step-by-step description of how to create a communication driver is provided, followed by detailed information on the mandatory and optional components of a driver. See: Writing a Communication Driver.
  • A template for a simple driver is presented as an example. All hardware-specific code has been removed from this example, leaving only the VTScada components. See: Communication Driver Template.
  • Information about tools for driver diagnostics and statistics gathering. See: Driver Diagnostic Tools.
  • A reference section is provided, starting at The VTSDriver API, and including:
    • The API of the built-in module, VTSDriver.
    • Details on how driver information is distributed through a networked application.
    • Rules for writing a driver.
  • Instructions for installing and using a driver are given at the end of this chapter. If you have been given the code for a new driver, and are simply looking for the steps to add it to your application, you can skip ahead to the section: Install a New Driver (Example: GE 9030 SNP Driver).

Experienced developers might (very rarely) create their own AddRead or DelRead modules as part of the driver. This might be done if certain address sets or blocks require handling other than the default. If the custom AddRead or DelRead modules return a 0 (or Invalid) then the custom driver's read queues and processing will be used. If the driver does not have a custom AddRead or DelRead, or if the custom modules return a 1, then the default handling will be used.

It is extremely rare for a driver to need a custom AddRead or DelRead.