Industrial compressors and chillers are the unsung heroes of manufacturing. They don't make products, but without them, nothing else works. Compressed air powers pneumatic actuators, controls, and tools across the plant. Chillers maintain process temperatures for injection molding, chemical reactions, food processing, and data centers. When a compressor or chiller fails, the entire production line stops — often with zero warning.

Every plant tracks downtime. Almost no plant tracks it well. The difference between useful downtime data and worthless downtime data usually comes down to one thing: reason codes. Get the classification system right, and you'll know exactly where to invest for maximum uptime improvement. Get it wrong, and you'll have a graveyard of "Other" and "Miscellaneous" entries that tell you nothing.

If you've ever seen a temperature reading of 3.4028235 × 10³⁸ flash across your monitoring dashboard at 2 AM, you've met IEEE 754's ugly side. Floating-point representation is the lingua franca of analog process data in industrial automation — and it's riddled with traps that can silently corrupt your data pipeline if you don't handle them at the edge.

This guide covers the real-world edge cases that matter when reading float registers from PLCs over Modbus, EtherNet/IP, and other industrial protocols — and how to catch them before they poison your analytics, trigger false alarms, or crash your trending charts.

Why Floating-Point Matters More in Industrial IoT​

In enterprise software, a floating-point rounding error means your bank balance is off by a fraction of a cent. In industrial IoT, a misinterpreted float register can mean:

• A temperature sensor reading infinity instead of 450°F, triggering an emergency shutdown
• An OEE calculation returning NaN, breaking every downstream dashboard
• A pressure reading of -0.0 confusing threshold comparison logic
• Two 16-bit registers assembled in the wrong byte order, turning 72.5 PSI into 1.6 × 10⁻³⁸

These aren't theoretical problems. They happen on real factory floors, every day, because the gap between PLC register formats and cloud-native data types is wider than most engineers realize.

The Anatomy of a PLC Float​

Most modern PLCs store floating-point values as IEEE 754 single-precision (32-bit) numbers. The 32 bits break down as:

┌─────┬──────────┬───────────────────────┐
│Sign │ Exponent │      Mantissa         │
│1 bit│  8 bits  │      23 bits          │
└─────┴──────────┴───────────────────────┘
 Bit 31  Bits 30-23      Bits 22-0

This gives you a range of roughly ±1.18 × 10⁻³⁸ to ±3.40 × 10³⁸, with about 7 decimal digits of precision. That's plenty for most process variables — but the encoding introduces special values and edge cases that PLC programmers rarely think about.

The Five Dangerous Values​

Why PLCs Generate These Values​

PLC ladder logic and structured text don't always guard against special float values. Common scenarios include:

Uninitialized registers: When a PLC program is downloaded but a tag hasn't been written to yet, many PLCs leave the register at 0x00000000 (zero) — but some leave it at 0xFFFFFFFF (NaN). There's no universal standard here.

Sensor faults: When an analog input card detects a broken wire or over-range condition, some PLCs write a sentinel value (often max positive float or NaN) to the associated tag. Others set a separate status bit and leave the value register frozen at the last good reading.

Division by zero: If your PLC program calculates a rate (e.g., throughput per hour) and the divisor drops to zero during a machine stop, you get infinity. Not every PLC programmer wraps division in a zero-check.

Scaling arithmetic: Converting raw 12-bit ADC counts (0–4095) to engineering units involves multiplication and offset. If the scaling coefficients are misconfigured, you can get results outside the normal range that are still technically valid IEEE 754 floats.

The Byte-Ordering Minefield​

Here's where industrial protocols diverge from IT conventions in ways that cause the most data corruption.

Modbus Register Ordering​

Modbus transmits data in 16-bit registers. A 32-bit float occupies two consecutive registers. The question is: which register holds the high word?

The Modbus specification says big-endian (high word first), but many PLC vendors violate this:

Standard Modbus (Big-Endian / "ABCD"):
  Register N   = High word (bytes A, B)
  Register N+1 = Low word  (bytes C, D)

