Short answer
Publication date: March 19, 2024
A significant share of manufacturing loss is caused not by major failures but by small interruptions detected too late. A machine may enter a fault state, wait for material, require operator attention, or appear to run without producing output. If these conditions remain unnoticed for several minutes, they can become a serious capacity loss by the end of the shift. Many small and medium-sized factories still depend on panel lights, operator reports, and end-of-shift forms to understand machine status.
NetRelay can improve this visibility without requiring a complete replacement of existing machinery. It provides four digital inputs for dry-contact signals such as running, waiting, fault, and product pulses. Four 250 V / 10 A relay outputs can trigger a signal light, siren, auxiliary fan, or a suitably protected control circuit through a contactor. Ethernet, Wi-Fi, 802.3af/at PoE, and 7–28 V DC power options support different panels and field conditions.
What information can be collected from a machine?
Not every machine offers the same communication protocol, but many industrial machines include an alarm relay, run contact, counter output, or signal-light circuit. The electrical diagram and manufacturer documentation should be reviewed to identify safe and isolated signals. NetRelay digital inputs can transfer these states to central software.
For example, input one may indicate running, input two a general fault, input three a material-waiting state, and input four a product-count pulse. This provides more information than a simple on/off state. If the run signal remains active while the product count does not increase for a defined period, the maintenance or production team can receive an alert. The system therefore separates “machine was running” from “machine produced output.”
How is the data connected to existing software?
NetRelay supports MQTT, HTTP GET/POST, WebSocket, and TCP. MQTT is suitable for collecting status data from several machines through a central broker. The HTTP API allows ERP, MES, SCADA, or custom production software to request I/O states when required. WebSocket can provide live operator-panel updates and authorized low-latency relay commands.
Applications developed with Python, Node.js, C#, PHP, Delphi, and other common languages can communicate with the NetRelay API. This helps businesses preserve existing software investments while adding physical machine data to digital workflows. Meaningful device names and input labels such as “Line 1 Running” or “Packaging Fault” make maintenance and reporting easier.
What measurable business value can it create?
The commercial value is not simply remote relay control. The main value is making production loss visible and measurable. A pilot project can compare:
- Time between the start and detection of downtime,
- Time between a fault alert and technical intervention,
- Unplanned interruptions per shift,
- Relationship between runtime and product quantity,
- Time and shift distribution of recurring failures,
- Incidents verified or resolved remotely,
- Reduction in routine inspection work.
A basic ROI model adds avoided production loss, shorter maintenance response, and saved staff time. This benefit is compared with the cost of NetRelay, panel components, sensors, installation, and software integration. The calculation should use the plant's actual downtime cost rather than a generic savings percentage.
How should a pilot be planned?
Instead of transforming an entire plant, begin with one critical machine or a machine with frequent interruptions. Review its electrical diagram, identify available dry contacts, and prepare safe connection points. Monitor data quality, false alarms, and response times during a 30–45 day pilot.
If the pilot is successful, create a standard wiring diagram, device profile, MQTT topic structure, and software dashboard before expanding to similar machines. PoE may reduce cabling by carrying power and data over one cable in suitable installations. Local event logic can continue during an internet outage, reducing cloud dependency.
Does NetRelay replace a PLC?
NetRelay may provide a practical alternative in selected auxiliary automation tasks, but it does not replace every PLC. High-speed counting, motion control, large I/O systems, safety integrity, and hard real-time processes require appropriate PLC and certified safety architecture.
Emergency stops, guard doors, press safety, and other human-safety circuits must not be created through NetRelay. NetRelay may monitor permitted status contacts from these systems. Relay outputs should control motors or high-power loads only through suitable contactors and protection components.
Pre-purchase checklist
Define the number of machines, required inputs, permitted auxiliary outputs, network infrastructure, PoE or DC power, central software, data-retention requirement, and alarm method. If four inputs and four outputs are sufficient, open API integration is required, and local operation matters, NetRelay is a strong candidate.
A properly designed project can provide measurable production visibility without replacing existing machinery. Share the machine diagram, required signals, and current software architecture with the NetRelay technical team to define a realistic pilot.
Why is data quality as important as hardware?
A wrong production signal can be more misleading than no data. A connection taken from a machine run lamp may indicate only that the main switch is on. Electrical noise may create duplicate product counts. Each input therefore needs a documented meaning, active level, minimum pulse duration, and validated normal behavior.
Input voltage and isolation must follow device documentation. Intermediate relays or suitable signal converters may be required. Signal cables should be separated from power wiring, and panel grounding and EMC should be reviewed. Software should filter short pulses, combine repeated events, and report disconnected devices as “unknown” rather than treating missing data as zero.
How should alarm management be designed?
Sending every stop to every manager quickly creates alarm fatigue. Planned maintenance, shift change, material waiting, and real faults should be separated. A first-level operator warning may escalate to maintenance after a defined duration and to production management if the interruption continues.
An alarm should include line, machine, event, start time, duration, and the first recommended check. A recovery message is also important for measuring response effectiveness. NetRelay email, MQTT, and HTTP capabilities can support these workflows through different applications.
What are the limits of production counting?
The pulse rate must remain within the reliable range of the selected input architecture. High-speed encoders, shaft position, and precision timing require a dedicated counter or PLC. NetRelay is better suited to moderate-speed product passage, cycle-complete contacts, and operating states.
Where counts are used for billing or regulated measurement, calibration, traceability, and validation must be addressed separately. NetRelay data can be a strong operational indicator but does not replace a certified measuring instrument where one is legally required.
Network and cybersecurity
Every device added to a production network should be controlled. NetRelay can be placed in an IoT VLAN with access limited to management workstations, the MQTT broker, and required API servers. Default credentials must be changed. VPN or secure outbound MQTT is preferable to direct internet port forwarding.
MQTT users should be separated by device and limited to their own topics. Command software needs role-based authorization, audit logging, and approval rules. Remote relay control should be available only to personnel with a defined operational need.
How can maintenance teams use the data?
Repeated faults during a certain shift or after a similar runtime may indicate a mechanical or process problem. Technicians can review current state and event history before traveling to the machine.
Device connectivity, power, and internal status can also be monitored. Firmware updates should be performed during a maintenance window after configuration backup. I/O tests must be completed before returning the unit to production.
What information is required for a professional quotation?
A discovery form should include machine make and model, electrical diagram, dry contacts, signal voltages, cycle speed, required outputs, panel space, power, Ethernet or PoE availability, and central software. “Remote machine control” is not specific enough; the exact function, conditions, and safety chain must be defined.
The quotation should identify intermediate relays, contactors, protection, terminals, enclosure, power supply, wiring, installation, software integration, commissioning, and training in addition to the NetRelay device. This prevents incomplete comparisons based only on board price.
Frequently asked questions
Does it work without internet?
Local rules and LAN communication can work without internet. If central software is at another location, remote monitoring pauses during the outage while the predefined local behavior continues.
How many devices can a factory use?
Multiple devices can be managed when MQTT topics, device identities, IP planning, and authorization are standardized.
Can installation affect machine warranty?
Improper modification may create warranty and safety risks. Qualified automation personnel should use manufacturer-approved auxiliary contacts and follow documentation.
What is the first step?
Select one machine with measurable loss, review recent downtime, identify available signals, and document pilot success criteria. This makes the purchase a business decision rather than a technology experiment.
Example 30-day commissioning schedule
During week one, review electrical diagrams and downtime causes and validate signals with operators and maintenance. In week two, complete panel wiring, network settings, device naming, and dashboards. During week three, run in observation mode with automatic relay actions disabled and compare records with actual machine behavior. In week four, enable validated alarm rules and measure response.
Finish with both technical and commercial review. Stable communication alone is not success if the information does not improve production decisions. If early detection of one recurring interruption prevents meaningful loss, prepare a rollout. Deliver configuration backup, wiring drawing, I/O list, and responsibility matrix.
The buying decision should begin with the number of defined problems rather than the number of devices. Clear machine, signal, and loss targets create clear success criteria.
What should the completed project deliver?
A working device alone is not a completed project. Acceptance testing should trigger every input, safely test every permitted output, and verify communication-loss and power-recovery behavior. Responsibilities for operators, maintenance, and IT should be documented. This prevents dependence on one individual and reduces risk during expansion.