NOVUS Input Output Module for IoT Application DigiRail OEE User Guide

DIGIRAIL OEE
USER GUIDE V1.2x C

Recommended for devices with firmware version V 1.2x and higher.

SAFETY ALERTS

The symbols below are used in the device and throughout this manual to draw the user’s attention to important information related to device safety and use.

| |
---|---|---
CAUTION
Read the manual fully before installing and
operating the device.| CAUTION OR HAZARD
Risk of electric shock.| ATTENTION
Material sensitive to static charge. Check
precautions before handling.

All safety recommendations appearing in this manual must be followed to ensure personal safety and prevent damage to the instrument or system.
If the instrument is used in a manner other than that specified in this manual, the device’s safety protections may not be effective.

PRESENTATION

DigiRail OEE is the ideal tool to read the sensors that monitor the operation of machines, devices, or processes. Among its many applications, this multi- input module allows you to account operation time and stand-by time and the amount of approved and rejected parts, indicates the need for gpreventive or corrective maintenance, or monitor operating conditions in general.
The device has 6 digital inputs, 2 analog inputs and 2 digital outputs, RS485 interface, USB interface, Wi-Fi or Ethernet communication interface and is compatible with the main clouds on the market. In addition, it can be integrated with MES, SCADA, and ERP systems.
The figure below shows an example of topology for DigiRail OEE:

IDENTIFICATION

DEVICE OVERVIEW

Built in ABS+PC and with IP20 protection rating, DigiRail OEE has high quality housing, three LEDs on its front and a protection cover with detachable faces to pass the sensors, as shown in the figure below:

DEVICE IDENTIFICATION

The identification of the device model is described on the label attached to the back of the housing. This label also provides information on the power supply, MAC address and serial number, as shown in the figure below:

DEVICE MODEL

DigiRail OEE has two models: DigiRail OEE – WRL and DigiRail OEE – ETH. Its features are described in Table 01:

| Digital Input| Analog Input| Digital
Output| USB
Interface| RS485
Communication
Interface| Ethernet
Communication
Interface| Wireless
Communication
Interface
---|---|---|---|---|---|---|---
WRL| 6| 2| 2| 1| 1| x| 1
ETH| 6| 2| 2| 1| 1| 1| x

Table 1- DigiRail OEE models

INSTALLATION

MECHANICAL INSTALLATION

As shown in the figure below, DigiRail OEE can be installed on DIN 35 mm rail. You must fix it with its back clips:

In addition, the device also has two holes to fix it with screws, as shown in the figure below:

DigiRail OEE has a removable protection cover to protect its connection terminals. The protection cover has three detachable areas, one at the bottom and one at each side, so you can easily handle the sensors:

The protection cover has two pins, located on the sides of the housing, which help you fit it into the device. Once the cover has been installed, you will need a screwdriver to remove it.

DIMENSION
DigiRail OEE has the following dimensions:

DigiRail OEE protection cover has the following dimensions:

ELECTRICAL INSTALLATION

DigiRail OEE has three detachable connection terminals to connect the external power supply, RS485, digital inputs and outputs and analog inputs, as shown in the figure below:

To connect the sensors, you must previously remove the connection terminals from the device and observe the enumeration recorded in the housing, as shown in the figure of electrical connections above.
Inputs, outputs and communication interfaces of this device are not isolated from the power supply or from each other.

INSTALLATION RECOMMENDATIONS

• Electronic and analog signal conductors must run through the plant separately from the output and power conductors. If possible, in grounded conduits.
• The power supply for the electronic instruments must come from a proper electrical grid for instrumentation.
• It is recommended to use RC FILTERS (noise suppressors) in contactor coils, solenoids, etc.
• In control applications, it is essential to consider what can happen when any part of the system fails. The device internal security features do not guarantee full protection.
• The electrical connections must be made with the device connection terminals. Before connecting them, make sure that the connections have been made properly.

POWER SUPPLY
The power supply connection is made at the terminals, according to the figure below. You must use a power supply with voltage between 10 and 30 V. You can also use 12 and 24 Vdc power supplies.

DIGITAL INPUT
DigiRail OEE has digital input channels that can be configured in “Counting” or “Event” modes. Regardless of the selected function, you must configure the type of sensor connected to the input: PNP, NPN or Dry Contact. After that, select the edge of the digital signal to generate the count or event: Rising edge, falling edge or both edges.

CORRELATION BETWEEN SENSOR TYPE. SENSOR STATUS AND LOGICAL LEVEL

Sensor Type| Sensor Status| Logical Level
PNP| Open| 0
Closed| 1
NPN| Open| 1
Closed| 0
Dry Contact| Open| 1
Closed| 0

Table 2 – Digital input

ANALOG INPUT
The analog input connection is made at the corresponding terminals, as shown in the figure below:

DIGITAL OUTPUT
The digital output connection is made at the corresponding terminals, as shown in the figure below:

LED INDICATORS

DigiRail OEE has three LEDs, located on the front of the device, as shown in the figure below:

The operation and description of each LED are as follows:

WI-Fl / ETHERNET
CONNECTION
INDICATOR| | On| The connection has been established.
Flashing| The data is being transmitted.
Off| The connection has not been established.
MQTT BROKER
CONNECTION
INDICATOR| | On| The connection has been established.
Flashing| The data is being transmitted.
Off| The connection is disabled or failed when initializing.

Table 3 – LED indicators

COMMUNICATION INTERFACES

USB INTERFACE

DigiRail OEE has a USB port, located on the side of the housing, to configure and perform the device C. You must use a USB cable in the standard micro-USB (not supplied) to connect the device with a desktop or notebook.
When installing the NXperience configuration software, the USB port drivers will be automatically installed (see chapter CONFIGURATION SOFTWARE).

The USB interface is NOT ISOLATED.
It should be used temporarily to CONFIGURE or PERFORM THE DIAGNOSIS of the device.

RS485 INTERFACE

Operating only in Modbus-TCP Gateway mode for Modbus RTU, the RS485 connection interface is located on one of the DigiRail OEE detachable terminals, as shown in the figure below:

The RS485 interface can be configured to operate at the following speeds (Baud Rates): 1200, 2400, 4800, 9600, 19200, 38400, 57600 and 115200. Besides, it can be configured to operate with 1 or 2 Stop Bits and in even parity, odd parity, and no parity. You can configure all these parameters using the NXperience software (see the CONFIGURATION SOFTWARE chapter).
The RS485 interface only works when the DigiRail OEE is connected to an external power supply. It will not operate when the device is being powered only by the USB interface.
The device has an internal 120 ohms termination resistor for the RS485 interface.
The table below shows how to connect the connectors to the RS485 communication interface:

| Inverted bidirectional data line.| Terminal 11
---|---|---
Bidirectional data line.| Terminal 12
Optional connection which improves the communication performance.| Terminal 13

Table 4- RS485 Connections

You can find more details about implementing a device network via RS485 in the document “RS485 and RS422 basics”, available at www.novusautomation.com.

ETHERNET INTERFACE

DigiRail OEE – ETH has an Ethernet interface, located next to the device terminals, as shown in the figure below:

If the Ethernet interface is enabled and the device is connected to an Ethernet network, the LED on the front of the device remains on. This LED will remain on and flashing if data is being sent over this interface.

WI-FI INTERFACE

DigiRail OEE – WRL has an 802.11 Wi-Fi interface in b/g/n 2.4 GHz standards, operating through an internal antenna. This interface supports
WPA-Personal (PSK) WPA/WPA2 TKIP/AES/TKIP and AES encryption.
If the Wi-Fi interface is enabled and the device is connected to a Wi-Fi network, the LED on the front of the device remains on. This LED will remain on and flashing if data is being sent over this interface.

MQTT PROTOCOL

DigiRail OEE is compatible with Message Queue Telemetry Transport (MQTT) protocol, which allows publishing data in the cloud, and supports the following MQTT Brokers: Google Cloud, Microsoft Azure, AWS, NOVUS Cloud, LiveMES, Mina and generic MQTT Brokers.
This chapter describes the structure of the data published in the cloud and introduces the structure to send settings to the device.

PUBLICATION AND SUBSCRIPTION TOPICS

As described below, DigiRail OEE uses five topics for operation:

