Quick Start Guide

10 SENTINEL SM1 Quick Start Guide 11
Utility
Relay A: Three terminals whose default action is to indicate when there is a PC disconnection fault. When there is no PC Fault the COM terminal is disconnected from
the “N/O” terminal, and connected to the “N/C” terminal. When a PC Fault is present, the COM terminal becomes disconnected from the “N/C” terminal, and connected
to the “N/O” terminal. When the device is not powered, the COM terminal is disconnected from the “N/C” terminal, and connected to the “N/O” terminal.
Relay B: Not currently implemented.
Installation and setting up
Devices are identi ed on the network by means of a Handle which is unique, and a Link Address which is randomly allocated, but checked for uniqueness and corrected
by PodWare when going online to the system. When a network of devices is newly installed,  rst go online to the network with PodWare to make sure this checking
process is done. Wait for PodWare to discover all of your devices this  rst time. Do not connect Sentinel to the network until this is done.
So that devices reporting Incidents to Sentinel can be identi ed, each device on the network should be given a Device Name. Please see the main PodWare Help  le for
details on how to do this.
When you power-up Sentinel while connected to a network of devices, or if a network of devices is plugged into Sentinel while it is operating, Sentinel will discover all
the devices on the network and begin to monitor them. While it is discovering new device, it illuminates all the front panel indicators to warn you that incidents are
not being monitored during this process. For a large number of devices, this process can take several minutes.
Better network performance will be had if either Sentinel or PodWare are online to the system. Operations will be slower if both are online to a large network of
devices. If it is a requirement to have both Sentinel and PodWare online to a large network (larger than say 24 devices), then Sentinel should be put online  rst and
allowed to acquire all the devices, then once settled, put PodWare online.
Navigating on the Sentinel
There are a number of “pages” that you can view. Use the “<” Page button to view the previous page, or “>” Page button to view the next page.
Use the Encoder to adjust the value of the item (Parameter) if it is adjustable. If the item is not adjustable, then the Encoder will have no action.
The pages are as follows:
• Display Contrast
• Default information (The default page)
• Incident (History, Scroll for others)
Some pages (such as Incident History) allow scrolling among the items. Use the “∨” Scroll button to view the previous scrolled item, or “∧” Scroll button to view the
next scrolled item.
By default, the display will usually show the name of this device, the number of other devices that it has found on the network, and the Alarm status:
MyDeviceName
27 of 28 Devices Normal
The word “Normal” indicates that no incidents are active among the monitored devices. The display is also indicating that 27 devices have been found on the network,
of the 28 expected. If there is an Alarm Incident active, the default page will look like this:
MyDeviceName
28 of 28 Devices Fault>
For a Fault Incident. Or (for a Check incident):
MyDeviceName
28 of 28 Devices Check>
Details of the Alarm Incidents may be viewed by clicking the “>” Page button to go to the Alarm Incident History page. For a Check incident, an incident looks like this:
8.3 Dys ago DeviceName03
CHK Ampli erTemperature
This shows the elapsed time (how many days since the incident ended - in this case 8.3 days ago), the name of the device which raised the incident (“DeviceName03”),
the incident type (Check) and the Alarm Name (“Ampli erTemperature”). If the incident is more than 160 days old, the elapsed time is shown as “>5 mths”. If the
Sentinel unit has its power removed then re-applied, the elapsed time indications may be inaccurate since the timers do not run when the power is switched o .
A Fault incident looks like this:
27 Dys ago DeviceName04
FLT Pilot Tone Lost
If the incident still exists, the elapsed time is shown as **NOW**:
**NOW** DeviceName02
CHK DriverImpedanceChanB
Local Alarms (Alarms which are not reported from monitored devices, but from the Sentinel unit itself), are shown on the display in exactly the same way except that
the DeviceName of the o ending device, is the name of the Sentinel product:
**NOW** MyDeviceName
FLT WrongNumberOfDevices
Clicking the “∨”, “∧” Scroll buttons will allow other items in the Incident History to be viewed. The latest incident will normally be shown. Click the “v” Scroll button
repeatedly to show older incidents.
Clicking the “<” Page button from the default page will show the Utility Page - Display Contrast:
Util Screen
1 100%
Using and controlling Sentinel with PodWare
For further help on the PodWare application, please refer to the general software documentation, or click the help button on the main application.
Device alarm incidents
Alarm Incidents are a uni ed way of informing the System Monitor or the PodWare application of the status of a device in terms of its ability to perform its
required function.
Using Alarm Incidents, a device may report the current State of a number of critical parameters. The State of each may be one of: Normal, Check or Fault.
The occurrence of one of the latter two is considered to be an Incident. A Check Incident is one where the performance of the product may be impacted, but the device
is attempting to restore full performance without any human intervention.
A Fault Incident is one where the performance of the product is impacted, and the device requires human intervention.
Compatible devices connected on the same network as the System Monitor will have their operational state monitored by the System Monitor. The most serious Alarm
among all the monitored devices determines the overall state of the system as indicated by the System Monitor.
So that an Incident from a device may be temporarily ignored (for example while waiting for the attendance of an engineer), each device has the ability for the current
alarm level to be disabled, whereupon the device no longer reports the alarm, so the incident will not be detected by System Monitor. More serious incidents occurring
subsequently will still be honoured.
The System Monitor itself may generate “local” Alarm Incidents which the PodWare application (or indeed another System Monitor) may detect and indicate.
The network Tree in the PodWare application will also indicate the Alarm states of compatible devices using the convention Green = Normal, Yellow = Check System,
Red = System Fault. Note that some devices may require a  rmware update in order to be compatible with the Alarm system used by System Monitor.
User controls
The control panel in the PodWare application for the System Monitor allows the parameters to be viewed and adjusted. The panel may have one of two di erent
formats: A monitoring panel (the “MonIcon”) where the status of the device and the system may be viewed, or a full control panel where all the controls to adjust
parameters in the System Monitor are located. The full panel has other controls used mainly for setting up.