Built-in Features


This section of the document has information on the built-in features of the SECS Equipment software in regards to the SEMI E5 and GEM standards.  Here the presentation is aimed at the equipment software developer.  This information is also presented in the template SECS/GEM Reference Document which is intended for the host side SECS/GEM user.  Hume Integration Software provides the template SECS/GEM Reference Document to Datahub SDK customers for customization and redistribution in order to meet the strict documentation requirements of SECS and GEM.
 

Built-In SECS Equipment Variables

These variable definitions are specified by the SEMI standards, and are created by the SECS Server when the connection type is set.  Once the definitions exist, you are able to customize the values, the varIDs, or value methods.  Even if a definition is not appropriate for your equipment, you should not delete it, since its existence is called out by the standards. 

The Owner column shows at a glance which variable values the server manages for you, and which ones your application needs to manage. The following letter symbols are used as a shorthand indication:

S
The SECS server manages the value and your application does not need to be concerned with it.
A
Your application is responsible for managing the value and keeping the SECS server informed of value changes either by calling the set method, or by providing a callback for the SECS server to evaluate when the current value is needed.  Not all variables in this category are relevant to your application. For example, if you do not implement Limits Monitoring, then you can ignore variables that are provided for this feature.
H
This variable is a settable parameter (class ECV) whose value can be changed to affect the SECS server behavior. Usually you leave these values alone and let the host optionally change them. Per the requirements of the standards, the value of settable parameters are made persistent - they are saved in a file and restored from the previous session. If your application changes or sets a parameter value during initialization, then you may be replacing a saved value that the host expects to be restored.

 
Default varID Variable Name Owner Description Class Value TSN Type
200 AlarmsEnabled S The list of alarm ALIDs enabled for reporting via S5. The value is completely managed by the SECS server. SV L
201 AlarmID S The current alarm identifier ALID at the setting or clearing of an alarm irrespective of reporting.  The value is completely managed by the SECS server. DVVAL U4
202 AlarmsSet S The list of alarm ALIDs in the set state, irrespective of reporting. The value is completely managed by the SECS server. SV L
220 AnnotateEventReports H If true, event reports are sent in the annotated format of S6F13 instead of S6F11.  The default value is true. ECV TF
250 Clock S The value of the equipment's clock.  This value is completely managed by the SECS server.  If a host sets the clock using S2F31, the host's desired setting is saved as an offset from the system time for the SECS interface instance and the system time is not changed.  The use of an NTP time server is far more accurate than using SECS to manage the system clock, so it is strongly recommended. SV A:16
300 ControlMode S 0=Local, 1=Remote. This variable value is managed by the SECS server based on your property settings that set whether your online control mode is Local or Remote. SV U1
301 ControlState S 1=off-line/eq off-line 2=off/seek on 3=off/host off 4=on/local 5=on/remote  The ControlState variable value is managed by the SECS server based on your property settings. SV U1
304
DataSetName
S
The Process Program ID or Data Set name in the latest Stream 13 large file upload.
SV
A

306

DataSetSendResetS13F9

H
Controls sending of the Data Set reset message, S13F9 during initialization.  0=do not send, 1=send, 2=send only after receiving S13F9 from the host.  The default value is 2 to maximize compatibility with various host implementations.  The value of this variable only matters if Stream 13 message types have been enabled for use by the equipment application.

ECV

U1

307

DataSetSendVerifyS7F29

H
According to GEM, the equipment should send S7F29 after downloading a large Process Program in order to verify the length of the downloaded data.  This settable parameter is used to disable the length verification if the host does not support it.  The default value is 1, meaning the message is sent and the Process Program is not used unless the length is correct.

ECV

TF

308

DataSetTimeoutSecs

H
A timeout value in seconds for expecting next messages during Stream 13 data set transfer.  The settable range is 10-600 with 60 being the default.  If the timeout occurs, the UploadTimeout event is posted; however, the transfer can still succeed if the host continues.  The transfer is marked as having a timeout, and it no longer prevents a new transfer of the same file from being initiated.