• Topic to publish periodic data and events: Used to publish data generated on the device, i.e., the logs. There are two types: channel and events.
• Topic to receive the configuration: Used to receive configuration data. The device subscribes to this topic to receive configuration data. For each configuration received, a confirmation reply is published in the configuration confirmation topic.
• Topic to confirm the configuration: The device publishes the current configuration in this topic. Every time a configuration is received, the device publishes a confirmation in this topic. After a configuration is applied to the device, the current configuration is also published in this topic.
• Topic to receive commands: Used to receive commands. The device subscribes to this topic to receive commands and signals the execution of a command by publishing in the command confirmation topic.
• Topic to confirm the command: The device publishes the result of commands executed in this topic.

Examples of topics for a generic Broker:

Table 5 – Topics for a generic Broker

TRANSMISSION MODEL FOR DATA AND EVENTS

The publication of events and data generated by the device follows the standard MQTT model and uses a topic defined during configuration.

DATA AND EVENTS
The data will be published in the topic defined for the publication of periodic data and events. The type of data is indicated in the JSON message.
For all data, the timestamps used are in Unix timestamp UTC format (GMT 0).

CHANNEL DATA
The channel data is published periodically, according to the device configuration. The data is in JSON format and has the following key/value sets:
Notes:

• device0 is configurable in the Device ID parameter of the MQTT configuration tab of the NXperience configurator software.
• The timestamp value is the timestamp in Unix UTC format at the time the device reads the channel.
• chdX_value corresponds to the information of the digital channels at the time of timestamp. If the channel is not enabled, it will not appear in the JSON. If the channel is in “Register” mode, the value will correspond to the logical level of the digital channel at that moment. If the channel is in “Counting” mode, the value will correspond to the counter value at that time.
• chX_user_range informs the value of the analog input in the range configured by the user and at the time of the timestamp. If the analog channel is not enabled, it will not appear in the JSON.

EVENTS
When the digital channel is configured in “Event” mode and an event occurs, an event type message will be generated, indicating the channel, the timestamp, and the edge where it occurred. The data are in JSON format and have the following key/value sets:

Notes:

• The timestamp value is also in Unix timestamp format in UTC (GMT 0), but the milliseconds of the event have been added as fractional part.
• Regarding the edge value: “1” means that the event occurred on a rising edge. “0” means that the event occurred on a falling edge.

CONFIGURATION

Some sets of device configuration can be changed or consulted via MQTT when publishing in the topic to receive device configuration. A confirmation of this publication is received in the configuration confirmation topic.
The available configuration items for this device type are:

chd5 and chd6).
Periodic counter reset| Configuration of the digital counters reset periodicity.
chX| Configuration of the analog channel ‘X’ (Available: ch1 and ch2).
eth| Ethernet interface configuration (When available).
wifi| Wi-Fi interface configuration (When available).
modbus-tcp| Modbus-TCP protocol configuration.
rs485| RS485 interface configuration.

Table 6 – Configuration item

TRANSMITTION MODEL FOR CONFIGURATIONS AND COMMANDS
The basic operating model of the commands and configurations was developed to allow synchronization of the device settings and conditions with the cloud.
In this model there are two basic concepts:

• Desired properties: These are the conditions and configurations that the backend application can change or query on the device with which it interacts.
• Reported properties: These are the properties used as a response to receive Desired properties, where the device reports its status or the result of a command.

This message exchange model needs two different topics to work. The first is the topic in which the device is subscribed to receive the Desired properties. This step, initiated by the application, is called “request”. The device uses the second topic to publish the Reported properties after the command or configuration is executed. This step is called “response”.
For details on sending configurations via MQTT to DigiRail OEE, you should refer to the MQTT Protocol document available on the product page on NOVUS website.

COMMANDS

Following the same model of sending settings, the commands must be published in the Topic to receive commands. The type of data is indicated in the JSON message. The return of the command execution is done through the Topic to confirm the command.

The available commands for DigiRail OEE are:

• Output: Used to obtain or modify the digital outputs status.
• Reset counters: Used to apply a reset to the digital counters.
• Set Counters: Used to change the value of the digital channel counters.
• Get diagnostic: Used to obtain diagnostic data from the device.

OUTPUT
This command modifies the device output status.
FORMAT OF THE OUTPUT COMMAND TO MODIFY THE OUTPUT STATUS:
It is not necessary to publish the status that will not be modified.
FORMAT OF THE COMMAND OUTPUT RESPONSE:
Notes:

• The timestamp is the same as the command received (desired).
• The status described in the desired step will only be applied if the execution is done without errors.
• The value shown in the error field is an integer and reports the first error found in the execution of the command, as shown in the error codes table below:
  CODE| DESCRIPTION
  ---|---
  Error 0| Success.
  Error 1| The structure is correct, but the device has received an out-of-range parameter.
  Error 2| The structure is correct, but the device has received an unknown parameter.

Table 7 – Error codes

There are, however, unanswered error cases from the device, as shown below:

• * The JSON structure is wrong.

  • The structure is right, but some element is missing (timestamp, desired, item).
    In case of error, none of the parameters will be accepted and the device will not go into configuration mode.

• If the command has failed, the status indicated in reported will be the current ones.

This command can also be used to consult the status of the device outputs when sent with the format provided below.
FORMAT OF THE OUTPUT COMMAND TO OBTAIN THE OUTPUT STATUS:

THE FORMAT OF THE RESPONSE TO OBTAIN THE OUTPUT STATUS IS THE SAME FORMAT AS THE RESPONSE TO THE COMMAND TO MODIFY THEM:

RESET COUNTERS
The reset counters command is used so that the application can reset the digital channels counters. A digital channel needs to have MQTT enabled for it to be restarted through this interface.
The structure used for this command follows the same model as for sending configurations, using the concepts of “desired” and “reported”. The reset_chdX value can assume values of 0 or 1. The value of “1” indicates that a reset is to be applied to the counter of the corresponding digital channel. The value “0” indicates that the counter should not be changed. In this case, it is also possible to simply omit the JSON channel.

REQUEST RESET COUNTERS:

RESPONSE RESET COUNTERS:

Notes:

• The timestamp is the same as the command received (desired).
• The status described in the desired step will only be applied if the execution is done without errors.
• The error value is an integer and reports the error found during the command execution.
• In this example, digital channels 1, 3, 5 and 6 do not appear in the JSON desired since you do not want to reset their counters.

SET COUNTERS
The set counters command is used so that the application can change the value of the digital channel counters. You must enable the permission to change the configuration through MQTT to modify a digital channel through this interface.
The structure of this command follows the same model as for sending settings, using the “desired” and “reported” concepts.
The set_chdX can assume any value between 0 and X. If the setting allows it, the channel will immediately assume the defined value when sending the value on the set_chdX field. You must omit the channel from the JSON in order not to change the counter value of a channel.

REQUEST SET COUNTERS:

RESPONSE SET COUNTERS:

Notes:

• The timestamp is the same as the command received (desired).
• The status described in the desired step will only be applied if the execution is done without errors.
• The error value is an integer and reports the error found during the command execution.
• In this example, digital channels 1, 4, 5 and 6 do not appear in the JSON desired since you do not want to change their counters. In the response, the current value of the digital channel will be returned. For digital channels 1, 4, 5 and 6 the current value is assumed to be zero.

GET DIAGNOSTIC
The get diagnostic command returns diagnostic data from the device.

REQUEST GET DIAGNOSTIC:

RESPONSE GET DIAGNOSTIC:

If the Publish Diagnostics Periodically parameter of the NXperience configuration software (see the MQTT PROTOCOL section of the CONFIGURATION SOFTWARE chapter) is enabled, the system event occurrence counters will also be added to the response:

Notes:

• The title and location fields are defined in the general configuration frame of the configurator software.
• The curr_timestamp field presents the current timestamp of the device, i.e., obtained from its internal clock and is in Unix timestamp UTC format.
• The cfg_timestamp field presents the timestamp of the last configuration applied to the device and is also in Unix timestamp UTC format.
• The fw_v field presents the firmware version of the device.
• The mqtt_queue field presents the number of logs pending sending via MQTT.
• The sn field presents the serial number of the device.
• The curr_rssi field informs the quality of the Wi-Fi signal, which is measured instantaneously. The value is shown as a percentage. Thus, the higher the  value, the better the signal. The min_rssi, max_rssi, and avg_rssi fields complement the diagnosis of the Wi-Fi signal quality, returning the minimum, maximum, and average value, respectively.
• The ipv4 field informs the IP of the device on the network.
• The log_counters field informs the number of occurrences of each system log event.
• The watchdog_counter field informs the number of occurrences of each system Watchdog event.

