Prepare a Kinco HMI backup by separating editable source, runtime application and exported process data. These files support different recovery tasks, and a successful upload does not prove that editable source was stored on the panel. Ask the project owner for the original files and matching software release, then check the exact model’s supported recovery route. Validate a duplicate before relying on it during an outage.
Separate Source, Runtime and Process Data
An editable source project is the engineering material used to change screens, objects, communications and application behavior. Keep its external resources and the software environment needed to open it. A folder containing only an installer or a compiled application does not establish that this material is present. Identify what each file actually contains before calling the folder a complete machine backup.
A compiled runtime serves a different purpose. Where the target and documentation support restoration, it may provide a way to put the application back into operation. It does not automatically provide editable screens or recover the original engineering structure. Label it as runtime, retain its originating panel identity, and record the specific restore target that still needs to be checked.
Recipes and Logs Outside the Main Project
Recipes, alarm records and logged values can have their own storage and export arrangements. Treat them as separate items until the applicable documentation establishes what an application backup includes. A recipe name is not enough to establish its meaning: preserve field order, units, permitted ranges and any association with a product or machine configuration. Historical logs also need their time context and identification.
Machine settings may live in the controller rather than the HMI. Ask the machine owner which settings are needed to resume the process, who maintains them, and whether another engineering backup is required. Restoring the display alone does not prove that those settings have been restored.
Confirm Model-Specific Upload Limits
Begin with a photograph of the full panel label and the actual project target. Record the software family and release used for the working application. The same screen size or a similar model suffix cannot establish upload support. For representative hardware records, use the GL070 and GL070E document entry and the GL2070HE software and manual record, then request the instructions applicable to the installed code.
Read the model manual and matching software help for supported transfer directions, exported file types and target restrictions. A USB connector does not establish that source upload exists. Likewise, a completed upload establishes a transfer result, not the editability of the resulting file. File extensions encountered in an archive, including propkg or prodpj, must be interpreted using the originating package documentation rather than their names alone.
Passwords and Source Storage Conditions
Use the project owner’s credentials and approved access procedure. Source recovery can depend on whether source material was stored in the first place and on access settings. If the required password or stored source is unavailable, record the limitation. Do not build an outage plan around reconstructing source from runtime or removing project protection. Ask the builder to search its archive while the existing installation remains available.
Build a Machine Backup Inventory
Create an inventory that connects every file to a machine and a recovery purpose. Record the original filename, file type, panel code, originating software release, dependencies, storage location and responsible owner. Add separate status fields for file present, copy opens, target applicability checked and restore tested. These statuses answer different questions and should not collapse into one tick beside the word backup.
| Inventory item | Validation evidence | Recovery status to record |
|---|---|---|
| Editable source | Matching package opens a duplicate with resources | Open result and unresolved dependencies |
| Runtime application | File type and applicable restore instructions | Target reviewed and restore test date |
| Recipes and logs | Export scope, field list and time context | Import mapping reviewed separately |
| Connection record | Driver, channel and endpoint worksheet | Compared with the working machine |
| Machine parameters | Approved controller or process record | Owner confirms restoration responsibility |
Name folders consistently using the machine identity and backup date. Preserve an untouched original and perform inspections on duplicates. Keep another copy away from the engineering computer used for the work. Include a short explanation of how the archive was obtained so a later technician can distinguish a builder-supplied source project from a panel upload.
Validate Files and Dependencies on a Copy
Open a duplicate source in the matching software environment. Record the actual outcome, including missing images, fonts, libraries or other referenced resources. Confirm the target and PLC driver before making conversion changes. A project that opens with missing material may still need substantial recovery work; document the missing dependency instead of hiding the warning by saving over the archive.
Review the major application functions against the machine record. Identify navigation, operator permissions, alarm text, recipe fields, communication channels and any external data paths. The purpose is to understand what must survive restoration. This review is not evidence that every function has already been tested on hardware. Keep planned checks and completed checks visibly distinct.
If the archive comes from another machine, establish which settings differ before treating it as a recovery candidate. Similar equipment can use different controller addresses or process parameters. For a target change, follow the project migration assessment rather than assuming that opening the project establishes a supported conversion. Preserve the working source before each conversion attempt.
Test the Supported Recovery Route
When editable source is available, use its documented software and target workflow on an appropriate spare or approved test arrangement. Compile the duplicate, resolve meaningful errors, verify the destination identity, and transfer using the applicable instructions. Keep experiments away from the only operating panel. Compare the resulting navigation and configuration with the original record before connecting it to a machine.
When only runtime is available, first establish whether the model documentation supports restoring that file to the proposed target. If it does, record the precise route and its limitations. If it does not, the remaining work may involve obtaining the builder’s source or developing and commissioning a new application against an agreed machine specification. These are different recovery projects, not interchangeable file operations.
A Backup File Versus a Proven Restore
A proven restore requires an observed result on the appropriate target. Record the panel code, file identity, software release, transfer method, test date and person responsible. Verify display and touch behavior, required navigation, communication settings and known PLC values. Restore recipes only after reviewing field mapping and process limits with the machine owner. A completed transfer without these checks remains a partial result.
For a physical panel replacement, add opening, mounting, supply and cable checks from the panel replacement checklist. An application backup cannot establish cabinet fit. If an older machine uses the MT070 family, retain the exact suffix and original engineering environment instead of generalizing from another seven-inch panel.
Record Restore Results and Future Ownership
Keep the accepted source, runtime where applicable, process exports and connection worksheet together. Attach the recovery procedure and the latest actual restore date. State who updates the archive after an application revision and who can supply the necessary access credentials through the site’s approved process. Revisit the test when the target, software family or machine configuration changes.
Use the Kinco manufacturer resource center to locate matching documentation. Record the document identity and applicable release in the archive; a resource-center link alone does not preserve the instructions used for a test. Keep unresolved source or restore restrictions visible in the handover.
Backup and Recovery Questions
Does uploading a Kinco HMI recover editable source?
Not necessarily. Establish the file type, source-storage conditions and access requirements for the actual target. Ask the project owner for original source before relying on a panel upload.
Should recipes and logs be backed up separately?
Treat them separately until the documented backup scope confirms coverage. Preserve field meaning, units and time context, then review the supported restore process.
How can I verify a backup before replacing the panel?
Open a source duplicate with its dependencies and test the supported restore route on an appropriate spare. Record actual results, target identity and remaining limitations before the planned outage.