Swapped (Little-Endian / "CDAB"):
  Register N   = Low word  (bytes C, D)
  Register N+1 = High word (bytes A, B)

Byte-Swapped ("BADC"):
  Register N   = Byte-swapped high word (B, A)
  Register N+1 = Byte-swapped low word  (D, C)

Full Reverse ("DCBA"):
  Register N   = (D, C)
  Register N+1 = (B, A)

Real-world example: A process temperature of 72.5°F is 0x42910000 in IEEE 754. Here's what you'd read over Modbus depending on the byte order:

The only reliable way to determine byte ordering is to read a known value from the PLC — like a setpoint you can verify — and compare the decoded result against all four orderings.

EtherNet/IP Tag Ordering​

EtherNet/IP (CIP) is generally more predictable because it transmits structured data with typed access. When you read a REAL tag from an Allen-Bradley Micro800 or CompactLogix, the CIP layer handles byte ordering transparently. The value arrives in the host's native format through the client library.

However, watch out for array access. When reading a float array starting at a specific index, the start index and element count must match the PLC's memory layout exactly. Requesting tag_name[1] with elem_count=6 reads elements 1 through 6 — the zero-indexed first element is skipped. Getting this wrong doesn't produce an error; it silently gives you shifted values.

Practical Validation Strategies​

Layer 1: Raw Register Validation​

Before you even try to decode a float, validate the raw bytes:

import struct
import math

def validate_float_register(high_word: int, low_word: int,
                            byte_order: str = "ABCD") -> tuple[float, str]:
    """
    Decode and validate a 32-bit float from two Modbus registers.
    Returns (value, status) where status is 'ok', 'nan', 'inf', or 'denorm'.
    """
    # Assemble bytes based on ordering
    if byte_order == "ABCD":
        raw = struct.pack('>HH', high_word, low_word)
    elif byte_order == "CDAB":
        raw = struct.pack('>HH', low_word, high_word)
    elif byte_order == "BADC":
        raw = struct.pack('>HH',
                          ((high_word & 0xFF) << 8) | (high_word >> 8),
                          ((low_word & 0xFF) << 8) | (low_word >> 8))
    elif byte_order == "DCBA":
        raw = struct.pack('<HH', high_word, low_word)
    else:
        raise ValueError(f"Unknown byte order: {byte_order}")

    value = struct.unpack('>f', raw)[0]

    # Check special values
    if math.isnan(value):
        return value, "nan"
    if math.isinf(value):
        return value, "inf"

    # Check denormalized (subnormal) — often indicates garbage data
    raw_int = struct.unpack('>I', raw)[0]
    exponent = (raw_int >> 23) & 0xFF
    if exponent == 0 and (raw_int & 0x7FFFFF) != 0:
        return value, "denorm"

    return value, "ok"

Layer 2: Engineering-Range Clamping​

Every process variable has a physically meaningful range. A mold temperature can't be -40,000°F. A flow rate can't be 10 billion GPM. Enforce these ranges at the edge:

RANGE_LIMITS = {
    "mold_temperature_f":   (-50.0, 900.0),
    "barrel_pressure_psi":  (0.0, 40000.0),
    "screw_rpm":            (0.0, 500.0),
    "coolant_flow_gpm":     (0.0, 200.0),
}

def clamp_to_range(tag_name: str, value: float) -> tuple[float, bool]:
    """Clamp a value to its engineering range. Returns (clamped_value, was_clamped)."""
    if tag_name not in RANGE_LIMITS:
        return value, False
    low, high = RANGE_LIMITS[tag_name]
    if value < low:
        return low, True
    if value > high:
        return high, True
    return value, False

Layer 3: Rate-of-Change Filtering​

A legitimate temperature can't jump from 200°F to 800°F in one polling cycle (typically 1–60 seconds). Rate-of-change filtering catches sensor glitches and transient read errors:

MAX_RATE_OF_CHANGE = {
    "mold_temperature_f":  50.0,    # Max °F per polling cycle
    "barrel_pressure_psi": 2000.0,  # Max PSI per cycle
    "screw_rpm":           100.0,   # Max RPM per cycle
}