GATEWAY MQTT RS485
Sending packets through the RS485 serial interface via MQTT allows you to read data from a local network (Modbus RTU, for example) and send commands remotely via the MQTT protocol. In this case, DigiRail OEE operates as a Gateway, communicating with the slave devices through the RS485 serial interface.
To send commands remotely, it is necessary to connect another MQTT client to the Broker to which DigiRail OEE is connected and, in the sequence, register in the topic configured for command confirmation. The command must then be published in the topic configured in DigiRail OEE to receive commands.
Modbus RTU commands can be published in hexadecimal format with the following structure:

Below is an example of a message to be published in the command sending topic:
In sequence, the response received through the RS485 serial interface will be published by DigiRail OEE in the topic assigned to the commands confirmation, following the format:

An example message that could be received in the command confirmation topic:

RESET DIAGNOSTIC
The reset diagnostic command is used so that the application can reset counters related to internal system events and Wi-Fi signal quality (RSSI) measurement data.
The structure used for this command follows the same model as for sending configurations and uses the concepts of “desired” and “reported”.
The values of the reset_watchdog_counter, reset_x_counter and reset_diag_rssi fields can have values of 0 or 1. The value
“1” means that a reset is to be applied to the corresponding parameter. The value “0” indicates that the parameter should not be changed. In this case you can also simply omit the JSON channel.

REQUEST RESET DIAGNOSTIC:

RESPONSE RESET DIAGNOSTIC:

Notes:

• The timestamp is the same as the received command (desired).
• The status described in desired will only be applied if execution is done without errors.
• The value of error is an integer and reports the error encountered during the execution of the command.

LOGS
The logs command returns the last 50 log events from the system. All events will have an ID, which can be queried with this command, and a timestamp of the occurrence. You can see a detailed description of the log in Table 8.

REQUEST LOGS:

RESPONSE LOGS:

LOGS_PARSED
Due to device memory limitations, the logs_parsed command returns only the last 30 system log events. However, instead of giving an ID, there will be a short description of the log, plus the timestamp of the occurrence, like the logs command. You can see a detailed description of the log in Table 8.

REQUEST LOGS_PARSED:

RESPONSE LOGS_PARSED:

The table below shows a detailed description of the logs:

interval.
14| mqtt| default_int| Publish interval has been changed to a default interval.
15| dns| error _1| DNS internal error – Phase 1.
16| dns| error_2| DNS internal error – Phase 2.
17| dns| error_3| DNS internal error – Phase 3.
18| mem| init _error| There was an error during the circular buffer initialization. Device has recovered.
19| mem| not_init| The circular buffer has not been initialized.
20| mem| read_error| There was a failure while reading the circular buffer.
21| cfg| updated| Device configuration updated.
22| fw| updated| Device firmware updated.

MODBUS-TCP PROTOCOL

DigiRail OEE is compatible with the Modbus-TCP protocol, a data communication protocol used to connect the device to supervisory control and data acquisition (SCADA) systems. It supports up to 3 simultaneous connections and allows up to 3 Modbus-TCP clients (masters) to monitor it at the same time. DigiRail OEE operates both as a Modbus-TCP server (slave) and as a TCP/RTU gateway.
As a server (slave), it responds to the configured Modbus RTU address. For address that diverge from the configured address value, it will operate as a TCP/RTU gateway. In this case, the packed will be sent to the RS485 interface and, if there is a reply from any Modbus RTU slave, replied to the Modbus-RTU client (master) that generated the request.
For more information about Modbus-TCP protocol, you should refer to the Modbus-TCP Protocol document available on the product page on NOVUS website.

COMMANDS

READ HOLDING REGISTERS – 0x03:
This command can be used to read the value of one or up to a maximum of 125 consecutive registers, according to the table below.

WRITE HOLDING REGISTERS – 0x06:
This command can be used to write in a register, according to the table below.

WRITE MULTIPLE HOLDING REGISTERS – 0x16:
This command can be used to write in multiple registers, according to the table below.

REGISTERS TABLE

Below is the table of registers supported by the device:

