Overview
A point map is the configuration layer that defines how data is translated between a source protocol and a destination protocol in a gateway. Each row represents a mapping decision: where the source value comes from, how it is interpreted, and how it should be exposed downstream.
Point maps are central to both QuickServer and FieldServer workflows.
Typical Point Map Columns
| Column | Description |
|---|---|
| Source address | Register, object, data table, or vendor-specific source reference |
| Destination address | Register, object, topic, or downstream point reference |
| Data type | UINT16, FLOAT32, ENUM, bitfield, and similar typing metadata |
| Scaling | Multiplier, offset, slope or intercept conversion |
| Access direction | Read-only, write-only, or bidirectional behavior |
| Description | Human-readable point name or function note |
Best Practices
- Start with the source documentation before building the map. For Modbus, that usually means the register map.
- Classify read versus write behavior before mapping. This is especially important for EtherNet/IP jobs that depend on DATA_TABLE_READ / WRITE.
- Verify data types and scaling rules before assuming the transport is at fault.
- Validate a small subset of points end to end before expanding the full map.
[!TIP] Validate five to ten known points first. Early end-to-end confirmation catches data-type, scaling, and addressing mistakes before they spread across the whole project.
Common Failure Patterns
- The source address is correct but the data type is wrong.
- The correct value is present but needs byte or word reordering.
- The project assumes a writable path that the source device does not actually support.
- The team builds the full map before verifying one physically known value.