Charmed Quark Systems, Ltd. - Support Forums and Community
Class: ContactClosure - Printable Version

+- Charmed Quark Systems, Ltd. - Support Forums and Community (
+-- Forum: General Discussion (
+--- Forum: Device Classification (
+--- Thread: Class: ContactClosure (/showthread.php?tid=8300)

Class: ContactClosure - Dean Roddey - 05-01-2013

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:


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]

Class: ContactClosure - Dean Roddey - 05-01-2013

(reserved for expansion)

Class: ContactClosure - Dean Roddey - 05-01-2013

(reserved for expansion 2)

Class: ContactClosure - Dean Roddey - 05-04-2013

Is this one redundant? Is there any useful difference between a relay and a contact closure? Is a contact closure basically a read only relay?

Class: ContactClosure - wuench - 05-05-2013

In my mind DIO, Relay, Switch, and Contact closure are all redundant. They are all just boolean/binary fields. The only difference is read-only/read-write.

Maybe you could just get away with something like:

Switch (Read/Write Boolean)
Input (Read/Only Boolean)

Class: ContactClosure - Dean Roddey - 05-05-2013

Keep in mind that these will also used for filtering during field/driver selection. So they may want to find all the devices that provide relays. We'd find them by looking for all drivers that implement the Relay device class. So it's not just about functionality, it's also about finding and filtering.

Class: ContactClosure - Dean Roddey - 06-22-2013

OK, updated this one.

Class: ContactClosure - Dean Roddey - 07-31-2014

Updated to clarify access requirements and multi-unit naming stuff.