ADDRESS| REGISTER| DESCRIPTION| MINIMUM
VALUE| MAXIMUM
VALUE| TYPE
---|---|---|---|---|---
1| HR PRODUCT CODE| Product code.| 510| 510| RO
2| HR_SERIAL_NUMBER_H| Serial number (32bits).| 0x0000| OxFFFF| RO
3| HR_SERIAL_NUMBER_L| Ox0000| OxFFFF| RO
4| HR_FIRMWARE_VERSION| Version firmware x 100.| 100| 65535| RO
| | Reserved.| | |
6| HR_MAC_ADDR_O_1| MAC Address. Hexadecimal format with 2 numbers per register. 0 : 1 : 2 : 3 : 4 : 5| 0x0000| OxFFFF| RO
7| HR_MAC_ADDR_2_3| 0x0000| OxFFFF| RO
8| HR_MAC_ADDR_4_5| Ox0000| OxFFFF| RO
| | Reserved.| | |
10| HR_USB_STATUS| USB interface status:
0 → Disconnected
1 → Connected| 0| 1| RO
| | Reserved.| | |
13| HR_NUMBER_OF_ACTIVECH| Number of enabled analog channels.| | | –;,.
14| HR_NUMBER_OF_ACTIVE_CHD| Number of enabled digital channels.| | |
15| HR_RESET_COUNTERS| Reset of digital channel counters.
Note: Write 1 resets all the digital counters that are configured to be reset by Modbus-TCP and MATT.| | |
16| HR_PWR_STATUS| Power supply status:
0 → Powered by the USB interface
1 → Powered by external supply| | |
17| HR_STATUS_OF_RECORDS| Number of registers pending submission via MATT protocol.| | |
| | Reserved.| | |
20| HR_LAST_CONFIG_YEAR,| Year of the last configuration.| 2016| 2080| RO
21| HR_LAST_CONFIG_MONTH,| Month of the last configuration.| 1| 12| RO
22| HR_LAST_CONFIG_DAY,| Day of the last configuration.| 1| 31| RO
23| HR_LAST_CONFIG_HOUR,| Hour of the last configuration.| 0| 23| RO
24| HR_LAST_CONFIG_MINUTE,| Minute of the last configuration.| 0| 59| RO
25| HR_LAST_CONFIG_SECOND| Second of the last configuration.| 0| 59| RO
26| HR_CURRENT_YEAR| Current year.| 2016| 2080| RO
27| HR_CURRENT_MONTH| Current month.| 1| 12| RO
28| HR_CURRENT_DAY| Current day.| 1| 31| RO
29| HR_CURRENT_HOUR| Current hour.| 0| 23| RO
30| HR_CURRENT_MINUTE| Current minute.| 0| 59| RO
31| HR_CURRENT_SECOND| Current second.| 0| 59| RO
| | Reserved.| | |
34| HR_RESET_COUNTER_CHD1| Resets the digital channel counter 1.
Note: Write 1 resets the counter for this channel if it is configured to allow reset via Modbus-TCP and MQTT protocols.| 0| 1| RW
35| HR_RESET_COUNTER_CHD2| Resets the digital channel counter 2.
Note: Write 1 resets the counter for this channel if it is configured to allow reset via Modbus-TCP and MQTT protocols.| 0| 1| RW
36| HR_RESET_COUNTER_CHD3| Resets the digital channel counter 3.
Note: Write 1 resets the counter for this channel if it is configured to allow reset via Modbus-TCP and MQTT protocols.| 0| 1| RW
37| HR_RESET_COUNTER_CHD4| Resets the digital channel counter 4.
Note: Write 1 resets the counter for this channel if it is configured to allow reset via Modbus-TCP and MQTT protocols.| 0| 1| RW
38| HR_RESET_COUNTER_CHD5| Resets the digital channel counter 5.
Note: Write 1 resets the counter for this channel if it is configured to allow reset via Modbus-TCP and MQTT protocols.| 0| 1| RW
39| HR_RESET_COUNTER_CHD6| Resets the digital channel counter 6.
Note: Write 1 resets the counter for this channel if it is configured to allow reset via Modbus-TCP and MQTT protocols.| 0| 1| RW
| | Reserved.| | |
41| HR_DIGITAL_OUT1_VALUE| Digital output status and control:
0 → OFF
1 → ON
Allows you to read and write to the output.| 0| 1| RW
42| HR_DIGITAL_OUT2_VALUE| Digital output status and control:
0 → OFF
1 → ON
Allows you to read and write to the output.| 0| 1| RW
| | Reserved.| | |
45| HR_CHD1_STATUS| Digital channel status:
0 → Not configured
1 → OK
2 → The configuration has an error| | |
46| HR_CHD1_VALUE_HIGH| Counter value in 32-bit.| 0| 65535| RO
47| HR_CHD1_VALUE_LOW| 0| 65535| RO
48| HR_CHD1_TIME_STAMP_LAST_HIGH| Last event timestamp. 32-bit. Unix format.| 0x0000| 0xFFFF| RO
49| HR_CHD1_TIME_STAMP_LAST_LOW| 0x0000| 0xFFFF| RO
| | Reserved.| | |
56| HR_CHD2_STATUS| Digital channel status:
0 → Not configured
1 → OK
2 → The configuration has an error| 0| 2| RO
57| HR_CHD2_VALUE_HIGH| Counter value in 32-bit.| 0| 65535| RO
58| HR_CHD2_VALUE_LOW| 0| 65535| RO
59| HR_CHD2_TIME_STAMP_LAST_HIGH| Last event timestamp. 32-bit. Unix format.| 0x0000| 0xFFFF| RO
60| HR_CHD2_TIME_STAMP_LAST_LOW| 0x0000| 0xFFFF| RO
| | Reserved.| | |
67| HR_CHD3_STATUS| Digital channel status:| 0| 2| RO
| | 0 → Not configured
1 → OK
2 → The configuration has an error| | |
68| HR_CHD3_VALUE_HIGH| Counter value in 32-bit.| 0| 65535| RO
69| HRCHD3_VALUELOW| 0| 65535| RO
70| HRCHD3_TIME_STAMP LAST HIGH| Last event timestamp. 32-bit. Unix format.| Ox0000| OxFFFF| RO
71| HRCHD3TIME_STAMP LAST LOW| Ox0000| OxFFFF| RO
| | Reserved.| | |
78| HR_CHD4_STATUS| Digital channel status:
0 → Not configured
1 → OK
2 → The configuration has an error| 0| 2|
79| HRCHD4yALULHIGH| Counter value in 32-bit.| 0| 65535| RO
80| HRCHD4_VALUE_LOW| 0| 65535| RO
81| HR_CHD4_TIMESTAMP LAST HIGH| Last event timestamp. 32-bit. Uri& format.| Ox0000| OxFFFF| RO
82| HRCHD4 TIME STAMP LAST LOW| Ox0000| OxFFFF| RO
| | Reserved.| | |
89| HRCHD5_STATUS| Digital channel status:
0 → Not configured
1→ OK
2 → The configuration has an error| 0| 2| RO
90| HR CHD5 VALUE HIGH| Counter value in 32-bit.| 0| 65535| RO
91| HRCHD5VALUE_LOW| 0| 65535| RO
92| HR_CHD5_TIMESTAMP LAST HIGH| Last event timestamp. 32-bit. lit format.| Ox0000| OxFFFF| RO
93| HRCHD5_TIME_STAMP LAST LOW| Ox0000| OxFFFF| RO
| | Reserved.| | |
100| HR_CHD6_STATLIS| Digital channel status:
0 → Not configured
1 → OK
2 → The configuration has an error| 0| 2| RO
101| HRCHD6_VALUE_HIGH| Counter value in 32-bit.| 0| 65535| RO
102| HRCHD6_VALUE_LOW| 0| 65535| RO
103| HRCHD6_TIME_STAMP_LAST_H1GH| Last event timestamp. 32-bit. Unbc format.| 0x0000| OxFFFF| RO
104| HRCHD6TIMESTAMP LAST LOW| 0x0000| OxFFFF| RO
| | Reserved.| | |
109| HR_CHlSTATUS| Analog channel 1 status:
0 → Not configured
1 → OK
2 → The configuration has an error| C| |
| | Reserved.| | |
111| HRCHl_MV_MA_VALUEH| Value in the unit of measurement (mA or V). Float 32-bit format.| Ox0000| OxFFFF| RO
112| HRCHl_MV_MA_VALUE_L| 0x0000| OxFFFF| RO
113| HR_CHl_SENSE_USER_RANGE_H| Value in user range. Float 32-bit format.
Note: This is the same value as the cloud publication.| Ox0000| OxFFFF| RO
114| HRCHlSENSE_USER_RANGE_L| Ox0000| OxFFFF| RO
| | | | |
120| FIRCH2STATUS| Analog channel 2 status: 0 3 Not configured
1 → OK
2 → The configuration has an error| 0| ,1| RO
| | Reserved.| | |
122| HRCH2_MV_MA_VALUEI-1| Value in the unit of measurement (mA or V). Float 32-bit format.| 0x0000| OxFFFF| RO
123| HRCH2_MVMA_VALUEL| Ox0000| OxFFFF| RO
124| HR_CH2_SENSE_USER_RANGE_H| Value in user range. Float 32-bit format.| Ox0000| OxFFFF| RO
125| HR_CH2_SENSE_USER_RANGEL| Note: This is the same value as the cloud publication.| 0x0000| OxFFFF| RO
| | Reserved.| | |
130| HR_MOTT_LAST_UPDATE_YEAR| Year of last sending to the MOTT Broker.| | 1| RO
131| HRMOTT_LAST_UPDATE_MONTH| Month of the last sending to the MOTT Broker.| 1| 12| RO
132| HRMOTT_LASTUPDATEDAY| Day of the last sending to the MOTT Broker.| 1| 31| RO
133| HRMOTT_LASTUPDATEHOUR| Time of the last sending to the MOTT Broker.| 0| 23| RO
134| HR_MOTT_LAST_UPDATE_MINUTE| Minute of the last sending to the MOTT Broker.| 0| 59| RO
135| HR_MOTT_LAST_UPDATE_SECOND| Second of the last sending to the MOTT Broker.| 0| 59| RO
136| HR_MOTT_STATUS _BROKER| Communication status with the MOTT Broker:
0 → Broker disconnected
1 → Broker connected
2 → DNS problem
3 → Broker error
4 → Connecting to the Broker| | 4| RO
| | Reserved.| | |
139| HR_WIFI_RSSI| Signal quality between the device and the Wi-Fi Gateway displayed in percent The higher the value. the better the signal.| 0| 65535| RO
| | Reserved.| | |
| HR_LAN_GATEWAY_COM _STATUS| ETH communication status: 0 4 Gateway disconnected 14 Gateway connected
2 → Wi-Fi provisioning error
3 → Obtaining IP via DHCP
4 → Error obtaining P via DHCP| 0| 4| RO
142| HR_LAN_IP_ADDR0_1| IP v4 address. Two octets per register. Dec 0 . Dec 1 . Dec 2 . Dec 3| 0| 65535| RO
143| HR LAN JP_ADDR2_3| 0| 65535| RO
144| HR_LAN_MASK_ADDR_0_1| M ask. Two octets per register. Dec 0 . Dec 1 . Dec 2 . Dec 3| 0| 65535| RO
145| HR_LAN_MASK_ADDR_2_3| 0| 65535| RO
146| HR_LANGATEWAY_ADDR_0_1| G ateway. Two octets per register. Dec 0 . Dec 1 . Dec 2 . Dec 3| 0| 65535| RO
147| HR_LAN_GATEWAY_ADDR_2_3| 0| 65535| RO
148| HRLANDNSADDR0_1| DNS server IP. Two octets per register. Dec 0 . Dec 1 . Dec 2 . Dec 3| 0| 65535| RO
149| HR_LAN_DNS_ADDR_2_3| 0| 65535| RO
| | Reserved.| | |
151| HR_LAN_IPV6_ADDR0_1.| IPv6 address – Local. Hexadecimal format.
0_1 : 2_3 : 4_5 : 6_7 : 8_9 : 10_11 : 12_13 :| 0| 65535| RO
152| HRLAN_IPV6ADDR_2_3.| 0| 65535| RO
153| HRLAN_IPV6_ADDR45.| 0| 65535| RO
154| HR LAN IPV6 ADDR 6 7
– – – – – •| 0| 65535| RO
155| HR_LAN_IPV6_ADDR_8_9.| 0| 65535| RO
156| HR_LAN_IPV6_ADDR_10_11.| 0| 65535| RO
157| HR_LAN_IPV6_ADDR_12_13.| 0| 65535| RO
158| HRLANIPV6ADDR_14_15.| 0| 65535| RO
159| HR_LAN_IPV6_GLOBAL_ADDR_O_I.| IPV6 address – Global. Hexadecimal format.
0_1 : 2_3 : 4_5 : 6_7 : 8_9 : 10_11 : 12_13 :| 0| 65535| RO
160| HR LAN IPV6_GLOBAL_ADDR_2_3.| 0| 65535| RO
161| HR_LAN_IPV6_GLOBAL_ADDR_4_5.| 0| 65535| RO
162| HR_LAN_IPV6_GLOBAL_ADDR_6_7.| 0| 65535| RO
163| HR_LAN_IPV6_GLOBAL_ADDR_89.| 0| 65535| RO
164| HR LAN IPV6 GLOBAL ADDR 10 11
_ .| 0| 65535| RO
165| HR_LAN_IPV6_GLOBAL_ADDR_12_13.| 0| 65535| RO
166| HR_LAN_IPV6_GLOBALADDR_14_15.| 0| 65535| RO
167| HR_CHD1_LEVEL.| Logical level of digital input 1.| 0| 1| RO
168| HR_CHD2_LEVEL.| Logical level of digital input 2.| 0| 1| RO
169| HRCHD3_LEVEL.| Logical level of digital input 3.| 0| 1| RO
170| HR_CHD4_LEVEL.| Logical level of digital input 4.| 0| 1| RO
171| HRCHD5_LEVEL.| Logical level of digital input 5.| 0| | RO
172| HRCHD6_LEVEL.| Logical level of digital input 6.| 0| 1| RO
173| | Reserved.| | |
174| HR_CHD1SETVALUE_H| Changes the value of the 32-bit counter for channel 1.| 0| 65535| RW
175| HRCHD1SETVALUEL| 0| 65535| RW
176| HRCHD2SETVALUEH| Changes the value of the 32-bit counter for channel 2.| 0| 65535| RW
177| HRCHD2SETVALUEL| 0| 65535| RW
178| HR_CHD3SETVALUE_H| Changes the value of the 32-bit counter for channel 3.| 0| 65535| RW
179| HR_CHD3SETVALUEL| 0| 65535| RW
180| HR_CHD4SETVALUEH| Changes the value of the 32-bit counter for channel 4.| 0| 65535| RW
181| HRCHD4_SETVALUE_L.| 0| 65535| RW
182| HRCHD5SETVALUE_H| Changes the value of the 32-bit counter for channel 5.| 0| 65535| RW
183| HRCHD5SETVALUEL| 0| 65535| RW
184| HR_CHD6_SETVALUE_H| Changes the value of the 32-bit counter for channel 6.| 0| 65535| RW
185| HRCHD6SETVALUEL| 0| 65535| RW
186| | Reserved.| | |
187| HR OTTY _SSCOLLECT_RECORDMAX| Maximum number of downloads supported by memory.| 1824| 7096| RO
188| HRSSCOLLECT_LASTRECORD| Position of the last download added to memory.| 0| 7096| RO
189| HRSS_COLLECT_F1RST_RECORD| Position of the first download added to memory.| 0| 7096| RO
190| HR_SS_COLLECTREOUESTED RECORD| Position of the download requested for reading.| 0| 7096| RW
191| HR_SSCOLLECT_TIMESTAMPUNIX_H| Timestamp of the requested download in Unix format.| 0| 65535| RO
192| HR_SS_COLLECT_TIMESTAMPUNIX_L| 0| 65535| RO
193| HRSS_COLLECT_TIMESTAMP_MS| Timestamp of the requested download in milliseconds.| 0| 65535| RO
194| HR_SS_COLLECT_CHD 1E , r ‘ .- INDEX| When an event occurs in the requested download, returns the index  of the digital channel:
0 3 No event. It is a periodic log
1 → Event on channel 1
2 → Event on channel 2
3 → Event on channel 3
4 → Event on channel 4
5 → Event on channel 5
6 → Event on channel 6| 0| 6| RO
195| HR_SS_COLLECT_CHD_EVENT_TYPE| When an event occurs in the requested download, returns the event type:
0 → No event. It is a periodic log
1 → Falling edge event of the digital channel
2 → Rising edge event of the digital channel| 0| 2| RO
196| HR_SSCOLLECTCHDI_VALUE_H| Value of digital channel 1 in the requested download.| 0| 65535| RO
197| HRSS_COLLECT_CHDl_VALUE_L| 0| 65535| RO
198| HR_SSCOLLECTCHINVALUE_H| Value of digital channel 2 in the requested download.| 0| 65535| RO
199| HR_SS_COLLECT_CHD2_VALUE_L| 0| 65535| RO
200| HR_SS_COLLECTCHD3_VALUE_H| Value of digital channel 3 in the requested download.| 0| 65535| RO
201| HR_SS_COLLECT_CHD3_VALUEL| 0| 65535| RO
202| HRSSCOLLECTCHD4_VALUE_H| Value of digital channel 4 in the requested download.| 0| 65535| RO
203| HRSSCOLLECTCHD4VALUEL| 0| 65535| RO
204| HR_SSCOLLECT_CHD5_VALUE_H| Value of digital channel 5 in the requested download| 0| 65535| RO
205| HR_SS_COLLECT_CHD5_VALUE_L| 0| 65535| RO
206| HR SS COLLECT CHD6 VALUE H| Value of digital channel 6 in the requested download.| 0| 65535| RO
207| HR SS COLLECT CHD6 VALUE L| 0| 65535| RO
208| HR_SS_COLLECT_CH1_SENSE __USER
RANGE_H| Displays the sensor value in the user range of analog channel 1 (in Float).| 0| 65535| RO
209| HR_SS_COLLECT_CHl_SENSEUSER RANGE_L| 0| 65535| RO
210| HIR_SS_COLLECTCH2SENSE _USER
RANGE_H| Displays the sensor value in the user range of analog channel 2 (in Float).| | 65535| RO
211| HR -GE SS COLLECT CH2 SENSE USER
– – – –
RAN L
I| 0| 65535| RO
| | Reserved.| | |
216| HR_SS_WIFI_RSSI_MIN| Minimum value indicated by the HR IMFI RSSI register. You can reset the value using the HR_RESELDIA-G_RSSI register.| 0| 65535| 50
217| HR_SS_WIFI_RSSI_MAX| Maximum value indicated by the HR WIFI RSSI register. You can reset the value using the HR_RESETTDIAG_RSSI register.| 0| 65535| RO
218| HR_SS_WIFI_RSSI_AVERAGE| Average value indicated by the HR WIFI RSSI register. You can reset the value using the HR_RESELDIA-G_RSSI register.| 0| 65535| 50
| | Reserved.| | |
221| HRRESET_COUNTER_WDT| Resets the system Watchdog diagnostic counters.| 0| 1| RW
222| HR_RESET_COUNTERLOGS| Resets the system logs diagnostic counters.| 0| 1| RW
223| HR RESET DIAG RSSI
–| Resets the minimum. maximum and average signal quality (RSSI) measurement| 0| 1| RW