ECV

U4
330 DvvalList S A list of the DVVAL variables, their IDs and names (L [L:2 <VID> <DVNAME>]+).  The value of this variable is completely managed by the SECS server.  This variable is standard for Hume implementations, but is not specified by SEMI standards.  The variable fills a gap in SECS functionality - there is no standard means for the host to ask about DVVAL variables. SV L
350 ECIDChangeName S The equipment constant, ECID, last updated independent of the host.  This value is managed by the SECS Server using your parameter related API calls. DVVAL U4
375 EstablishCommunicationsTimeout H The length of time in seconds between S1F13 attempts when initializing communications.  The default value is 30. This parameter can be set to affect the server. ECV U4
400 EventsEnabled S The list of event CEIDs enabled for data collection event reports.  This value is managed for you by the SECS server. SV L
410 EventDescriptions S A list of all event CEIDs and their descriptions.  This value is completely managed by the SECS server.  This variable is standard for Hume implementations, but is not specified by SEMI standards.  The variable fills a gap in SECS functionality - there is no standard means for the host to ask about event types. SV L
500 LimitVariable A Contains the VID for the variable whose value changed monitoring zones.  This value is not managed by the SECS server.  If you implement Limits Monitoring, then you should implement logic to set this variable value. DVVAL U4
501 EventLimit A Contains LIMITID(s) of the limit reached by LimitVariable(s).  This value is not managed by the SECS server.  If you implement Limits Monitoring, then you should implement logic to set this value. DVVAL L
502 TransitionType A The direction of limits zone transition 0=low2hi, 1=hi2low.  This value is not managed by the SECS server.  If you implement Limits Monitoring, then you should implement logic to set this value. DVVAL B
600 MDLN S Equipment Model Type. This value is managed for you by the SECS Server using your MDLN property value. SV A:6
650 OperatorCommand A The last operator command issued during control_mode of REMOTE.  This value needs to be managed by your SECS application logic.  Look at the application example - you need to provide names for your operator actions, and make the latest value known to the SECS server by providing a variable value callback, or by making a value set call before posting the OperatorCommandIssued event. DVVAL A
700 PPChangeName A The Process Program ID, PPID, affected by the creation, edit, or delete local to the equipment.  The PPChangeName and PPChangeStatus values need to be managed by your SECS application logic if your equipment supports the creation, editing, or deletion of process programs.  You set the current values, or make them available through variable value callbacks just prior to posting the ProcessProgramChange event. DVVAL A
710 PPChangeStatus A The action taken on PPChangeName, 1=create, 2=edit, 3=deleted. Your application logic manages this variable value if your equipment supports editing process programs.  See PPChangeName above. DVVAL U1
715 PPError A Contains information about a failure to verify a process program.  Your application logic should set the value of this variable just prior to posting the ProcessProgramInvalid event when a process program received from the host fails validation.  You trigger your evaluation logic from the StateChange event when the data arguments inform you of a process program download. DVVAL A
720 PPExecName A The PPID(s) of the selected Process Program(s).  Your application logic manages this value to indicate the current process program. SV A
725 PPFormat A Indicates the type or types of process programs (PPs) and recipes supported: 1 = normal unformatted PPs, 5 = large unformatted PPs, 10 = normal and large unformatted PPs.  See E5 for other values.  The default value is 1.  A "large" process program is sufficently large that Stream 13 messages are preferred to the Stream 7 messages for PP transfer.  A normal size PP is compatible with either Stream 7 or Stream 13 transfers.  The transfer of very large PPs using Stream 7 can cause excessive memory allocations for both the sender and the receiver.  Therefore, if the PPFormat is set to 5, the SECS server only allows the safer, but more complex Stream 13 transfers.  The default value of this variable is 1.  We recommend that you use the simpler SEMI concept of unformatted Process Programs, and restrict your value choices to 1, 5, and 10.  We also suggest you set the value of PPFormat to 5 if your process programs are larger than 64k, although the SECS server is able to transfer files as large as 3.5 meg using Stream 7. SV U1
800 PreviousProcessState A The previous processing state.  Your application needs to manage the PreviousProcessState and the ProcessState values, typically by setting their values with the SECS server just prior to posting events that indicate process state change, namely, ProcessingStarted, ProcessingCompleted, ProcessingStopped. and ProcessStateUpdate.  The example application has more detail.

