As was mentioned above, the scheduled command list is a data structure built from the specifications of the operator, which are input via a text file. This section discusses how this text file should be read in and processed.
A good general rule of thumb is to have each valid, non-comment, non-blank line translated into one node in the scheduled command list. Each field of the node to be described should be delineated by either spaces or tabs. Each section of text separated in this way should then be labeled and ordered.
For example:
;Period Address Command First_ Last_ Conv_ First_ Second_ ; Index Index Class Const Const 2 10 AIN EUR[1001] EUR[1005] L 0.0 0.1
The above three lines are an example already supported by the provided source code in the Technology Pack. This is a guideline only and you may need to make some substantial changes. The top two lines are comments, as any line starting with a semicolon is generally considered a comment. The top line is a comment that labels each section of text in the third line as a field. It is not necessary, it is only a comment to aid the operator in understanding the command list. Therefore, the first column 2 defines the Period field, the second column 10 defines the Address field, the third column AIN defines the Command field, and so forth.
The first five fields in the above example are to be read as follows: "once every 2 cycles (2 seconds typically) send the command 'AIN' to the 10th address and place the results in the ONSPEC table EUR (Engineering Units Real) starting with location 1001 and ending with location 1005". This assumes that the AIN command returns a block of at least five values.
The last three fields are optional. They define a conversion that is done before the values are sent to ONSPEC. The code for defining a conversion is in USERCONV.C. This portion is usually sent to the end user so they may make changes. In the above example this would multiply each value by 0.1 then add 0.0.
Often there are command list entries that the operator does not wish to occur periodically, but rather wants to be sent once at the outset and then never sent again. It is suggested that the I/O template should send all commands once when processing the configuration file, not wasting memory by creating a node to represent a command that need not be remembered. Sometimes these commands are called one-shot commands and a '0' must be entered at the Period field for each of them in the configuration file.
For example:
;Period Address Command First_ Last_ Conv_ First_ Second_ ; Index Index Class Const Const 0 10 SET
Similarly, commands that the operator wishes to be sent only when there is a change in ONSPEC's tables that should be reflected in the device (in other words, output commands) should be signified to the I/O template by the placement of the letter I in the Period field of the line.
Often there are command list entries that the operator does not wish to occur periodically, but rather wants to be sent once at the outset and then never sent again. It is suggested that the I/O template should send all commands once when processing the configuration file, not wasting memory by creating a node to represent a command that need not be remembered. Sometimes these commands are called one-shot commands and a '0' must be entered at the Period field for each of them in the configuration file.
For example:
;Period Address Command First_ Last_ Conv_ First_ Second_ ; Index Index Class Const Const I 10 AOUT EUR[1011] * L 0 2
Thus, if ONSPEC reported that EUR[1011] had changed in value, the I/O template would have to locate the node with the above information in it. It would then call output conversion routine and send the value to the device. The asterisk (*) indicates that only one table location is used. It is the same as putting an EUR[1011] in the Last_Index field.