Table 9 – Registers table

CONFIGURATION SOFTWARE

NXperience software is the main tool to configure and perform the DigiRail OEE diagnosis and allows you to explore all the device features, communicating through its USB interface or via Modbus-TCP. However, NXperience is not a supervisory system and has no MQTT Broker functionality. You must use appropriate systems for the application to enjoy all the benefits provided by the device.
This manual describes the generic functionalities of the software. For more information, check the specific operations manual. The software can be
downloaded free of charge from our website www.novusautomation.com, in the Download Area.

CONFIGURING DIGIRAIL OEE WITH NXPERIENCE

You can configure DigiRail OEE by clicking the Configure button, located on the NXperience home screen. The following sections describe each of the parameters that can be configured and their particularities.

GENERAL SETTINGS

INFORMATION

• Device Tag: Allows you to configure a tag for the device. The field allows up to 20 characters.
• Location: Allows you to inform the place where the device has been positioned. The field allows up to 40 characters.
• Serial Number: Displays the device serial number.
• Model: Displays the device model.
• Firmware Version: Displays the device firmware version.
• MAC Address: Displays the device MAC address.

CLOUD APPLICATION

• Cloud Type: Allows you to configure the type of cloud to be used: Generic, LiveMES or MInA. By selecting the “LiveMES” or “MInA” option, besides configuring the device with the LiveMES or Mina communication standards, it is possible to leave the options “Configure channels defaults” and/or “Configure the publishing interval defaults” checked, to apply the settings for these cloud types, as shown in the figure below:

