Device & application guide
Find an acquisition driver by device brand, model or protocol, then select products for your supervisory interface. Use connection examples to plan point lists and commissioning.
Which device do you need to connect?
The acquisition library lists 579 protocols and device drivers.
Results are driver entries in the catalog. Different models, firmware and interfaces from one brand may need different drivers. Product selection applies acquisition, forwarding and hardware conditions together.
21 protocol / driver entries found
View acquisition protocol list- Select products for this driver
ModbusRTU_Honeywell_MVC_80M
Reviewed acquisition interfaceThe acquisition interface for this entry needs confirmation
Original catalog wording
ModbusRTU_Honeywell_MVC_80M 霍尼韦尔MVC_80M
- Select products for this driver
ModbusRTU_OverDTU
Reviewed acquisition interfaceThe acquisition interface for this entry needs confirmation
Original catalog wording
ModbusRTU_OverDTU ModbusRTU 透传DTU 私有协议
- Select products for this driver
ModbusRTU_TMS
Reviewed acquisition interfaceThe acquisition interface for this entry needs confirmation
Original catalog wording
ModbusRTU_TMS TMS 系列计费温控器通信协议
- Select products for this driver
ModbusRTU_YNN_BCD
Reviewed acquisition interfaceThe acquisition interface for this entry needs confirmation
Original catalog wording
ModbusRTU_YNN_BCD 永诺电器仪表BCD
- Select products for this driver
ModbusRTU_BRTEE
Reviewed acquisition interfaceThe acquisition interface for this entry needs confirmation
Original catalog wording
ModbusRTU_BRTEE 布雷特电动阀
- Select products for this driver
ModbusRTU_GTEC188
Reviewed acquisition interfaceThe acquisition interface for this entry needs confirmation
Original catalog wording
ModbusRTU_GTEC188 GTEC188
- Select products for this driver
ModbusRTU_YDF_B
Reviewed acquisition interfaceThe acquisition interface for this entry needs confirmation
Original catalog wording
ModbusRTU_YDF_B YDF_B诱导风机
- Select products for this driver
IBT_ModbusRTUClient
Reviewed acquisition interfaceThe acquisition interface for this entry needs confirmation
Original catalog wording
IBT_ModbusRTUClient IBT物联网通讯电力载波协议
- Select products for this driver
LTM9662_485NET
Reviewed acquisition interfaceThe acquisition interface for this entry needs confirmation
Original catalog wording
LTM9662_485NET M9600温度采集模块Modbus RTU
Connections and commissioning for common applications
These conceptual examples help you prepare and validate a project. They are not importable model configurations. Use actual documentation for addresses, terminals, data layout and software versions.
Modbus devices into a BACnet system
Read field-device points and expose mapped values to a building management system. This example begins with monitoring; writable points require separate confirmation.
- 01
Field device
Documented Modbus RTU server / slave
- 02
Acquisition
RS485 · register / coil point list
- 03
Matching gateway
Modbus client / master → mapped points
- 04
Forwarding
BACnet/IP · objects and properties
- 05
Building system
BACnet client / supervisory system
Commissioning steps
Confirm the exact device model, register or coil area, addressing convention, data type, word order and scaling from its point list.
Select a gateway with documented Modbus RTU acquisition and BACnet/IP forwarding; confirm roles, RS485 ports and point capacity.
Match serial parameters and device address, then prove one readable field point before adding the complete list.
Assign BACnet device and object identifiers in the project, and verify the supervisory system can discover and read the mapped points.
Minimum point list / checklist
| Point / check | Source | Data definition | Destination / validation |
|---|---|---|---|
| Temperature | Field point address to fill in | Numeric value · unit / scaling to confirm | BACnet analog object to assign |
| Run status | Field status address to fill in | Boolean · 0 / 1 meaning to confirm | BACnet binary object to assign |
How to verify
Compare the same point at the device, gateway and supervisory system. Change a measurable field condition, check refresh timing and units, then disconnect the device and verify the reported communication status.
BACnet forwarding variants and write behavior depend on the selected model and configuration. The product filter applies acquisition and forwarding conditions together.
Field data into an EtherCAT master
EC1024-ARM is the confirmed EtherCAT slave model. The master-side project maps acquired field values into the slave process-data layout.
- 01
Field device
Example: a documented Modbus RTU device
- 02
Acquisition
RS485 · exact reviewed driver
- 03
EC1024-ARM
Field acquisition → EtherCAT slave
- 04
Forwarding
EtherCAT · confirmed process-data layout
- 05
PLC / motion system
EtherCAT master
Commissioning steps
Obtain the ESI file and model manual that match the actual EC1024-ARM hardware and firmware. The website does not yet provide an ESI file.
Confirm field acquisition first, including data type, scaling and communication status for a small read-only point list.
Use the confirmed ESI and mapping instructions in the master project; agree the process-data direction, type, byte order and layout at both ends.
Connect using the model wiring instructions, bring the slave into normal data exchange, and compare the master variables with the gateway values.
Minimum point list / checklist
| Point / check | Source | Data definition | Destination / validation |
|---|---|---|---|
| Temperature | Field point address to fill in | Numeric type / unit to confirm | Slave → master process-data entry to assign |
| Device online | Acquisition communication status | Status encoding to agree | Slave → master status entry to assign |
How to verify
Observe a changing value at acquisition and in the master. Check diagnostics, cycle timing and device-disconnection handling. Evaluate any command path separately using an agreed, safe test point.
Confirmed capacity: 1024 points and 128 devices. The ESI file, mapping offsets and supported timing parameters still require model confirmation; the PFN1024-ARM configuration is not reused.
Remote acquisition over 4G
Choose a model that explicitly supports 4G and the required acquisition / forwarding protocols. Mobile connectivity and protocol conversion are separate selection conditions.
- 01
Field equipment
Example: Modbus RTU points
- 02
Acquisition
Local interface and reviewed driver
- 03
4G gateway
Confirmed 4G capability and point mapping
- 04
Remote transport
Operator network · MQTT example
- 05
Remote platform
Compatible MQTT endpoint
Commissioning steps
Confirm field-device points, protocol roles and the gateway interfaces; select with 4G, acquisition and forwarding conditions together.
Confirm the operator, SIM, coverage, antenna and deployment network requirements for the actual gateway.
Agree the platform endpoint, access credentials, topic / payload definition and security settings supported by both ends.
Prove local acquisition first, then verify remote updates; configure and test reconnection behavior according to the model manual.
Minimum point list / checklist
| Point / check | Source | Data definition | Destination / validation |
|---|---|---|---|
| Temperature | Field point address to fill in | Numeric value · unit / timestamp definition | Project topic and payload field to assign |
| Device online | Acquisition communication status | Status encoding / update rule to agree | Project status field to assign |
How to verify
Compare the field and platform values, then interrupt and restore the mobile connection. Record reconnection time and check whether missing data is reported or buffered by the selected model.
A 4G suffix alone does not confirm every forwarding protocol. Buffering, automatic recovery and platform compatibility must be checked for the exact model.
RT5001 transparent access and remote maintenance
Plan a remote network path for engineering access to PLCs or touchscreens. Protocol transparency is checked against the actual device, engineering tool and network arrangement.
- 01
PLC / touchscreen
Target device and project access
- 02
Local network
Confirmed device address and access service
- 03
RT5001 router
Transparent access / remote networking
- 04
Remote network
Configured networking path
- 05
Engineer workstation
Compatible engineering tool
Commissioning steps
Choose RT5001-WiFi or RT5001-WiFi-4G according to the required uplink; check the exact model datasheet and networking instructions.
Record local subnets, device addresses and required services; check for overlapping subnets on the remote side.
Complete authorized remote networking according to the model manual and verify the target device is reachable with its actual engineering tool.
Start with status reading or project comparison. Test project transfer only in an agreed maintenance window and retain a recoverable project copy.
Minimum point list / checklist
| Point / check | Source | Data definition | Destination / validation |
|---|---|---|---|
| PLC target | Project address / subnet to fill in | Engineering tool and required service | Remote reachability and project recognition |
| Remote path | Uplink and networking arrangement | Access authorization / availability | Reconnect and access-control check |
How to verify
Verify device discovery or direct addressing, online status and project identification with the actual tool. Interrupt and restore the remote path, then confirm only authorized endpoints remain accessible.
Transparent access does not itself convert a device protocol into BACnet or EtherCAT. If data conversion is also required, verify the RT5001 model’s separately documented gateway functions.
Prepare these details for faster selection
Device brand and full model, physical interface, protocol manual and point list, supervisory interface, device / point count, and read-only or write requirements.