05-01-2013, 04:42 PM
(This post was last modified: 07-31-2014, 10:14 AM by Dean Roddey.)
General Description
This thread is for discussion of the Contact Closure device class. Drivers that implement this device class will provide one or more sensors that sense whether a connection is open or closed.
Fields Provided
[INDENT]It is assumed that, in the general case, the fields will likely be nameable by the user, therefore there are no naming convention limitations on the fields of this device class, other than that they MUST use the appropriate prefix indicator, i.e. that all of them be in one of the forms:
CTCL#fieldname
CTCL#sub~fieldname
This indicates that the fields are implementing the Contact Closure device class.
If initial default names are assigned until the user can/does rename them, then it is SUGGESTED that they in some way refer back to device specific values, so that it is obvious what contact each field is attached to.[/INDENT]
Multi-Unit Considerations
[INDENT]Though it is generally assumed that these fields will be user nameable to reflect their function and therefore are all on an equal footing, if the device provides banks of identical sets of contacts with a specific purpose, the driver MAY use sub-unit naming conventions. In that case the fieldname parts become fixed, and the sub-unit part becomes the user or device provided name. Each sub-unit must provide an identical set of fields.[/INDENT]
Semantic Requirements
[INDENT]All such fields should be semantically marked with the ContactClosure semantic field type, and follow the conventions indicated by that semantic field type. Contact closures are read-only, since they only sense the open/close state of a contact.[/INDENT]
Backdoor Commands/Queries
[INDENT]None are required at this time.[/INDENT]
This thread is for discussion of the Contact Closure device class. Drivers that implement this device class will provide one or more sensors that sense whether a connection is open or closed.
Fields Provided
[INDENT]It is assumed that, in the general case, the fields will likely be nameable by the user, therefore there are no naming convention limitations on the fields of this device class, other than that they MUST use the appropriate prefix indicator, i.e. that all of them be in one of the forms:
CTCL#fieldname
CTCL#sub~fieldname
This indicates that the fields are implementing the Contact Closure device class.
If initial default names are assigned until the user can/does rename them, then it is SUGGESTED that they in some way refer back to device specific values, so that it is obvious what contact each field is attached to.[/INDENT]
Multi-Unit Considerations
[INDENT]Though it is generally assumed that these fields will be user nameable to reflect their function and therefore are all on an equal footing, if the device provides banks of identical sets of contacts with a specific purpose, the driver MAY use sub-unit naming conventions. In that case the fieldname parts become fixed, and the sub-unit part becomes the user or device provided name. Each sub-unit must provide an identical set of fields.[/INDENT]
Semantic Requirements
[INDENT]All such fields should be semantically marked with the ContactClosure semantic field type, and follow the conventions indicated by that semantic field type. Contact closures are read-only, since they only sense the open/close state of a contact.[/INDENT]
Backdoor Commands/Queries
[INDENT]None are required at this time.[/INDENT]
Dean Roddey
Explorans limites defectum
Explorans limites defectum
