Previous | Contents | Index |
This section describes the tasks to perform after installing the
DAS for Siemens H1 Protocol, including editing the configuration file, setting the
device connection management support block parameter, configuring ports
and setting up plant floor equipment.
2.3.1 Editing the Configuration File
A configuration file, BCC$SYSDATA:DCM_H1_CONFIG.TEMPLATE, is supplied with the kit. The configuration file contains definitions for types, paths, and devices. A type record represents a Protocol Emulator (PE). A path record represents a Network Interface (NI). Copy the template file, edit this file to include site-specific information about types and paths, and execute the file.
The following sections give examples of the type, path, and device
records. See the BASEstar Classic Command Line Interface User's Guide for more information about creating
type, path, and device definitions.
2.3.1.1 Editing Type Records
The following example shows the type records created by the configuration file.
create type SH1_TYPE_S115U /manuf = SIEMENS /model = S115U- /proto = SH1 /descr = SH1_CPU_S115U create type SH1_TYPE_S135U /manuf = SIEMENS /model = S135U- /proto = SH1 /descr = SH1_CPU_S135U create type SH1_TYPE_S150U /manuf = SIEMENS /model = S150U- /proto = SH1 /descr = SH1_CPU_S150U create type SH1_TYPE_S155U /manuf = SIEMENS /model = S155U- /proto = SH1 /descr = SH1_CPU_S155U create type SH1_COMPATIBLE /manuf = UNKNOWN /model = H1_COMPATIBLE- /proto = SH1 /descr = "Any device supporting H1 protocol on Ethernet" |
The model field is used to tell the DAS the model of the Siemens programmable controller being configured. The DAS uses this field to determine what functions are not supported (for S155U programmable controllers), to check if start/stop options should be checked (for S135U programmable controllers) and to customize commands sent to the programmable controller. Be sure that the model field matches the model of the programmable controller being configured.
The
COMPATIBLE
type supports read and write functions only and can be used to
configure TI devices that support the Siemens H1 protocol.
2.3.1.2 Editing Path Records
The following example shows the path records created by the configuration file.
create path OSI_PATH /netn = VOTS /multidrop- /vaxport = "_OS:" /io_size = 1024 /retries = 0 /descr = OSI_PATH |
Table 2-3 lists the path parameters and indicates the value(s) that are allowed for each.
Parameter | Value(s) |
---|---|
VAXport 1 | _OS: |
Netname | VOTS |
Multidrop 2 | MULTIDROP |
Timeout 3 | 1-59 |
Retries 4 | |
IO Size 5 |
The line parameters in the path definition are not used by this DAS and
are ignored.
2.3.1.3 Editing Device Records
The following example shows the device records created by the configuration file.
create device S150_DEVICE /type = SH1_TYPE_S150U / path = OSI_PATH - /neta = "H1NET%080006010001:(R=READREAD,W=WRITWRIT)" |
The timeout on the device definition controls the time that BASEstar Classic device connection management allows for a device operation to complete. The value for the device timeout should be larger than the expected time of the longest device operation and also longer than the timeout on the path definition. To set the actual I/O timeout use the timeout on the path definition.
The timeout for a connect is controlled only by the CR Timeout on the OSI transport template definition. See Section 2.3.2 for information on setting OSI transport template parameters.
The device may be defined as "unsolicited". See Section 3.3.1 for information on unsolicited data collection.
When configuring the Siemens device, the network address qualifier must reflect the address of the programmable controller.
This network address must at least contain the OSI transport template name used by DECnet Plus and the Ethernet address of the device.
It has the following format:
osi_template_name%Ethernet_address: |
For example:
H1NET%080006000001: |
Note that the OSI transport template name and Ethernet address are separated by " % " and that the Ethernet address must be terminated by " : ".
Optionally, up to five Transport Service Access Points (TSAPs) may be added to define the read, write, unsolicited or command channels and to define the calling TSAP.
For example:
H1NET%080006000001:(R=READREAD) H1NET%080006000001:(U=UNSOLUNS) H1NET%080006000001:(R=READTSAP,W=WRITTSAP) H1NET%080006000001:(R=MY_TSAP1,W=MY_TSAP2,U=MY_TSAP3) |
These TSAPs must also be defined on the CP-535 card of the programmable controller. The names of the TSAPs must be up to 8 uppercase characters, left justified, blanks padded on the right. They are enclosed in parenthesis and separated by commas.
Temporary TSAPs are accessed when the command operation starts and are deaccessed when the operation is completed. Permanent TSAPs are accessed when the device is enabled (if the device is "unsolicited") or at the first requested operation (if the device not "unsolicited"). Permanent TSAPs are deaccessed when the device is disabled.
The unsolicited TSAP is always a permanent TSAP.
The command TSAP is always a temporary TSAP.
By default, the read TSAP and the write TSAP are permanent TSAPs. It is possible to make them temporary, by defining them with TR and TW instead of R and W.
For example:
H1NET%080006000001:(TR=TEMPREAD) H1NET%080006000001:(R=SIEMENSR,TW=SIEMENSW) H1NET%080006000001:(TR=TMP_READ,TW=TMP_WRIT) |
The network address is limited to 55 characters. If the OSI transport template length + ethernet address length + TSAP lengths is larger than 55 characters then additional TSAPs may be defined as described below:
Additional TSAPs may be defined using a system logical name. The name of this logical consists of the OSI transport template name used by DECnet Plus and the Ethernet address of the device, separated by a $ .
For example:
DEFINE/SYSTEM H1NET$080006000001 "(C=CDE_TSAP,O=OWN_TSAP)" |
For more information about maintaining type, path, and device definitions, refer to the BASEstar Classic Command Line Interface User's Guide.
Previous | Next | Contents | Index |