The Service interface describes what methods are used by the VLCB system
and must be implemented by concrete service classes.
The VLCB system is configured with a set of services that implement the functionality needed by the VLCB module. A list of services provided in this VLCB library are listed in the section Provided Services.
User defined services are encouraged to implement new functionality that is not covered by the provided services
The Service interface is described in Service
A complete list of implementing service classes are also included there.
Below is a list of services provided by the VLCB library that can be used in a VLCB module sketch.
The services listed below do not include diagnostics.
Such diagnostics are optional and provided by child classes with the suffix "WithDiagnostics".
E.g. The CAN service class CanService does not provide diagnostics
while the class CanServiceWithDiagnostics does provide diagnostics.
Diagnostics is made optional to save memory on smaller Arduino systems.
Note: Not all services have a diagnostics enabled counterpart yet.
Handles the OP-codes for managing nodes. It is required for use in a VLCB module.
This is a service that is specifically for modules on a CAN bus and is required for such modules. Handles OP-codes CANID and ENUM for re-assigning CANID for the module.
The CanService works in tandem with a CAN transport object, derived from the
CanTransport interface, which must be provided as an argument to its constructor.
Handles configuration of node variables for the module.
Handles incoming events.
To use this the module application needs to register an event handler function with
setEventHandler().
The signature of the handler function shall be:
void handler(byte index, const VlcbMessage *msg);The arguments provided to the handler function are:
index: The index number of the incoming event in the event table.msg: The message structure that contains the event.
Facilitates sending events. The events can either be:
- Direct events where the event number is given and the node number of the node is used. Optionally a node number can be provided for spoofed node numbers.
- Taught events that are stored in the events table. These events are accessed by an index into the events table.
Facilitates teaching events using classic event teaching. Events are taught (created), updated and read by using the event node number and event number as key to the event, or putting the node into learn mode. This means that the node number / event number pair must be unique.
Both consumed and produced events can be taught.
A user sketch can register an event validation callback with
setEventValidator().
The signature of the validator function shall be:
byte eventValidator(int nn, int en, byte evNum, byte evValue);It shall return a response code GRSP_OK (0) if the taught event is accepted
or any other GRSP_XXX code or CMDERR_XXX code for failure.
For failures this error code will be the response to EVLRN request.
Facilitates teaching events using indexed (slot) event teaching. Here events are taught (created), updated and read by using event indexes.
The same event (with the same node number / event number) can be taught to different slots.
This service facilitates sent events to be received by the same module.
Any event generated by the EventProducerService will then be handled
by the EventConsumerService.
Manages the green and yellow LEDs and also the push button on the VLCB module. Updates the LEDs based on activities on the module. When the push button is pressed sends an Action to tell the other services that the user has requested some action.
Provides a user interface on the serial port on the Arduino. Prints status messages and also handles actions the user enters on the serial port. See more details in SerialUserInterface documentation.