CLOCK

• Date/Time: Displays the date and time of the Windows system, which will be used by NXperience to set the device clock when sending the configuration.
• GMT: Allows you to configure the GMT of the place where the device will be used (preferably during the first use).
• NTP Server: Once enabled, allows you to perform automatic clock synchronization through an NTP server.
  o Address: If the “NTP Server” option is enabled, allows you to set an address for the NTP server and thus update the clock automatically.
  o Difference to update: If the “NTP Server” option is enabled, the clock will be updated whenever the difference between the clock of the
  NTP server and the device are greater than the value set in the parameter.

COMMUNICATION
This screen is divided into the following tabs: Ethernet or Wi-Fi, Modbus-TCP Protocol, MQTT Protocol, and RS485.

ETHERNET
This tab is specific to DigiRail OEE – ETH model.

• Obtaining Address: Allows you to configure the way in which DigiRail OEE – ETH will acquire an IP: DHCP (Dynamic Host Configuration
  Protocol), protocol that allows the IP address (Internet Protocol) to be assigned by the network server, or Static, which allows the user to define the IP address, the subnet mask, and the default gateway for the connection. In this case, it is also necessary to define the DNS (Domain Name System) server. By default, the device is configured with the “DHCP” setting.

• IPv4 Configuration:

  • IP Address: Allows you to configure the IP address. This parameter refers to the identification of the device in a local or public network. Each computer or device on the Internet or in an internal network has a unique IP. It is a mandatory field when the Obtaining Address parameter is set to “Static”.
  • Network Mask: Allows you to configure the network mask. This parameter allows you to divide a specific network into smaller subnets, optimizing the use of a certain IP range. It is a mandatory field when the Obtaining Address parameter is set to “Static”.
  • Default Gateway: Allows you to define the gateway to be used. This parameter refers to the address that connects the device to the Internet. It is a mandatory field when the Obtaining Address parameter is set to “Static”.
  • DNS Server: Allows you to define the DNS server. This parameter refers to a hierarchical and distributed name management system for computers, services or any resource connected to the Internet or to a private network. It is a mandatory field when the Obtaining Address parameter is set to “Static”.

• IPv6 Configuration:

  • IP Address: Allows you to configure the IPv6 address. This parameter refers to the identification of the device in a local or public network. Each computer or device on the Internet or in an internal network has a unique IP. It is a mandatory field when the Obtaining Address parameter is set to “Static”.
  • DNS Server: Allows you to configure the DNS server. This parameter refers to a hierarchical and distributed name management system for computers, services or any resource connected to the Internet or to a private network. It is a mandatory field when the Obtaining Address parameter is set to “Static”.
  • Prefix: Allows you to configure the prefix to be used.

WI-FI
This tab is specific to DigiRail OEE – WRL model.

• Wi-Fi Configuration:

  • Access Point SSID: Allows you to enter the name of the Wi-Fi network to which DigiRail OEE – WRL will try to connect to. The field  allows up to 32 alphanumeric characters.
  • Access Point Password: Allows you to enter the Wi-Fi network password to which DigiRail OEE – WRL will try to connect to. The  ield
    allows up to 21 alphanumeric characters. From firmware version 1.02 forward, DigiRail OEE leaves the factory pre-configured to connect to an Access Point with SSID “DROEE” and password “digirail-oee”. If the user has several DigiRail OEE to configure, simply configure an Access Point with that SSID and password (or put the smartphone to route the Wi-Fi) so that they all connect. This way, the user will not need to configure each of the devices through the USB interface. A new SSID and password configuration can be done either by USB or by Modbus TCP, through the NXperience software, or even through the MQTT protocol.

• Obtaining Address: Allows you to configure the way in which DigiRail OEE – WRL will acquire an IP: DHCP (Dynamic Host Configuration Protocol), protocol that allows the IP address (Internet Protocol) to be assigned by the network server, or Static, which allows the user to  efine
  the IP address, the subnet mask, and the default gateway for the connection. In this case, it is also necessary to define the DNS (Domain Name System) server. By default, the device is configured with the “DHCP” setting.

• IPv4 Configuration:

  • IP Address: Allows you to configure the IP address. This parameter refers to the identification of the device in a local or public network. Each computer or device on the Internet or in an internal network has a unique IP. It is a mandatory field when the Obtaining Address parameter is set to “Static”.
  • Network Mask: Allows you to configure the network mask. This parameter allows you to divide a specific network into smaller subnets, optimizing the use of a certain IP range. It is a mandatory field when the Obtaining Address parameter is set to “Static”.
  • Default Gateway: Allows you to define the gateway to be used. This parameter refers to the address that connects the device to the Internet. It is a mandatory field when the Obtaining Address parameter is set to “Static”.
  • DNS Server: Allows you to define the DNS server. This parameter refers to a hierarchical and distributed name management system for computers, services or any resource connected to the Internet or to a private network. It is a mandatory field when the Obtaining Address parameter is set to “Static”.

• IPv6 Configuration:

  • IP Address: Allows you to configure the IPv6 address. This parameter refers to the identification of the device in a local or public network. Each computer or device on the Internet or in an internal network has a unique IP. It is a mandatory field when the Obtaining Address parameter is set to “Static”.
  • DNS Server: Allows you to configure the DNS server. This parameter refers to a hierarchical and distributed name management system for computers, services or any resource connected to the Internet or to a private network. It is a mandatory field when the Obtaining Address parameter is set to “Static”.
  • Prefix: Allows you to configure the prefix to be used.

MODBUS-TCP PROTOCOL

• Enable Protocol: Allows you to enable or disable the Modbus-TCP service.
• Service Port: Allows you to configure the TCP port on which the service will be available.
• Modbus Address: Allows you to configure the Modbus RTU address at which the device will reply as a server (slave). In cases of packets with address that diverge from the configured value, the device will operate as a Gateway.

MQTT PROTOCOL

• Enable MQTT: Allows you to enable or disable the sending of data via the MQTT protocol.

• Cloud: Allows you to configure the platform to be used during the connection with the MQTT Broker: Generic platform, Google Cloud, Amazon AWS, Microsoft Azure, NOVUS Cloud, LiveMES or MInA. Depending on the option chosen, the parameters will adjust to meet the specific requirements of the platform. To customize all the parameters, select the “General” option. When you select the “LiveMES” or “MInA” option, the device will set the platform defaults. You do not need to make any changes to use the MQTT protocol.

• Broker User: Allows you to configure the user registered in the Broker. This field allows up to 32 characters. If the field is empty, the connection will be made in anonymous mode. Parameter not necessary for Google Cloud and Microsoft Azure.

• Broker Password: Allows you to configure the password of the user registered in the Broker. This field allows up to 42 characters. If the field is empty, the connection will be made in anonymous mode. Parameter not necessary for Google Cloud and Microsoft Azure.

• Service Port: Allows you to configure the number of the port used to make the connection with the Broker.

• QoS: Allows you to configure the quality level of service used to send MQTT messages: 0 or 1.

• Data Retention: Allows you to configure whether data should be retained in the cloud. Not all platforms support this feature.

• Broker URL or IP: Allows you to configure the Broker address, which can be either a URL (Uniform Resource Locator) or an IP. The field allows up to 60 characters.