def rate_check(tag_name: str, new_value: float,
               last_value: float) -> bool:
    """Returns True if the change rate is within acceptable limits."""
    if tag_name not in MAX_RATE_OF_CHANGE:
        return True
    max_delta = MAX_RATE_OF_CHANGE[tag_name]
    return abs(new_value - last_value) <= max_delta

The 32-Bit Float Reassembly Problem​

When your edge gateway reads two 16-bit Modbus registers and needs to assemble them into a 32-bit float, the implementation must handle several non-obvious cases.

Two-Register Float Assembly​

The most common approach reads two registers and combines them. But there's a critical subtlety: the function code determines how you interpret the raw words.

For holding registers (function code 3) and input registers (function code 4), each register is a 16-bit unsigned integer. To assemble a float:

Step 1: Read register N → uint16 word_high
Step 2: Read register N+1 → uint16 word_low
Step 3: Combine → uint32 raw = (word_high << 16) | word_low
Step 4: Reinterpret raw as IEEE 754 float

But here's the trap: some Modbus libraries automatically apply byte swapping at the protocol layer (converting from Modbus big-endian to host little-endian), which means your "high word" might already be byte-swapped before you assemble it.

A robust implementation uses the library's native float-extraction function (like modbus_get_float() in libmodbus) rather than manual assembly when possible. When you must assemble manually, test against a known value first.

Handling Mixed-Endian Devices​

In real factories, you'll often have devices from multiple vendors on the same Modbus network — each with their own byte-ordering conventions. Your edge gateway must support per-device (or even per-register) byte-order configuration:

devices:
  - name: "Injection_Molding_Press_1"
    protocol: modbus-tcp
    address: "192.168.1.10"
    byte_order: ABCD
    tags:
      - name: barrel_temp_zone1
        register: 40001
        type: float32
        # Inherits device byte_order

  - name: "Chiller_Unit_3"
    protocol: modbus-tcp
    address: "192.168.1.20"
    byte_order: CDAB    # This vendor swaps words
    tags:
      - name: coolant_supply_temp
        register: 30000
        type: float32

Change Detection with Floating-Point Values​

One of the most powerful bandwidth optimizations in IIoT edge gateways is change-of-value (COV) detection — only transmitting a value when it actually changes. But floating-point comparison is inherently tricky.

The Naive Approach (Broken)​

// DON'T DO THIS
if (new_value != old_value) {
    send(new_value);
}

This fails because:

• Sensor noise causes sub-LSB fluctuations that produce different float representations
• NaN ≠ NaN by IEEE 754 rules, so you'd send NaN every single cycle
• -0.0 == +0.0 by IEEE 754, so you'd miss sign changes that might matter

The Practical Approach​

Compare at the raw register level (integer comparison), not the float level. If the uint32 representation of two registers hasn't changed, the float is identical bit-for-bit — no ambiguity:

uint32_t new_raw = (word_high << 16) | word_low;
uint32_t old_raw = stored_raw_value;

if (new_raw != old_raw) {
    // Value actually changed — decode and transmit
    stored_raw_value = new_raw;
    transmit(decode_float(new_raw));
}

This approach is used in production edge gateways and avoids all the floating-point comparison pitfalls. It's also faster — integer comparison is a single CPU instruction, while float comparison requires FPU operations and NaN handling.

Batching and Precision Preservation​

When batching multiple tag values for transmission, format choice matters for float precision.

JSON Serialization Pitfalls​

JSON doesn't distinguish between integers and floats, and most JSON serializers will round-trip a float through a decimal representation, potentially losing precision:

Original float: 72.5 (exact in IEEE 754: 0x42910000)
JSON: "72.5" → Deserialized: 72.5 ✅

Original float: 72.3 (NOT exact: 0x4290999A)
JSON: "72.30000305175781" → Deserialized: 72.30000305175781
Or:   "72.3" → Deserialized: 72.30000305175781 (different!)

