Driver Sheet Info
In InduSoft Web Studio SCADA software, there are two types of driver sheets that users may utilize to configure communications: the standard driver sheet and the main driver sheet. Either of these sheets may be used to scale tag values right in the sheet. For example a 4-20mA signal that is read as a value from 0-4095 can be converted to a range that applies to engineering units such as temperature or pressure. Each type of driver sheet has its own unique advantages, which are discussed below. This is not an official Indusoft document, but is a compilation of information that I have found to be useful to customers over the years, The general purpose of the driver sheet is to associate Indusoft project tags with registers or memory locations in a remote device, such as a PLC or other type of controller, and provide a means of triggering Read or Write requests to implement the data exchange between the Indusoft project and the device.
Main Driver Sheet
The main driver sheet is not available for all drivers, but the majority of drivers support it. This driver sheet is optimal for an easy configuration, but may have less flexibility. Only one main driver sheet may be used, and it triggers every 600 milliseconds, though this can be changed if desired. With the main driver sheet, you can mix and match PLCs, controllers, and device memory types within the same worksheet. For example I/O bit level addresses can be combined with analog integer or real type addresses from one or more devices which use the same physical and logical protocol.
When you configure a Main driver sheet, you can configure multiple data types in the address column and you can configure multiple devices in the station column. The PLC devices typically require that a request for data specify an address range in a particular data block, and therefore for a particular data type, and the communications protocol generally imposes an overall size limit on the amount of data to be transmitted in an individual request/response. In order to conform to these requirements, the driver task breaks up all of the entries in the main driver sheet into Virtual Read Groups. Each virtual group is created by dividing the entries according to the device address (from the station field), then by dividing the entries for a particular device by data type (from the address field), and then by dividing those according to the block size limit of the protocol. If the entries for a particular data type comprise a range of addresses that is greater than the block size limit of the protocol will allow in one request, then one or more additional virtual groups must be created to accommodate them. You can view these virtual groups by right clicking on the driver icon on the taskbar during runtime and selecting Virtual Read Groups from the popup menu.
Standard Driver Sheet
The standard driver sheet has a flexible triggering configuration, and users are allowed 999 different standard driver sheets. Users can determine when each sheet reads or writes based upon triggers. For example if you have a remote, solar or battery powered project and you want to control a “burst” of communication at 2 am every morning, you can use a standard driver sheet to do this, enabling the sheet for a given time, then disabling it until you need to read or write values again. Alternatively, you may wish to have one or more of these sheets reading continuously and writing by exception (ie when a configured tag’s value changes in the tags database), which is the mode that the Main Driver Sheet always uses. Standard driver sheets also differ from main driver sheets in that the tags on one sheet must use the same memory type. Inputs cannot be mixed with holding registers, for example, in the MOTCP driver, and Integers from the N7 block cannot be mixed with Reals from the F8 block in ABTCP.
When you configure a Standard driver sheet, you will notice that there is only one Station field for the entire sheet. Additionally, you will notice that the Header field specifies the starting address within a particular data block from which each value in the Address column of the worksheet will be offset to specify an address within that block. This Header field therefore specifies one data type for the entire sheet. This is a manual implementation of the same constraints imposed on a Virtual Read Group in the Main driver sheet, and in fact, each Standard driver sheet represents a Read Group. The same limitations are imposed on these Read Groups for the block size limit of the protocol as well. The range defined by the highest and lowest addresses configured in the Standard driver sheet must conform to what is allowed in a single request for the specified data type. Additional Standard driver sheets may be required to avoid exceeding this limit on any one sheet.
It should be noted that the individual data types are not all of the same size, and therefore, a request for one data type may reference a wider range of addresses than another type within the logical protocol utilized by a particular driver. Additionally, some communication protocols have more overhead than others, in terms of the total bytes that can be sent or received in a request (Read Group or Virtual Read Group), so the allowed range of addresses for a given data type varies from one logical protocol (driver) to another. When configuring the Standard driver sheet for a given protocol, you will need to use something of a trial and error methodology to establish that limit for each of the data types you configure.
Block Size
If the Communications Settings dialog in IWS for a particular driver, such as MOTCP, allows the user to enter a block size, the value entered is limited to the maximum block size allowed by the logical protocol. The size of this entry may be further constrained by the maximum size of a request that the particular device is able to handle, if it is smaller than that imposed by the protocol. It is important to note that this entry is automatically used by the Main Driver Sheet in generating the Virtual Read Groups. The Standard Driver Sheet will generate a request for the range of register values defined by the highest and lowest addresses specified in the body of the worksheet. If this range violates the block size limit of the protocol (or the processing capacity of the device), an error will be generated when the request is sent.
Buffer Size
Each time the driver task in Indusoft generates a request, it allocates memory to store the request data, then forwards this data to the serial or Ethernet port associated with the driver from which it originates. It then de-allocates this transmit buffer memory so it is available to other tasks. Responses to the requests are likewise stored in a receive buffer, and the appropriate data is parsed from the buffer and written to the associated tags on the driver sheet. This receive buffer memory is also allocated and de-allocated as required. The Communications Settings dialog provides a field for configuring the size of both the Transmit Buffer and the Receive Buffer in some cases. In the majority of circumstances by far, it is not necessary to change the default values assigned to these fields, as they are generally large enough to accommodate requests and responses that are handled by the driver. There may be some few cases where memory availability is severe enough to require adjusting the values to enhance the performance of the overall project. In such a case, reducing these values may require a corresponding reduction in the configured block size value, or in the range of addresses configured on the standard driver sheets.
In some cases, the Indusoft driver may not be communicating directly with a communications port on a device, but may instead communicate with a software module, in which the driver makes function calls to that software’s API, and that software in turn sends and receives data to and from the physical device. Two such cases are the Omron driver, which communicates with the FINS gateway software, and the TWCAT driver, which communicates with the TwinCat Soft PLC libraries. In these cases, the buffer size will not apply at all, and any block size limitation would be imposed by the API itself. Additionally, the TWCAT driver uses controller tag names exclusively, and the OMRON and ABCIP drivers can be configured to use either block addressing or controller tag names in their later releases, so the rules for block size and address ranges (covered below) will not be the same in those modes.
Driver Sheet Triggers
Indusoft is designed to run under a Microsoft Windows operating system, and has similarities to other applications designed to run under Windows. Specifically, for this discussion, the various threads or tasks that make up the application have to share processor time with the tasks of any other currently executing applications, and the operating system is the ultimate arbiter of which task runs at a given time. Very generally speaking, each task has an associated Time Slice (interval in which it is allowed to run) and an associated Period (interval in which it must stay out of the pool of eligible tasks before it’s Time Slice can again be granted execution time by the operating system. In this way, processor time is shared by all tasks of all concurrently running Windows applications, usually at a rate of speed that makes each application appear to run seamlessly, ie without interruption. Programmers use specific guidelines to design their applications such that the assigned Period and Time Slice values optimize the overall execution of the tasks both within their own applications, and within the larger context of the operating system.
The driver task consists of two main operations, building the queue (stack of requests) and executing the queue. These operations are fairly independent. . Since the Main Driver Sheet is less complex than the standard driver sheet, we will look at how its triggers work first. As mentioned above, by default, its Read Trigger occurs every 600 ms. This does not mean, however, that it will scan every tag on the driver sheet every 600 ms..
The Main Driver Sheet will optimize the user entries according to the limitations mentioned above (number of devices, data types, request size) to create the lowest number of Virtual Read Groups that will be required to scan all configured tags. Subject to the period and time slice constraints, the Main Driver Sheet’s behavior is to read continuously and write by exception. When the Read Trigger occurs, all Virtual Read Groups for which no requests already exist in the queue will be added to the queue, and during the Driver task’s time slice, the execution of the queue is a continuous sending of these requests to the specified devices, always executing from the top of the stack. If the driver task is able to send all requests before another trigger occurs, then the driver task will have some idle time where no requests are sent during some part of one or more time slices, but this is quite rare and would be true only if very few tags were configured. Typically, there are always requests in the queue to be sent each time the driver task is granted its time slice, When a value changes on the Indusoft side for a tag that is configured in the MDS, a Write Item request to the associated device is immediately placed on the top of the queue for that specific tag, and has priority over any other requests already in the queue.
As mentioned previously, configuring a set of Standard Driver Sheets (each sheet a separate Read Group) is the manual equivalent of the automatic creation of virtual read groups done by the MDS. The triggering is more flexible on these sheets, however, and should be understood well in order to optimize the driver task for your needs if the Main Driver Sheet does not suffice. Assume you have completed all sheets needed to accommodate your various devices and data types and remain within the block size limits, and you wish to have all of these sheets scanned continuously in a repeating sequence. Additionally, you wish for any tag whose value changed on the Indusoft side to immediately generate a priority Write item, then you can place a 1 in the Enable Read when Idle field and a 1 in the Enable Write on Tag Change field, and the behavior will mimic that of the Main Driver Sheet, as described above, You may, however, wish to organize your sheets according to specific equipment groups or project screens, or you may have a large number of tags which affect the performance of the driver task, and you may want to read some of them more frequently than others. Instead of using the Enable Read When Idle field on those sheets, you may wish to use the Read Trigger field, such that each time the value of the tag configured in this field is changed, one Read request will be sent for that sheet. You can configure a tag to be toggled at a specific rate using the Scheduler, and place that tag in the Read Trigger field. Remember, each time a Read Trigger occurs, the request for this sheet is added to the queue if there is not one already there. Again, putting the tag BlinkFast in that field is not going to guarantee a request for this sheet will be sent every 200 ms. You should also be aware that the Write Trigger field on a Standard Driver Sheet has its own behavior. If you change the value of the tag configured in the Write Trigger field, a Write Group request will be immediately placed on the queue to send the values of every tag configured on that sheet to the specified device, Additionally, this request will write the value 0 to any registers between the highest and lowest addresses on the sheet for which no Indusoft tags are associated.
Address Ranges
If you create a read group for the ABTCP driver that has, for example, a tag associated with N7:0 and a tag associated with N7:5, and these are the only two tags on the sheet, the Read request for that sheet will specify all addresses from N7:0 to N7:5, as the highest and lowest addresses configured on the sheet will define the range of addresses requested. Additionally, if a a Write Trigger occurs, unlike the Enable Write on Tag Change setting, the values for the tags associated with N7:0 and N7:5 will be written to the PLC, and the value 0 will also be written for N7:1, N7:2, N7:3 and N7:4, as mentioned in the preceding paragraph.
Most users choose either to use the Main Driver Sheet exclusively and let it optimize the number of Read Groups (if the performance is good enough for their project) or to use the Standard Driver Sheets exclusively, so they control what tags are in each group, and the manner in which reads and writes are triggered for each sheet. It is also valid to use both types, according to the needs of your particular project. There are additional fields in the header portions of both types of driver sheets not covered here, and they are useful in your overall scheme, but the basics presented here should be useful in providing up-front knowledge that can help with your PLC configuration scheme, your Indusoft Communications configuration scheme and may perhaps affect the way you configure other tasks in the Indusoft project.