• Device ID: Allows you to configure a device ID.

• Project ID: Allows you to configure a project ID. Parameter exclusive to Google Cloud.

• Register ID: Allows you to configure a register ID. Parameter exclusive to Google Cloud.

• Region: Allows you to configure a region for the connection: “Us-central1”, “Europe-west1” or “Asia-east1”. Parameter exclusive to Google Cloud.

• Topics: By clicking the Edit button, you can enter the topics to be used for the connection:

  • Publishing Topics: Allows you to configure the device to publish data in the cloud. For more information on publication topics, check  the PUBLICATION AND SUBSCRIPTION TOPICS section of the MQTT PROTOCOL chapter.
  • Topic to publish periodic data and events
  • Topic to confirm the configuration
  • Topic to confirm the command
  • Subscription Topics: Allows you to configure the device to receive data in the cloud. For more information on subscription topics, check the PUBLICATION AND SUBSCRIPTION TOPICS section of the MQTT PROTOCOL chapter.
  • Topic to receive the configuration
  • Topic to receive the commands

• Primary Key: Allows you to configure the primary key to be used. Parameter exclusive to Microsoft Azure.

• Security: Allows you to configure the protocol and data encryption for secure communication with the MQTT Broker.

  • None: The connection does not use security measures.
  • Only TLS V 1.2 – CA: If this option is selected, communication with the Broker will use the Transport Layer Security (TLS) 1.2 protocol, which requires a TLS certificate recognized by a certification authority (CA) to ensure privacy and data integrity. o TLS V 1.2 – Self Signed: If this option is selected, communication with the Broker will use the Transport Layer Security (TLS) 1.2 protocol, which, in addition to the TLS certificate recognized by a certification authority (CA), also requires authentication of the client certificate and its private key to ensure privacy and data integrity.
    Note: CA certificate, client certificate and private key files are accepted in .pem and .der formats only.

• Save the certificate to the configuration file: Once enabled, adds the certificate contents whenever you save a configuration file.

• Read the certificate via Modbus-TCP: Once enabled, allows NXperience to read certificates via the Modbus-TCP interface.

• Publish Diagnostics Periodically: By enabling this parameter, DigiRail OEE will perform periodic diagnostic publications in the command confirmation topic. It will be published whenever the device is started and every day at midnight (if connected to the Broker). There will be two publications: One with the “diag” object with the system event counts and another with the “logs” object, returning the last 50 system  events.
  RS485
  

• Stop Bits: Allows you to configure the number of Stop Bits to be used by the RS485 interface.

• Baud Rate: Allows you to configure the Baud Rate to be used by RS485: 1200, 2400, 4800, 9600, 19200, 38400, 57600 or 115200.

• Parity: Allows you to configure the parity to be used by the RS485 interface: Even, odd or none.

• Timeout: Allows you to configure a period (in ms) to be used by the RS485 interface to define how long the device will wait for a response from a network slave. This parameter may be configured with a minimum value of 10 ms and a maximum value of 65535 ms.

CHANNELS
ANALOG CHANNELS

• Input Type: Allows you to configure the type of sensor to be used on each analog channel.
• Number of decimal places: Allows you to configure the number of decimal places to be used when publishing the calculated value.
• Lower Limit: Allows you to configure a minimum value for the sensor.
• Upper Limit: Allows you to configure a maximum value for the sensor.
• Error Value: Allows you to configure the error value to be considered for the display when an error is detected while reading the sensor.

DIGITAL CHANNELS

• Input Type: Allows you to configure the type of digital input: Counting or Event.
• Sensor Type: Allows you to configure the type of sensor to be used: PNP, NPN or Dry Contact.
• Counting Edge: Allows you to configure the desired counting edge: Rising edge, falling edge or both edges. This way, the device will increase the counts or recognize an event whenever the configured edge is detected in the digital input.
• Debounce: Once enabled, allows you to configure the debounce period to be used. The debounce refers to the sensor settling time (minimum time in which the sensor must remain at the logical level of interest so that the detected edge is considered valid).
• Reset Mode: Allows you to configure the reset mode of the selected channel: Periodic and/or MQTT/Modbus TCO. You can set the Periodic mode on the ALL CHANNELS tab (see the ALL CHANNELS section of this chapter).
• Allows you to adjust the count value : Once enabled, allows changes via Modbus/MQTT in the channel digital counter.

ALL CHANNELS

RESET THE DIGITAL CHANNELS PERIODICALLY
It allows you to configure the periodic reset mode of the digital channels configured in “Periodic” mode (see the CHANNELS section of this chapter).
ADD COUNTING IN CHANNELS CONFIGURED AS EVENT
When the digital channel is configured as “Event”, it allows you to add the count value in the circular buffer and in the MQTT publication.

LOGS

• Log Interval: Allows you to define the interval (in seconds) at which the data will be logged to the circular buffer. If the MQTT protocol is enabled, this interval will also be used to log the periodic data publications.
• Automatic switch to Alternative Log Interval: Once enabled, allows increasing the time interval in which the data will be logged in the memory in cases of instability of the connection with the MQTT Broker. When the MQTT publication submission queue is greater than 10% of capacity, the log interval will be changed to the value set in the “Alternative Log Interval” parameter. When the connection is restored and the queue is below 10 % of capacity, the log range is reset.
• Alternative Log Interval: Allows you to define the interval (in seconds) to be used when the MQTT publish sending queue is over 10% of capacity. In this case, it the option “Enables automatic switching to Alternative Log” must be enabled.

DIAGNOSTICS

You can view the DigiRail OEE diagnosis tab by clicking the Diagnostics button located on the NXperience home screen.

INFORMATION

• Device Tag: Displays the device tag.
• Location: Displays the location of the device, as configured in the General Information section of the Configuration tab (see CONFIGURING DIGIRAIL OEE WITH NXPERIENCE section of this chapter).
• Serial Number: Displays the device serial number.
• Model: Displays the device model.
• Firmware Version: Displays the device current firmware version.
• USB Status: Displays the USB interface status of the device.
• Power Supply : Displays information about the power supply status of the device.

INPUTS

• Value: Displays the current value of the configured channel. When the channel has been configured as “Event”, this field will show the value 0 or 1. When the channel has been configured as “Counting”, it will show the counter value.
• Date/Time: Displays the date and time of an event if the digital input has been configured in “Event” mode (see the DIGITAL CHANNELS section of this chapter).
• Engineering Unit Value: Displays the value measured by the channel in V or mA, depending on the type of channel configured.

OUTPUTS

This section allows you to force outputs 1 and 2 in on or off status by clicking the On button, in addition to displaying the status of each output.

CONNECTIVITY

ETHERNET
This section will present parameters related to the device model: DigiRail OEE – ETH or DigiRail OEE – WRL.

• Wi-Fi Quality: Displays the quality of the Wi-Fi signal in percentage value.
• Gateway Connection: Displays information on the status of the Gateway connection.
• IPv4 – Address: Displays the device IPv4 address.
• IPv4 – Mask: Displays the device IPv4 mask.
• IPv4 – Gateway: Displays the device Gateway.
• IPv4 – DNS: Displays the device DNS.
• IPv6 – Local: Displays the device local IPv6 address.
• IPv6 – Global : Displays the device global IPv6 address.
• MAC Address: Displays the device MAC address.

MODBUS-TCP

• Port: Displays the number of the Modbus-TCP port configured in the device.
• Number of Connections: Displays the number of Modbus-TCP Clients currently connected to the device.

MQTT

• Broker Status: Displays the connection status to the configured MQTT Broker.
• Last Update: Displays the day and time of the last package successfully published in the MQTT Broker.
• MQTT Queue: Displays the number of logs awaiting publication.

SYSTEM EVENTS

This section allows you to view the system events. In addition, you can generate a report with extension .CSV, which contains the event log and a count of how many times each event occurred.

TECHNICAL SPECIFICATION