For telemetry where exact bit-level reproduction matters (e.g., comparing dashboard values against PLC HMI values), use binary encoding. A well-designed binary telemetry format encodes the tag ID, status, value type, and raw bytes — preserving perfect fidelity with less bandwidth.

A typical binary batch frame looks like:

┌──────────┬────────────┬──────────┬──────────┬────────────────┐
│ Batch    │ Group      │ Device   │ Serial   │ Values         │
│ Header   │ Timestamp  │ Type     │ Number   │ Array          │
│ (1 byte) │ (4 bytes)  │ (2 bytes)│ (4 bytes)│ (variable)     │
└──────────┴────────────┴──────────┴──────────┴────────────────┘

Each value entry:
┌──────────┬────────┬──────────┬──────────┬────────────────┐
│ Tag ID   │ Status │ Count    │ Elem     │ Raw Values     │
│ (2 bytes)│(1 byte)│ (1 byte) │ Size     │ (count × size) │
│          │        │          │ (1 byte) │                │
└──────────┴────────┴──────────┴──────────┴────────────────┘

This format reduces a typical 100-tag batch from ~5 KB (JSON) to ~600 bytes (binary) — an 8× bandwidth reduction with zero precision loss.

Edge Gateway Best Practices​

Based on years of deploying edge gateways in plastics, metals, and packaging manufacturing, here are the practices that prevent float-related data quality issues:

1. Validate at the Source​

Don't wait until data reaches the cloud to check for NaN and infinity. By then, you've wasted bandwidth transmitting garbage and may have corrupted aggregations. Validate immediately after the register read.

2. Separate Value and Status​

Every tag read should produce two outputs: the decoded value AND a status code. Status codes distinguish between "value is zero because the sensor reads zero" and "value is zero because the read failed." Most Modbus libraries return error codes — propagate them alongside the values.

3. Configure Byte Order Per Device​

Don't hardcode byte ordering. Every industrial device you connect might have different conventions. Your tag configuration should support per-device or per-tag byte-order specification.

4. Use Binary Encoding for Bandwidth-Constrained Links​

If your edge gateway communicates over cellular (4G/5G) or satellite, binary encoding pays for itself immediately. The bandwidth savings compound with polling frequency — a gateway polling 200 tags every second generates 17 GB/month in JSON but only 2 GB/month in binary.

5. Hourly Full Reads​

Even with change-of-value filtering, perform a full read of all tags at least once per hour. This catches situations where a value changed but the change was lost due to a transient error, and ensures your cloud platform always has a recent snapshot of every tag — even slowly-changing ones.

How machineCDN Handles Float Data​

machineCDN's edge infrastructure handles these float challenges at the protocol driver level. The platform supports automatic byte-order detection during device onboarding, validates every register read against configurable engineering ranges, and uses binary telemetry encoding to minimize bandwidth while preserving perfect float fidelity.

For plants running mixed-vendor equipment — which is nearly every plant — machineCDN normalizes all float data into a consistent format before it reaches your dashboards, ensuring that a temperature from a Modbus chiller and a temperature from an EtherNet/IP blender are directly comparable.

Key Takeaways​

1. IEEE 754 special values (NaN, infinity, denormals) appear regularly in PLC data — don't assume every register read produces a valid number
2. Byte ordering varies by vendor, not by protocol — always verify against a known value
3. Compare at the raw register level for change detection — never use float equality
4. Binary encoding preserves precision and saves 8× bandwidth over JSON for telemetry
5. Validate at the edge, not in the cloud — garbage data should never leave the factory

Getting floating-point handling right at the edge gateway is one of those unglamorous engineering fundamentals that separates reliable IIoT platforms from brittle ones. Your trending charts, alarm logic, and analytics all depend on it.

Want to see how machineCDN handles multi-protocol float data normalization in production? Request a demo to explore the platform with real factory data.