State values used by the example application are: 64 initializing, 65 idle, 66 setup, 67 executing, and 68 paused.
SV U1
810 ProcessState A The current processing state.  Your application needs to manage this value - see the discussion directly above under PreviousProcessState and the example application code. 

State values used by the example application are: 64 initializing, 65 idle, 66 setup, 67 executing, and 68 paused.
SV U1
820 RcpChangeName A The identifier of the Stream 15 recipe affected by creation, editing, or deletion.  If your equipment uses the more complex recipes described by Stream 15 messages, then use the RcpChangeName and RcpChangeStatus values to indicate editing changes to Recipes along with posting event ExecutionRecipeNew or ExecutionRecipeChange. DVVAL A
825 RcpChangeStatus A The type of change for RcpChangeName.  Managed by your logic if you use Stream 15 type recipes. 0 = No change, 1 = Created, 2 = Updated (modified), 3 = Stored (new), 4 = Replaced, 5 = Deleted, 6 = Copied, 7= Renamed DVVAL U1
830 RcpExecName A The identifier of the currently selected Stream 15 recipe.  Managed by your logic if you use Stream 15 type recipes. SV A
850 SOFTREV S Equipment Software Revision ID.  This value is managed for you by the SECS server using your SOFTREV property value. SV A:6
870 SpoolCountActual S The actual number of messages queued.  This value is managed by the SECS server. SV U4
871 SpoolCountTotal S The total number of messages spooled and/or discarded.  This value is managed by the SECS server. SV U4
872 SpoolFullTime S The Clock value from the time the spool last became full.  This value is managed by the SECS server. SV A:16
873 SpoolStartTime S The Clock value from the time spooling last became active.  This value is managed by the SECS server. SV A:16
874 MaxSpoolTransmit H The maximum number of spooled messages sent per S6F23 reply, 0 means no limit.  The default value is 0.  This parameter may be changed to affect the SECS server's behavior. ECV U4
875 SpoolMax H The maximum number of messages that are allowed to be spooled.   The default value is 10000.  This parameter may be changed to affect the SECS server's behavior. ECV U4
876 OverWriteSpool H If true, circular spool buffering is used, meaning newer values overwrite the oldest values when the maximum number of messages is reached. If false, spooling is stopped when the buffer is full.  The default value is false.  This parameter may be changed to affect spooling behavior. ECV TF
877 SpoolStreamFns H The list of SnFm message types that are spooled. The value is set by receiving S2F43 from the host. Your logic should use the SpoolingAllow property and the spoolStreamFns method to control spooling and not manipulate this variable value. SV A
900 TimeFormat H This variable may be set to control the time format used in message types S2F18, S2F32, and S6F1: 0==YYMMDDHHMMSScc 1==YYYYMMDDHHMMSScc  The default is 1 (YYYYMMDDHHMMSScc). ECV U4
920 UseMultiBlockInquire H If true, S6F5 is used before sending multiblock event reports.  The default value is true for SECS-I and false for HSMS. This parameter value may be set to override the default. ECV TF

Built-in Handling of SECS Message Types