Logical level ‘I’: > 3 V
Maximum Voltage| 30 V
Input Impedance| 270 kΩ
Input Current ©30 Vcc| 0.15 mA
Maximum Frequency
(Square wave)| Dry Contact < 10 Hz
PNP: 3 kHz
NPN: 3 kHz
Minimum Pulse Length| Dry Contact 50 ms PNP: 150 us
NPN: 150 us
Digital Output| 2 digital NPN outputs
Maximum current that can be swathed at the output 700 mA
Buffer Capacity| • 7000 logs with 1 analog input enabled’
• 1800 logs with 2 analog inputs enabled and the 6 digital inputs in Count mode’
Communication Interfaces| DigiRail OEE – ETH| • USB 2.0 Interface
• Ethernet Interface (10/1C0 Mbps) with RJ45 connector
• RS485 communication interface with Modbus RTU protocol in Gateway mode
DigiRail OEE -WR| •USB 2.0 Interface
•Wi-Fl Interface (802.11 big/n 2.4 GHz), supporting WPA-Personal (PSK) WPAIWPA2 TKIP/AES/TKIP and AES encryption
•RS485 communication interface with Modbus RTU protocol in Gateway mode
LEDs| • 1 x Status LED
• 1 x Local Network Connection LED
• 1 x Broker MOTT Comection LED
Software| NXperlence (via USB or TCP/IP network for desktops and notebooks).
Power Supply| Power Supply| WI-FI Model:
Consumption: 70 mA @24V Consumption: 160 mA ©12V
Ethernet Model:
Consumption: 50 mA @24V Consumption: 120 mA @12V
Batteries| CR2032 battery for internal dock retention
Dimension| 129 mmx 142 mmx38mm.
Mounting| DIN rail or screw mounting.
Environment| Operating Temperature: -20 to 60 °C (-4 to 140 °F) Storage Temperature: -20 to 60 °C (-4 to 140 °F) Humidity: 5 to 95 % RH (without condensation)
Housing| ABS+PC
Protection Index| IP20
Certification| ANATEL (09260-20-07089), CE, FCC,
Compatible with IEC 60068-2-6 (2007),
Contains FCC ID: 2ADHKATWINC1500,
Contains IC: 20266-WINC1500PB.

• None of the cases consider event log.

Table 10 – Technical Specification

CIRCULAR BUFFER AVAILABILITY TABLE

This table allows you to evaluate the maximum number of downloads performed by the enabled channels if the digital channel count is in event mode or if it is not in event mode.

DIGITAL CHANNELS| ANALOG CHANNELS| MAXIMUM AMOUNT (WITHOUT EVENT COUNTING)| MAXIMUM AMOUNT (WITH EVENT COUNTING)
---|---|---|---
0| 1| 7096| 4913
0| 2| 5806| 4913
1| 0| 5806| 4913
2| 0| 4258| 4258
3| 0| 3361| 3361
4| 0| 2777| 2777
5| 0| 2365| 2365
6| 0| 2060| 2060
6| 1| 1935| 1935
6| 2| 1824| 1824

For more information about the operation and download of the circular buffer, see the document on the Modbus-TCP Protocol, available on the product page of the NOVUS website.

CERTIFICATION

ANATEL
This device is homologated by ANATEL, according to the regulated procedures for conformity assessment of telecommunications devices, and meets the technical requirements applied. This equipment is not subject to the protection from harmful interference and may not cause interference with duly authorized systems.
For more information, see the ANATEL website www.anatel.gov.br.

FCC
Contains FCC ID: 2ADHKATWINC1500
This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to Part 15 of the FCC Rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses, and can radiate radio frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications.
Any changes or modifications not expressly approved by the party responsible for compliance could void the user’s authority to operate this equipment.
RF Exposure:
To satisfy FCC RF exposure requirements, a separation distance of 6.5 cm or more should be maintained between the antenna of this device and persons during operation. To ensure compliance, operations at closer distances than this are not recommended. This device and its antenna(s) must not be co- located or operating in conjunction with any other antenna or transmitter.
This device complies with part 15 of the FCC Rules. Operation is subject to the following two conditions: (1) This device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may cause undesired operation.

CE Mark
This is a Class A product. In a domestic environment, this product may cause radio interference in which case the user may be required to take adequate measures.

IC
Contains IC: 20266-WINC1500PB
This device complies with Industry Canada’s license exempt RSS standard(s). Operation is subject to the following two conditions:
(1) This device may not cause interference, and
(2) This device must accept any interference, including interference that may cause undesired operation of the device.

The installation of the transmitter must ensure that the antenna has a separation distance of at least 6.5 cm from all persons or compliance must be demonstrated according to the ISED SAR procedure

VIBRATION TESTS
The device is in accordance with the vibration tests in the profile described in IEC 60068-2-6 (2007) – Environmental Testing – Part 2: Tests – Test Fc: Vibration (Sinusoidal).

WARRANTY

Warranty conditions are available on our website www.novusautomation.com/warranty.

APPENDIX 1 – RECOMMENDATIONS FOR INSTALLATION IN INDUSTRIAL ENVIRONMENTS

PURPOSE

Due to the high levels of electromagnetic noise caused by machinery in industrial environments, digital devices can be susceptible to electromagnetic interference. Because of this, good practices should be adopted during the installation of electronic devices to mitigate the effects of this interference.
This appendix presents some recommendations for the installation of digital sensors and is intended to prevent data acquisition problems.

BEST PRACTICES FOR INDUSTRIAL INSTALLATION

A proper installation must have an industrial grounding system that complies with the IEC 60364-1. This is necessary to ensure the reduction of interference caused by industrial machinery and the equipotentialization between the supply voltages of electronic devices. Along with the grounding system, it is recommended to choose a good DC 24 V power supply, which guarantees isolation and interference filtering from the AC power input to the DC 24 V power output. CE Mark certified power supplies are the most suitable.
Some manufacturing plants have machines that produce excessive electromagnetic interference. For these cases, it is recommended to choose an instrumentation panel where the electronic devices can be installed. It must comply with the technical standards and provide the shielding of the industrial environment through a grounding terminal that must be connected to the grounding system.
An important recommendation for the proper functioning of the system is to ensure that the cabling between sensors and instrumentation devices has the best path in the manufacturing plant to obtain the shortest distance between instruments and sensors and, at the same time, distance them from possible sources of electromagnetic interference (machines, motors, and sources of electromagnetic pulses). It is recommended that instrumentation sensors run through the plant through grounded conduits exclusively for instrumentation. The power supply network of the machines must run through the plant in separate conduits.

INSTALLATION RECOMMENDATIONS FOR DIGIRAIL OEE DIGITAL INPUT SIGNALS

In most cases, following good industrial installation practices, described in the previous section, is enough to ensure that the system will work properly. However, depending on the environment where the device is installed, some extra recommendations may be necessary.

ISOLATED GROUND POWER SUPPLY
The figure below illustrates how to connect a power supply to DigiRail OEE, a Dry Contact type sensor on digital channel 1, an NPN type sensor on digital channel 2 and a PNP type sensor on digital channel 3. In this example we also show that the power supply must be grounded.

PULL-UP RESISTORS FOR THE SENSORS
If the previous recommendation has been implemented and there is still a problem reading the sensors, pull-up resistors can be used to improve the sensor signal. Dry Contact and NPN sensors should have the sensor reading signal connected to the positive side of the power supply through a 10 kohm ¼ W resistor.
PNP type sensors should have the sensor reading signal connected to the negative of the power supply through a 10 kohm ¼ W resistor (a pulldown resistor).
This procedure is used to improve the sensor signal when the sensor is open. The pull-up and pull-down resistors can be connected either close to the device or close to the sensors. The figure below shows how to connect each of these sensors.

HOW TO GROUND THE NEGATIVE TERMINAL OF THE POWER SUPPLY
If none of the previous implementations has solved the problem, it is possible that there is a potential difference between the negative terminal of the power supply and the system ground, and a current leakage in one of the connected sensors. You can ground the negative terminal of the power supply to eliminate these problems.

GROUNDED CONDUIT
A good installation practice that prevents possible problems in reading the sensors is to use grounded conduit between the device and sensors. The figure below shows how to use grounded conduit in the path where the sensor signals travel through the plant.

References

• Anatel — Agência Nacional de Telecomunicações
• NOVUS Automation Inc. - Controllers, Thermostats, Data Loggers, Solid State Relays, Sensors, Transmitters, SCADA, Data Acquisition and Temperature Controllers

Read User Manual Online (PDF format)

Download This Manual (PDF format)

Download this manual  >>