Produkty PlcGit, działanie i cele

PlcGit posiada wiele funkcji

• Program PLC kopia zapasowa i przywracanie
• Sprawdź i scal różnice między wersjami oprogramowania PLC.
• Zarządzanie kodem programu PLC w rozproszonym zespole programistów

Poniższy opis stanowi przykład dla serii sterowników PLC Siemens S7 1500 z wykorzystaniem oprogramowania do programowania sterowników PLC Siemene TIA Portal

PLC Program Backup and Restore

On the first run, a repository must be defined, usually by choosing a repository name. For the initial setup, a TIA project is required. This project defines the PLC program for one or multiple PLCs, and a single repository can handle multiple TIA projects.
Each PLC is defined with its name and TCP/IP address. During setup, PLCGit reads the TIA project and displays a list of PLCs with their IP addresses. One or more PLCs can then be selected for backup and restore. The backup time and backup rate can be configured — typically once per day at night.
Internally, the TIA project is read, decoded, and all program parts are stored in the repository in a human‑readable form. Additionally, the TIA project is checked in for security reasons.

Every night, the real PLC is checked for changes. If modifications are detected, the affected elements are read from the PLC and stored in the repository. This creates a tag, identified by the timestamp and the user who made the change.

If changes — often made over a weekend — impact production on any day, maintenance personnel review the recent backups in the browser. Shift management usually knows the last stable production state to select.
The restore process then begins:
PLCGit takes the existing TIA project, reads all PLC changes, copies the project, and updates it with the changes up to Tuesday. When finished, it is downloaded to a machine with TIA Portal installed, typically used by maintenance staff. TIA is started, the project is loaded, and the affected PLC is updated and restarted. The machine will run exactly as it did on Tuesday.

Some details about backup and restore. If a nightly backup cannot be performed — usually because the PLC is unavailable — an alarm is generated and written to the logging system. Email notifications can be configured. No backup is created that night.
During restore, PLCGit performs consistency checks between the TIA project and the PLC. If the PLC hardware configuration differs, the restore may fail. This is also checked during nightly backups, and a warning is issued if differences are detected. Normally, when PLC hardware changes, a new TIA project must be checked in.

Check Differences Between PLC Program Versions and Merge

After an emergency restore — or for other reasons — maintenance personnel can check differences between detected versions or against the original TIA project. This is done in the browser.
The repository is selected from the list, then the PLC. A TIA‑like block view is shown, and changed blocks are marked. A changed block is selected, and its content is displayed in the browser in KOP/FUP/SCL/Graph, similar to TIA Portal. The block is shown twice, with both versions side by side, and detected changes are visibly highlighted. PLC program code is structured in rungs, and one rung is shown at a time. Changed rungs are marked in the rung list.

Merging allows the user to transfer complete blocks from one version to another, or merge entire rungs. Within a rung, individual elements or element groups can also be selected for merging.
Validation works the same way as a restore: Generate a TIA project, download it, open TIA Portal, load the project, and then load it into the PLC.

Manage PLC Program Code in Distributed Software Development Teams

For software development, normally no PLC exists. Multiple persons in the team are working on different parts of the PLC software. The PLC block selections and merge functions are needed only.
In this case multiple TIA projects can exist. They can be checked into a repository. For combining the code the blocks can be chosen and merged into one resulting TIA project. This can generate various merge conflicts. Such elements are marked. Then some manual work can solve the issues such as renaming some variables or blocks, or renumbering blocks. Typically the structures used in the distributed development team are different. A possible solution is the creation of a new structure in the merge containing all of the variables from the team members. But other solutions are possible also.
Different TIA versions in the team are mostly no problem. The merge from lower to higher TIA versions will always work. Stepping down can be possible if the affected PLC blocks do not use special functionality the older TIA cannot handle.
The only thing which cannot be merged is hardware configurations. They are always incompatible.