Check Kinco HMI PLC compatibility with the exact CPU or communication module, software driver and enabled service. A shared brand name or connector cannot establish application support. Record the driver’s documented family coverage, parameters and address convention, then test a known value on the intended machine. Keep a documented connection candidate separate from a tested configuration and identify missing evidence before choosing a panel.
Define Documented and Tested Compatibility
A documented candidate has a coherent connection plan supported by the matching device and driver documents. The proposed HMI supplies the required interface, the software contains the relevant driver, and the PLC offers the service and data access that driver expects. This is enough to justify further evaluation, but it is not a record of a completed machine test.
A tested configuration additionally has recorded results for specified hardware, firmware, software, parameters and application tasks. Even then, the conclusion applies to the tested scope. One correct integer read does not establish recipe transfers, every address range or production commands. Retain the distinction when communicating with purchasing so a conditional proposal does not become an unsupported compatibility promise.
Use separate status fields for document review, reference read and application acceptance. This makes a later module or software change visible: the earlier evidence remains useful, but the affected tasks require review against the revised configuration.
Identify the Exact CPU, Module and Service
Record the CPU order code, communication module, actual connected port and relevant firmware. Identify the communication service enabled in the PLC project and the role it performs. A CPU family may contain different hardware options, while a module may determine the external service available to the HMI.
The PLC engineering tool’s successful connection is useful background, but it may use a different service or access method. It does not establish that the HMI driver can reach the same data. Ask the project owner which operator values are deliberately exposed and whether access restrictions apply.
For an existing machine, preserve the working driver and parameter record before investigating a substitution. Rear connector photographs help identify the physical route; they cannot reveal the whole application configuration. Include the current project and the PLC-side data definition with the photographs.
Find Driver Evidence in the Matching Software
Identify the software family from the HMI target. The local product records list GL070 and GL070E with DTools, and GL2070HE with DTools Pro. Use the relevant release’s supported-target information and the selected driver’s connection help. The software identification guide explains how to request the matching resources.
Driver Family Coverage Versus CPU Assumptions
Save the driver name, documented device range, required options, address syntax and parameter definitions. A familiar brand entry in a driver list does not establish coverage of an unspecified CPU. Where documentation names a family or firmware limitation, retain that scope exactly rather than expanding it to every controller carrying the brand.
Use the existing Kinco download center reference to locate applicable resources and retain their release information. This article does not report a fresh manufacturer-document review or a live connection test. If the necessary driver evidence is unavailable, label the candidate unresolved and obtain the correct help before asserting support.
An electrical converter changes electrical signaling; it cannot supply an absent application protocol. A protocol gateway may provide a separate documented translation route, but its mapping, supported roles and both device connections become additional evidence requirements.
Check Serial and Ethernet Connection Requirements
A Physical Link Versus a Supported Protocol
RS485 identifies an electrical interface, not automatic Modbus RTU support. Ethernet identifies a network interface, not automatic access to a PLC protocol. Match the HMI driver, device service and physical route together before considering individual parameter values.
| Route | Evidence fields | Separate application question |
|---|---|---|
| Serial | Channel, electrical mode, connector drawing, framing and station | Does the selected protocol and role expose the intended data? |
| Ethernet | Endpoint, subnet, approved route, service and identifiers | Can this driver access the configured PLC service? |
| Gateway | Both supported protocols and mapping | Does the translation preserve address and value meaning? |
For serial links, use both manufacturers’ connector drawings, reference requirements and topology guidance. Cable colors and A/B labels are not universal signal definitions. For Ethernet, retain the site’s assigned addressing and permitted route rather than copying an illustrative address from another project.
A link indicator shows a physical observation; ping can support an IP-path observation. Neither is an application read. A blocked ping also does not independently prove failure. Use the Modbus first-read guide when that protocol is the documented route, and keep non-Modbus driver requirements with their own help.
Verify Addresses, Data Types and Access Rights
Keep the PLC data definition next to the HMI driver input convention. Address notation, numerical offset, register class, width and permissions are separate fields. Values that receive responses can still be wrong because the object reads another location or interprets the bits incorrectly.
Known Read Before Approved Write
Choose a known, non-critical value approved for observation under the machine’s maintenance procedure. Record the expected PLC value, address, type and HMI object configuration. Compare the result with PLC monitoring, including a known change where the responsible engineer permits it. This distinguishes live information from a retained display or local HMI variable.
Inspect signedness, scaling, width and byte or word order when the result differs. Do not apply a universal address adjustment. If writing is required later, use a designated commissioning variable under agreed conditions with the machine owner, verify permissions and confirmation, and keep control and safety interlocks in the PLC’s approved design. A read test does not authorize production commands.
Choose the Brand-Specific Driver Checklist
Use the relevant checklist to organize questions specific to the installed controller. These entries are investigation routes, not a list of universally supported brands or CPUs. The exact help and PLC documentation must substantiate the connection.
| Controller context | Focus for the next review |
|---|---|
| Siemens CPU and driver checklist | Exact CPU, communication access and driver-specific data requirements |
| Mitsubishi family and route checklist | Family, module, enabled protocol and device addressing |
| Omron connection checklist | Controller generation, chosen service and applicable address format |
| Allen-Bradley driver checklist | Identified controller family and the driver’s supported access method |
| Schneider server and register checklist | HMI-facing service, register class and multiword interpretation |
| Delta PLC driver checklist | Exact CPU, communication settings and documented register convention |
If multiple controller families exist on the machine, maintain a separate record for each connection. Similar project object names do not prove that both use the same service or address representation. Assign each missing document or test to the person who can supply it.
Complete the Compatibility Evidence Record
The record should contain HMI code and target software, CPU and module codes, firmware, selected driver and help version, PLC document scope, service, channel, wiring or network route, parameters and reference address. Add expected and observed values, test conditions, unresolved differences and the reviewer.
Use GL070 and GL070E hardware records or the GL2070HE product and document request for interface selection. They are model information entries, not approvals for an unspecified controller. A quotation request should state which compatibility evidence exists and which testing remains in scope.
Compatibility Questions
Does an Ethernet port prove PLC compatibility?
No. It supplies a physical interface. Driver coverage, enabled PLC service, device parameters, address syntax and permitted data access still need evidence.
What separates a documented candidate from a tested connection?
A candidate has matching documentary evidence. A tested connection also has recorded outcomes for the specified configuration and tasks; its conclusion remains limited to that scope.
Which driver evidence is needed for a specific PLC CPU?
Retain the exact driver and software release, documented CPU or module coverage, required service, connection fields and address convention alongside the installed PLC documentation. Record gaps instead of filling them with family-wide assumptions.
