What this integration guide is for
This guide is for an engineer with a Kinco HMI, a PLC, and a machine data list to connect. It focuses on the decisions that determine whether values are read correctly, commands are written safely, and communication faults remain visible. It does not assume a universal cable, a universal register offset, or a default serial setting.
Start with the exact order codes and manuals, then use the HMI product family and PLC product family as record indexes. A family page helps locate reviewed models; it does not prove that two devices share a physical interface, protocol driver, or compatible application role.
The official Kinco G2 HMI page identifies the G2 family and DToolsPro engineering software. The Modbus Organization specification library is the authority for Modbus application and serial guidance. The device manuals still control the exact ports, roles, addressing, and supported functions for the selected models.
Choose the communication path before creating tags
Do not begin by drawing screens. First decide which physical interface and protocol instance will carry the data. For a serial path, verify the port electrical standard on both devices, the network topology, termination and biasing requirements, and which device is responsible for requests. For an Ethernet path, verify the physical network, IP plan, service port, device role, connection limits, and how communication loss is exposed.
The Modbus RTU definition is useful for aligning terms, but the word “Modbus” alone is not a connection design. A working path requires compatible roles. A client initiates transactions; a server responds. The project must also agree on station or unit addressing, supported function codes, register ownership, and write policy.
| Decision | Evidence from the HMI | Evidence from the PLC |
|---|---|---|
| Physical path | Exact port and electrical interface | Exact port and electrical interface |
| Protocol role | Driver and client/server or master/slave role | Supported role for the selected interface |
| Addressing | Station, unit or network target in the project | Address assigned to the PLC endpoint |
| Data access | Read/write objects supported by the driver | Published register or variable exposure |
| Fault behavior | Timeout, quality and operator indication | Watchdog, command validity and safe response |
Record those decisions in a one-page communication boundary before opening DToolsPro. If any row is unknown, keep the path pending instead of compensating with guessed parameters.
Use verified model records without extending them
A concrete example helps show what “exact interface” means. The reviewed Kinco G2070HE record lists a 7-inch, 1024×600 HMI with COM0 supporting RS232, RS485 and RS422; COM1 supporting RS485 and RS422; COM2 supporting RS232; and a 10/100 Ethernet interface. Those are model-level fields from the official source record, not defaults for every Kinco HMI.
The reviewed K615S PLC record lists two isolated RS485 interfaces for Modbus RTU master or slave operation, one Ethernet interface for Modbus TCP client or server operation, and one CAN interface. That establishes possible interface paths for that PLC record. It does not choose the path, assign the role, or define the register map for a machine.
| Reviewed record | Verified communication evidence | What still requires project review |
|---|---|---|
| Kinco G2070HE | COM0/COM1 serial options, COM2 RS232, 10/100 Ethernet | Exact driver, port assignment, cable, role and settings |
| Kinco K615S | Isolated RS485, Modbus RTU roles, Ethernet Modbus TCP roles, CAN | Program exposure, addresses, function support and failure logic |
Do not transfer the G2070HE port list to a different HMI because it belongs to the same broad family. Do not infer that an Ethernet-only field proves serial capability. The exact HMI and PLC records must both support the chosen path.
Build a tag map that can be reviewed
The tag map is the contract between the PLC program and the HMI project. Give each item a stable engineering name and document both ends. At minimum, record the HMI tag, PLC variable or register, data direction, data type, width, signedness, engineering unit, scale, valid range, update expectation, write permission, and invalid-data behavior.
Separate status from command data. A displayed motor state may be read-only, while a start request is a controlled write that the PLC must qualify through permissives and interlocks. Do not let an HMI write directly to an output merely because a driver makes the address available. The PLC remains responsible for machine sequencing and the approved safety boundary.
Pay particular attention to values that occupy more than one register. The two projects must agree on register order, byte order, signedness, floating-point representation, and scaling. A plausible number can still be wrong if its words are reversed or its engineering scale is missing. Add test values that make those errors obvious rather than testing only zero.
Use a versioned tag-map file and keep it with both source projects. When a PLC variable, address, or data type changes, update the map before editing the HMI.
Configure the project in controlled stages
Build the connection in small steps so each fault has a limited search area:
- Freeze the evidence. Save the HMI order code, PLC order code, firmware, relevant manual revisions, network diagram, and initial tag map.
- Configure one path. Select the exact HMI driver and PLC endpoint, then enter only the verified interface, role and addressing values.
- Prove one read. Read a stable status value with a known data type and compare it with the PLC online value.
- Prove representation. Test signed, multi-register, scaled and non-zero values before duplicating tags.
- Prove one controlled write. Use a non-hazardous test condition, confirm PLC qualification, and verify the HMI cannot bypass interlocks.
- Expand by function. Add related tags in reviewable groups, preserving names, comments and ownership.
- Record the result. Capture accepted values, faults found, corrections, software versions and the person responsible for approval.
Do not make the first test on a running production sequence. A bench or controlled machine state gives the team time to inspect raw PLC values, HMI quality state, request traffic, and recovery without turning a communication mistake into an unintended command.
Diagnose shifted, stale or incorrect values
When communication fails completely, check the physical path and role before editing tags. Confirm power, cable and link state, serial wiring or Ethernet addressing, selected ports, station or unit target, and whether one side is actually initiating requests. A timeout is not evidence that the register address is wrong; it may mean the endpoint was never reached.
When some tags work and others do not, compare the failed item with the tag map. Common causes include an unsupported function, read/write ownership mismatch, address convention difference, data-width mismatch, or a PLC variable that was never exposed to the protocol. Test the raw value before applying scaling.
When the value changes but looks implausible, verify signedness, byte order, word order, data type and engineering scale. When it is stale, verify the PLC update, HMI scan policy, connection state and the screen’s quality indication. The HMI should not present a last-known value as current without a visible communication state.
Commission writes and recovery deliberately
Every write path needs an owner, a permitted operating state, and a defined response to communication loss. Momentary and maintained commands behave differently. Setpoint writes may need range checks and acknowledgement. Recipe transfers may need a version or completeness check before the PLC accepts them. Document what the operator sees when a write is rejected.
Exercise HMI restart, PLC restart, network interruption, serial cable loss, invalid data, timeout, and reconnection. Confirm that writes do not replay unexpectedly after recovery and that stale commands cannot remain latched without PLC supervision. Machine safety functions remain inside the verified safety architecture; ordinary HMI communication is not a safety channel.
Boundaries and limitations
This workflow provides a commissioning method, not a universal Kinco-to-PLC compatibility claim. It does not provide project-specific register addresses, serial defaults, cable pinouts, driver availability, firmware behavior, or safe-state logic. Those items must come from the exact HMI, PLC, software and machine evidence.
- A family name does not prove that every model has the same ports or protocol roles.
- A successful read does not validate writes, timing, recovery, alarms or machine safety.
- DToolsPro menu paths and driver names may vary with the maintained software version.
- Third-party PLC programs and HMI projects do not convert automatically into verified Kinco projects.
- Hardware availability, documentation, price and lead time are confirmed at RFQ.
Next step for a real HMI and PLC pair
Prepare the two order codes, firmware, current project files, port plan, PLC variable or register list, required screens, write permissions, failure-state requirements and acceptance tests. For scoped implementation and bench support, use the HMI and PLC programming service. The engineering review should return a documented path, not an assumed driver choice.
Questions engineers ask
What must match before a Kinco HMI can communicate with a PLC?
The exact devices must share a supported physical interface and protocol instance, with complementary client/server or master/slave roles. The project must also match addressing, supported functions, data representation, access rights, timeout behavior and the PLC variables exposed to that interface.
Which side should be the Modbus client?
Choose the role from the maintained system architecture and the roles supported by the exact devices. The client initiates requests and therefore owns the polling or transaction policy. Do not assign both endpoints the same role or infer a role from a connector alone.
Why is a tag shifted, stale or numerically wrong?
Compare the tag with the map. Check address convention, data width, signedness, byte and word order, scaling, PLC update logic, HMI scan policy and communication quality. Test a known non-zero value at both ends before changing several settings at once.
What should be bench-tested before enabling writes?
Test representative reads, controlled writes, range rejection, interlocks, HMI and PLC restart, cable loss, timeout, stale-data indication and recovery. Confirm that a reconnect cannot replay an unsafe command and that PLC logic remains responsible for machine permission and safety boundaries.