The E5 standard identifies data items used in message items with all uppercase letters such as CEID.  Typically, the standard allows for different data types to be used for a particular message item.  If we show a message data item in lowercase, we are showing the preferred data type of our implementation, and using the lowercase term to indicate a value of the indicated data type.  For example, we use type U4 to pass CEID values.  So our shorthand way of specifying this is to write "{U4 <ceid>}" instead of <CEID>.  Historically, the host software has been required to know and use the specific data types that the equipment implements when the standard allows for different data types.  This has never been the case with Hume SECS/GEM implementations.  For most message types, the software accepts any data type for a message data item as long as the value is equivalent.  For example, the S1F3R message data to obtain the value of the Clock variable, SVID = 250, is usually sent by the host as "L {U4 250}" since our implementation uses type U4 to send SVID values.  But the host could use type A, type U2, type U1, type I4, or type I2 for the data type of the SVID value to make this same request.  The value passed by the host only needs to be equal when compared as a string.  If the standard identifies a single data type for an item, only the specified type should be used.  For example, for control of spooling, S2F43, only type U1 should be used to indicate streams and functions.
 
Type Sender Data Format Comments
S1F1R H, E   "Are You There?"
S1F2 E L:2 <MDLN> <SOFTREV>
<MDLN> := {A <mdln>}
<SOFTREV> := {A <softrev>}
"On Line Data"
The MDLN and SOFTREV items are set from property values.
S1F3R H L [<SVID>]*
<SVID>  := {U4 <varID>}
"Selected Equipment Status Request" 
If the host sends a 0 length list, the host gets all possible values, but he doesn't know what they represent!  So there is an unwritten rule that the ordering of the L:0 reply matches the ordering of the S1F12 reply.
S1F4 E L [<SV>]* "Selected Equipment Status Data"
The data type of the SV value depends on the variable.
S1F11R H L [<SVID>]*  "Status Variable Namelist Request"
S1F12 E L [{L:3 <SVID> <SVNAME> <UNITS>}]+  "Status Variable Namelist Reply"
S1F13R H,E L:2 <MDLN> <SOFTREV>  "Establish Communications Request"
S1F14 E L:2 <COMMACK> {L:2 <MDLN> <SOFTREV>}
<COMMACK> := {B 0}
 "Establish Communications Request Acknowledge"
S1F15R H   "Request OFF-LINE"
S1F16 E B 0 "OFF-LINE Acknowledge"
causes transition to OFF-LINE Host control state
S1F17R H   "Request ON-LINE"
S1F18 E <ONLACK> := {B <onlack>} "ON-LINE Acknowledge"
{B 1} is sent if we have an offline control intent,
{B 2} is sent if we are already online
If we have an online control intent, {B 1} is sent in the unlikely case we are in the OFF-LINE Seekonline state, since the GEM standard does not show an online transition for this state because of S1F17R.  The usual case if we have an online control intent is to send {B 0} and transition to online control
       