Electronics manufacturing operates at the intersection of high precision and high volume. A surface-mount technology (SMT) line placing 50,000 components per hour needs every placement to be accurate to within 0.05mm. A reflow oven running a temperature profile with five distinct zones needs each zone to hold within 2°C of its setpoint. An automated optical inspection (AOI) system needs to catch every defect without generating false positives that slow the line.

When any of these parameters drift, the consequences compound fast. A single SMT nozzle running slightly off calibration can misplace 5,000 components before anyone notices. A reflow oven zone that is 8°C too hot produces solder joints that pass visual inspection but fail under thermal cycling six months later. These are the kinds of problems that IIoT monitoring was designed to catch — before they become quality escapes that reach your customers.

This guide covers how to deploy IIoT monitoring across an electronics manufacturing facility, which parameters matter most, and how real-time data changes the way electronics manufacturers manage quality, throughput, and equipment health.

Glass manufacturing is one of the most energy-intensive and thermally demanding processes in all of industrial production. A flat glass furnace operates at 1,550-1,600°C continuously — for 15 to 20 years between rebuilds. A container glass furnace cycles between 1,100°C and 1,550°C thousands of times per day as it feeds gobs to forming machines. The margin between perfect glass and scrap can be measured in single-digit degrees.

In this environment, manual data collection isn't just insufficient — it's dangerous. A refractory failure detected 6 hours late can destroy a furnace worth $20-50 million. A forming temperature deviation undetected for 30 minutes can produce thousands of defective containers. And energy represents 25-35% of total production cost, meaning a 3% efficiency improvement on a furnace burning $8 million in natural gas annually saves $240K.

IIoT monitoring isn't optional for modern glass manufacturing. It's survival.

Rubber and tire manufacturing is one of the most thermally sensitive production processes in all of discrete manufacturing. A 5°C deviation in a Banbury mixer changes compound viscosity. A 2-second variation in cure time changes tire durability. A 0.3mm inconsistency in calender gauge produces out-of-spec tread — and you might not catch it until the tire is on the building drum.

These are not problems you can solve with clipboard rounds every hour. They require continuous, real-time monitoring at the PLC level. Here's how IIoT is transforming rubber and tire manufacturing from art into engineering.

A single hour of unplanned downtime in a semiconductor fab costs between $100,000 and $500,000. With equipment valued at $10–$50 million per tool and process tolerances measured in nanometers, semiconductor manufacturing demands the most precise equipment monitoring in any industry. IIoT platforms are transforming how fabs manage equipment health, predict failures, and protect yield — but the semiconductor environment has unique challenges that general-purpose monitoring tools weren't designed to handle.

Woodworking and lumber manufacturing operate in a unique space: heavy industrial processes producing natural material products with inherent variability. Moisture content shifts between logs. Blade wear changes cut quality unpredictably. Kiln temperatures drift. Adhesive curing depends on ambient conditions. This variability makes real-time monitoring not just valuable — it's essential for consistent output.

Energy costs now rank as the second-largest operating expense for most manufacturers, right behind labor. With industrial electricity rates climbing 12-18% year over year across North America and Europe, plant managers need granular visibility into exactly where power is being consumed — not just a monthly utility bill that tells them nothing actionable.

Both IoTFlows and MachineCDN offer industrial monitoring platforms, but their approaches to energy tracking differ fundamentally. This comparison breaks down how each platform handles energy consumption data, where the gaps are, and which one gives your maintenance and operations teams the data they actually need to cut costs.

Every maintenance engineer knows the feeling: a critical machine goes down, the fault is identified in minutes, but the repair takes four hours because the right spare part is sitting in a warehouse 200 miles away. Or worse — it is on the shelf six feet from the machine, but nobody knew it was there because the parts inventory lives in a spreadsheet that was last updated three months ago.

Spare parts management and preventive maintenance scheduling are where IIoT platforms prove their value beyond simple monitoring. Both IoTFlows and MachineCDN offer machine monitoring capabilities, but their approaches to connecting real-time data with maintenance workflows differ significantly. This comparison breaks down which platform actually closes the loop between detecting a problem and fixing it.