| |
|
|
| IDRATEK
modules possess a very powerful feature known as 'Reflex'
behaviour. |
| This
allows modules to react automatically to certain events.
The reaction can |
|
take the form of sending command or information packets
to the network and/or |
|
executing internal commands. The key benefits of this
feature are listed below. |
| |
|
Modules
are not 'dumb' as each is capable controlling itself
and others |
|
Reaction
to events depends on the module e.g. a digital input
can trigger a |
|
|
packet
on a change of state, but local decision logic is
also possible |
|
Modules
can monitor multiple events and generate a Reflex
for each e.g. the |
|
|
MFP
units can generate responses to upwards of 40 different
events |
|
Allows
creation of truly non centralised (masterless) control
structures |
|
Centralised
structures, e.g. using CORTEX, can sub-delegate certain
tasks |
|
Information
is sent only on events so avoiding inefficient polling
schemes |
|
If
a central controller fails, the system can fall back
to an entirely Reflex |
|
|
control mode, so ensuring that some functionality
remains |
| |
|
An
example of the Reflex feature based on our QBI-001
module is shown below. |
| |
|
|
|
| |
|
|
| |
|
This
module can be programmed to react to a change of state
for any of its 4 buttons. Once triggered, this |
| |
|
reaction
can be programmed to broadcast an informational network
packet (e.g. providing button state), as well |
| |
|
as
network packets containing commands to remote nodes.
In this example, commands are sent to several |
| |
|
electrical switching modules in order to operate connected
lights. |
| |
|
The
user can define certain 'filtering' conditions, for
example to generate a reaction when a button is pressed |
| |
|
(rather than released). Both the filter conditions
and the reactions (Reflexes), are user programmable
and are |
| |
|
retained in non-volatile memory. Each button generates
an independent event trigger and each trigger can |
| |
|
action its own unique set of Reflexes. |