S2F13 H L [<ECID>]* "Equipment Constant Request"
S2F14 E L [<ECV>]* "Equipment Constant Data"
if L:0 is input, the reply order matches S2F30.
S2F15R H L [{L:2 <ECID> <ECV>}]* "New Equipment Constant Send"
S2F16 E B <eac> "New Equipment Constant Ack" 
Possible return values: 0 = ok, 1 = one or more constants does not exist, 3 = one or more values are out of range
S2F17R H   "Date and Time Request"
S2F18 E A:16 YYYYMMDDHHMMSScc or
A:12 YYMMDDHHMMSS
"Date and Time Data"
The TimeFormat parameter (ECV) selects the reply format, A:16 YYYYMMDDHHMMSScc is the default.
S2F23R H L:5 <TRID> <DSPER> <TOTSMP> <REPGSZ> {L [<SVID>]+}  "Trace Initialize Send"
S2F24 E B <tiaack> "Trace Initialize Acknowledge"
The SECS server manages sending the trace report messages (S6F1). Possible return values: 0 = ok, 2 = no more traces allowed, 3 = invalid period.  S9F7 is sent in lieu of a reply if an unknown variable is requested or if the TOTSMP value is not an even multiple of REPGSZ.
S2F25R H,E B [<b>]* "Loopback Diagnostic Request"
S2F26 E B [<b>]*  "Loopback Diagnostic Data"
S2F29R H L [<ECID>]* "Equipment Constant Namelist Request"
S2F30 E L [L:6 <ECID> <ECNAME> <ECMIN> <ECMAX> <ECDEF> <UNITS>]+  "Equipment Constant Namelist"
S2F31R H A:16 YYYYMMDDHHMMSScc  or
A:12 YYMMDDHHMMSS
"Date and Time Set Request"
S2F32 E B <tiack> "Date and Time Set Acknowledge"
The SECS server calculates and uses a clock offset value so the system clock is not affected. The return value will be 0 (ok) for any valid input, otherwise the return value is 1.
S2F33R H L:2 <DATAID> {L [{L:2 <RPTID> {L [<VID>]*}]*} "Define Report"
S2F34 E B <drack> "Define Report Acknowledge"
Return values are: 0 = ok, 2 = bad format, 3 = RPTID already in use, 4 = invalid VID
S2F35R H L:2 <DATAID> {L [<CEID> {L [<RPTID>]*}]*} "Link Event Report"
S2F36 E B <lrack> "Link Event Report Acknowledge"
Return values are: 0 = ok, 3 = CEID already linked, 4 = invalid CEID, 5 = invalid RPTID
S2F37R H L:2 <CEED> {L [<CEID>]*} "Enable/Disable Event Report"
S2F38   B <erack> "Enable/Disable Event Report Acknowledge"
Return values are: 0 = ok, 2 = invalid CEID
S2F39R H L:2 <DATAID> <DATALENGTH> "Multi-block Inquire"
The implementation does not care what type or value the <DATAID> is.
S2F40 E B 0 "Multi-block Grant"
S2F41R H L:2 <RCMD> {L [{L:2 <CPNAME> <CPVAL>]*} "Host Command Send"
S2F42 E L:2 <HCACK> {L [{L:2 <CPNAME> <CPACK>]*} "Host Command Acknowledge"
sent by your handling logic in the application -see example
S2F43R H L [{L:2 {U1 <strid>} {L [{U1 <fcnid>}]*}]*  "Configure Spooling"
S2F44 E L:2 {B <rsack>} {L [{L:3 {U1 <strid>} {B <strack>} {L [{U1 <fcnid>}]*}}]*} "Configure Spooling Acknowledge"
The property SpoolingAllow is consulted to determine which message types are allowed for spooling.
       
S5F1 E L:3 {B <alcd>} {U4 <alid>} {A <altx>} "Alarm Report Send"
the SecPort does not request a reply
S5F3R H L:2 {B <aled>} {U4 <alid>} "Enable/Disable Alarm Send"
S5F4 E B <ackc5> "Enable/Disable Alarm Ack"
S5F5R H <ALID vector> "List Alarms Request"
S5F6 E L [{L:3 {B <alcd>} {U4 <alid>} {A <altx>}}]* "List Alarm Data"
S5F7R H   "List Enabled Alarm Request"
S5F8 E L [{L:3 {B <alcd>} {U4 <alid>} {A <altx>}}]* "List Enabled Alarm Data"
       
S6F1 E L:4 <TRID> {U4 <smpln>} <STIME> {L [<SV>]+} "Trace Data Send"
The SECS server does not ask for replies.  <STIME> is formatted per the TimeFormat ECV setting.  <TRID> is whatever type and value the host sends in S2F23R.
S6F5R E L:2 <DATAID> <DATALENGTH> "Multi-block Data Send Inquire"
S6F6 H <GRANT6> "Multi-block Grant"
S6F11R E L:3 {U4 <dataid>} {U4 <ceid>} {L [{L:2 {U4 <rptid>} {L [<V>]+}}]+} "Event Report Send"
ECV AnnotateEventReports, varID 220, controls whether S6F11R is sent or S6F13R is sent.  S6F13R is the default.
S6F12 H <ACKC6> "Event Report Ack"
S6F13R E L:3 {U4 <dataid>} {U4 <ceid>} {L [{L:2 {U4 <rptid>} {L [{L:2 {U4 <vid>} <V>}]+}}]+} "Annotated Event Report Send"
S6F14 H <ACKC6> "Annotated Event Report Ack"
S6F15R H <CEID> "Event Report Request"
S6F16 E S6F11 data "Event Report Data"
S6F17R H <CEID> "Annotated Event Report Request"
S6F18 E S6F13 data "Annotated Event Report Data"
S6F19R H <RPTID> "Individual Report Request"
S6F20 E L [<V>]* "Individual Report Data"
S6F21R H <RPTID> "Annotated Individual Report Request"
S6F22 E L [{L:2 {U4 <varID>} <V>}]* "Annotated Individual Report Data"
S6F23R H <RSDC> "Request or Purge Spooled Data"
S6F24 E <RSDA> "Request or Purge Spooled Data Ack"
       
S7F1R H, E L:2 <PPID> <LENGTH> "Process Program Load Inquire"
S7F2 E, H <PPGNT> "Process Program Load Grant" - the SECS server always sends B 0.
S7F3R H, E L:2 {A <ppid>} <PPBODY> "Process Program Download"
Your application property setting for whether process programs are binary determines whether PPBODY is type B or A.  If the value of the PPFormat variable is 5, meaning large programs, this message type is disabled to prevent excessive memory use.
S7F4 E, H B <ackc7> "Process Program Download Acknowledge"
Return values are: 0 = ok, 5 = file system error.
S7F5R E, H A <ppid> "Process Program Upload Request"
S7F6 E, H L:2 {A <ppid>} <PPBODY> "Process Program Upload Data"
Your application property setting for whether process programs are binary determines whether PPBODY is type B or A.  If the value of the PPFormat variable is 5, meaning large programs, this message type is disabled to prevent excessive memory use.
S7F17R H L [{A <ppid>}]* "Delete Process Program Send"
S7F18 E B <ackc7> "Delete Process Program Acknowledge" Return values: 0 = ok, 1 = permission error, 4 = PPID not found
S7F19R H   "Current Process Program Dir Request"
S7F20 E L [{A <ppid>}]* "Current Process Program Data"
S7F27R
E
L:2 {A <ppid>} {L {L:3 {B <ackc7a>} {U4 <seqnum>} {A <errw7>}}}
"Process Program Verification Send"
The example equipment application sends this message after receiving a large process program transfer using Stream 13 data set transfer messages.  To be GEM compliant with large process program transfer scenarios, your equipment application needs to implement process program verification and sending this message type.  Use the StateChange event with the name dataset_download to trigger your verification logic.
S7F28
H

"Process Program Verification Acknowledge"
S7F29R
E
{U4 <length>}
"Process Program Verification Inquire"
Per GEM, the SECS server sends this message after receiving a Stream 13 downloaded process program in order to verify the length in bytes of the received process program.  There is a settable parameter, DataSetSendVerifyS7F29, that can be set false to disable sending this message and performing the length verification when the host does not support it.
S7F30
H
<PPGNT>
"Process Program Verification Grant"
S7F37R
E, H
A <dsname>
"Large Process Program Send"
The sender wishes to send a large process program using Stream 13 messages.
S7F38
E, H
B <ackc7>
"Large Process Program Acknowledge"
Return values are: 0 = ok, 1 = permission not granted
Permission is not granted if spooling is active or if the dsname value is not acceptable.  Acceptable names consist only of alphanumeric characters and period, ., hyphen, -, or underscore, _, or space characters.  The name may not have leading or trailing space or period characters.
S7F41R
E, H
A <dsname> "Large Process Program Request"
The sender of this message wishes to receive a large process program using Stream 13 messages.
S7F42
E, H
B <ackc7> "Large Process Program Acknowledge"
Return values are: 0 = ok, 1 = permission not granted, 4 = PPID not found, 6 = other error
Permission is not granted if spooling is active.  Error value 6 is returned if there is a file system error such as the file being locked. 

The SECS server makes a temporary copy of the process program when this reply is prepared in order to avoid problems with the file being locked or changed during the transfer. 
 
 
 
 
S*F0     abort replies are handled as a special case of reply
S9F1 E <MHEAD> "Unknown Device ID"
sent automatically per the standard
S9F3 E,H <MHEAD> "Unknown Stream"
S9F5 E,H <MHEAD> "Unknown Function"
S9F7 E,H <MHEAD> "Illegal Data" - Use this message type in your custom message handlers to indicate when the received data does not have the expected format.
S9F9 E,H <MHEAD> "Transaction Timeout"
T3 timeout
S9F11 E <MHEAD> "Data Too Long" - your application can send this, it is not sent by the SECS server.
       
S10F1 E L:2 {B 0} {A <text>} "Terminal Request"
the example application sends this
S10F3R H L:2 <TID> {A <text>} "Terminal Display, Single"
S10F4 E B <ackc10> "Terminal Display, Single Acknowledge"
<ackc10> is set by your application callback, standard values are: 0 = ok, 1 = message not displayed, 2 = terminal not available.
S10F5R H L:n <TID> {L [{A <text>}]*}  "Terminal Display, Multi-Block"
S10F6 E B <ackc10> "Terminal Display, Multi-Block Acknowledge"
<ackc10> is set by your application callback, standard values are: 0 = ok, 1 = message not displayed, 2 = terminal not available.




S13F1R E L:1 {A <dsname>}
"Send Data Set Send"
Per the process program transfer scenarios in GEM E30, only the equipment sends S13F1R to offer uploading a large, unformatted PP.
S13F2
H
L:2 {A <dsname>} {B <ackc13>}
"Send Data Set Acknowledge"
Per GEM E30, this reply is expected to be sent only by the host.
S13F3R
E, H
L:3 {U4 <handle>} {A <dsname>} {U4 <ckpnt>}
"Open Data Set Request"
S13F4
E, H
L:5 {U4 <handle>} {A <dsname>} {B <ackc13>} {U1 <rtype>} {U4 <reclen>}
"Open Data Set Data"
Ackc13 return code values are: 0 = ok, 2 = unknown data set name, 3 = bad checkpoint value,  9 = handle in use, or 66 = file system error
The host can use any data type for HANDLE but the U4 type is used for sending.  The <rtype> value sent is 0 indicating a stream.  The <reclen> value sent as a maximum read size is 65536 which reflects a balance of many considerations.
S13F5R
E, H
L:2 {U4 <handle>} {U4 <readln>}
"Read Data Set Request"
If the maximum read size, <reclen>, is greater than 32768, the equipment sets <readln> to 16384.  If the maximum read size is less than or equal to 32768, the equipment uses the maximum read size as the <readln> value.
S13F6
E, H
L:4 {U4 <handle>} {B <ackc13>} {U4 <ckpnt>} {L:n {B <fildat>}}
"Read Data Set Data"
Ackc13 return code values are: 0 = ok, 6 = no open data set for the handle, 7 file system error, 8 = at end of data.
On sending, the equipment sends <fildat> as a single list item binary vector (L:1 {B <fldat>}).  On receiving, the equipment is able to handle lists of any number of elements.  Only data types B or A are allowed for <FILDAT>.
S13F7R
E, H
L:1 {U4 <handle>}
"Close Data Set Send"
S13F8
E, H
L:2 {U4 <handle>} {B <ackc13>}
"Close Data Set Acknowledge"
Ackc13 return code values are: 0 = ok, 6 = no open data set for the handle
S13F9R
E, H

"Reset Data Set Send"
In order to maximize compatibility with many different hosts, the equipment does not automatically send this message during initialization; the default behavior is to send it if the host sends it.  The host user is able to set the Equipment Constant  DataSetSendResetS13F9 to control sending of this message type during initialization.
S13F10
E, H

"Reset Data Set Acknowledge"




Built-In Event Type Definitions


The table below shows the default data collection event CEID values and the event names.  The CEID values can all be customized using the event renumbering method provided for this purpose, and the alarm addition method that allows alarm set and clear events to be specified.

The Owner column shows at a glance whose logic is responsible to post the event. The letter S indicates that the SECS server posts the event type when appropriate.  The letter A indicates that your application should post the event type whenever it occurs.
 
Default CEID Event Name Owner Description
1000-3999 Of the pattern
AlarmALIDCleared
AlarmALIDDetected
where ALID is the 
numeric alarm ID.
S By default, the addition of each alarm type creates two new events; one for the Alarm Set event with the CEID value of ALID,  and one for the Alarm Clear event with the CEID value of ALID+1.  Customization of the CEID values is possible using the alarm add method where the CEID values are specified.

Use the alarm set method to set (or clear) an alarm condition and the SECS server takes care of setting the AlarmID variable value and posting the required GEM event.

4000 ControlStateOFFLINE S Control State OFF-LINE. Your application uses the control intent property to indicate the ON-LINE or OFF-LINE intention.
4001 ControlStateLOCAL S Control State LOCAL. Your application uses the control intent and mode properties to indicate your intention, and the SECS server takes care of the state transitions and posting the events.
4002 ControlStateREMOTE S Control State REMOTE
4005 MaterialReceived A Material Received
4006 MaterialRemoved A Material Removed
4015 OperatorCommandIssued A Operator Command Issued. Set the OperatorCommand variable to the new command value prior to posting the event.
4020 OperatorEquipmentConstantChange S Operator Equipment Constant Change. The SECS Server is aware of the parameter update method call and posts the event when appropriate.
4030 ProcessProgramChange A Process Program Change. Use the PPChangeName and PPChangeStatus variables to communicate the context data of the event to the host.
4035 ProcessProgramInvalid A Process Program Invalid. Use the PPError variable to indicate the validation problem. You may also use the PPChangeName variable to indicate the identifier of the downloaded Process Program that is failing validation.
4040 ProcessProgramSelected A Process Program Selected. Set the variable PPExecName to the new value before posting this event.
4047 ProcessingStarted A Processing Started
4048 ProcessingCompleted A Processing Completed
4049 ProcessingStopped A Processing Stopped
4050 ProcessStateUpdate A Process State Update. See the example application for a working implementation of a process state model and posting the related events. The Processing Started, Completed, and Stopped events are posted in addition to the ProcessStateUpdate event. In other words, at the start of processing, there are two events posted, ProcessingStarted and ProcessStateUpdate. You typically set the variable values PreviousProcessState and ProcessState just before posting the process state related events.
4080 SpoolingActivated S Spooling Activated
4081 SpoolingDeactivated S Spooling Deactivated
4083 SpoolTransmitFailure S Spool Transmit Failure
4091 ExecutionRecipeNew A Stream 15 Execution Recipe - New
4093 ExecutionRecipeChange A Stream 15 Execution Recipe - Change
4100 TerminalServicesOperatorAck A Terminal Services Operator Display Acknowledge. There is a similarly named API method that your application calls which causes this event to be posted.
4120
UploadFailure
S
This event is posted when a large Process Program transfer to the host using Stream 13 messages ends with an error condition such as a file system error.  At the time of the event, the variable DataSetName has the ID of the affected Process Program.
4125
UploadSuccess
S
This event is posted when a large Process Program transfer to the host using Stream 13 messages succeeds.  Actually, the equipment cannot know that the host has truly succeeded, only that the last read reply message was sent for the transfer.  At the time of the event, the variable DataSetName has the ID of the affected Process Program.
4130
UploadTimeout
S
This event is posted if a next message during Stream 13 data set transfer does not occur within the time interval of the settable parameter DataSetTimeoutSecs.  At the time of the event, the variable DataSetName has the ID of the affected Process Program.  The event occurrence does not mean that the upload has failed, it can still succeed if the host continues.  If the event does occur, the active transfer no longer prevents a new transfer of the same data set from being initiated.