Git и макросы TwinCAT 2 (CoDeSys)

У нас тут настолько TwinCAT 3.1, что некоторые молодые специалисты уже не видели второй версии. Что не отменяет сопровождение старых проектов и желание использовать контроль версий. К тому же есть родня в лице CoDeSys, где все также, но немного по другому.

TwinCAT 2 и Git плохо совместимы из-за бинарного формата проектов TwinCAT 2: использовать можно, но то же diff так просто не получится. Еще есть ENI (ENginering Interface), но оно стоит денег, хотя и не понятно почему? Вероятно, потому что нужен, но если что, есть бесплатное на python, но я не проверял. К тому же оно для Visual SourceSafe и SVN, а нужен Git.

Кому не нужна история или просто лень читать, может сразу пройти на гитхаб — там выложены результаты в виде проекта Tc2_Git.

Что такое, как и почему Git?

Читать можно в произвольном порядке.

1. Understanding Git (как устроен и работает Git):
• Data Model
• Branching
• Index
• Git Reset 101
2. Сходство и различие между Mercurial и Git. Ответ на вопрос: почему именно Git?
3. Git: наглядная справка.
4. Про Git. Книга и полное описание работы с Git.
5. Git How To. Интерактивный тур.

Экспорт

Первое, что необходимо сделать, это избавиться от бинарного формата проекта. В PLC Control есть возможность работать из командной строки. Оттуда же можно экспортировать проект из единого бинарного .pro файла в набор текстовых .exp файлов.

Про командную строку и командные файлы PLC Control можно прочитать в Command Line/Command File Commands. Интересно, что экспортировать можно как в один текстовый файл (project export), так и в несколько (project expmul): тогда в каждом, отдельном файле будет лежать отдельный модуль проекта. Разделение модулей по нескольким файлам в дальнейшем облегчит контроль, сравнение и откат изменений в проекте.

Кроме непосредственно экспорта понадобится еще ряд команд, поэтому без командных файлов не обойтись. И это будут не только системные батники-cmd, но и макросы PLC Control.

Макросы

Другая возможность — написать для среды разработки небольшую библиотеку макросов, добавить ее в проект и запускать экспорт непосредственно из меню PLC Control.

Я буду хранить библиотеку макросов в файле Git.mac. Название выбрано не случайно, но об этом чуть позже. Содержимое .mac файла:

MACRO
MacroName: 'Git Commit'
MacroMenu: '&Commit'
MacroCmd: 'file save'
MacroCmd: 'query off ok'
MacroCmd: 'replace yesall'
MacroCmd: 'project expmul ~project-filename-pro'
MacroCmd: 'system git add *'
MacroCmd: 'system git commit -m "%date%-%time%"'
END_MACRO

Кратко, что здесь происходит:

1. Сохраняем текущие изменения в файл проекта, делаем все по тихому и без вопросов: query off ok; replace yesall.
2. Экспортируем с разбивкой модулей по отдельным файлам .exp в подкаталог project-filename-pro с помощью project expmul.
3. Добавляем все изменения на git stage.
4. Коммитим с автоматическим комментарием в виде текущих даты-времени.

Все просто. Из недостатков — коммиты не содержат внятных комментариев и необходимость вручную вписать вместо project-filename-pro имя файла проекта. Например, есть project-name.pro, в .mac файле будет записано как project expmul ~project-name, то есть просто отбрасываем расширение файла.

Перед экспериментами не забудьте создать репозиторий через git init.

Добавляем макрос в рабочий проект. Идем в Project → Option → Macros и добавляем библиотеку макросов Git.mac через кнопку Macrolibrary → Include...

После этого появится новый раздел меню Edit → Macros → Git → Commit. Несмотря на то, что макрос назван Git Commit, система взяла за основу имя файла библиотеки макросов, то есть просто выдернула его из имени файла Git.mac. Поэтому название файла библиотеки имеет значение.

.Gitignore

Немного приберемся в каталоге проекта. Файл git-игнора может содержать следующие расширения файлов: *.dfr, *.pro, *.bak, *.ci, *.wbp. Эти файлы бинарные, поэтому лучше чтобы их не было в репозитории Git.

Git commit

Я предпочитаю использовать командную строку вместо макросов, поэтому сделал себе .cmd файл который сканирует каталог проекта в поисках .pro файлов, а затем каждый из них экспортирует в свою собственную папку вида ~имя-pro-файла. После экспорта командный файл автоматически коммитит изменения в локальный репозиторий Git. Количество .pro файлов не ограничено.

Командный файл +commit.cmd:

@echo off
SETLOCAL
set TcPlcCtrl="C:\TwinCAT\Plc\TCatPlcCtrl.exe"

if exist "*.pro" (
    FOR %%i IN ("*.pro") DO (
        CALL :ExportProject %%~ni
    )
)

del %cmd%

git add *
git commit -m '%date%-%time%'

exit /b

:ExportProject

set ProjectName=%1

set ProjectPath=%ProjectName%.pro
set cmd=__project_export.tmp
set ExportTo=~%ProjectName%

echo replace yesall > %cmd%
echo query off ok >> %cmd%
echo file open %ProjectPath% >> %cmd%
echo project expmul %ExportTo% >> %cmd%
echo file close >> %cmd%
echo file quit >> %cmd%

%TcPlcCtrl% /show hide /cmd %cmd%

exit /b

ENDLOCAL

Восстановление проекта

Если вы вдруг решите откатить текущие изменения git checkout или перескочить на другую ветку git branch, то сначала необходимо выполнить требуемые команды Git и только затем сделать импорт .exp файлов.

Я опять-таки всё автоматизировал, но только импорт. Еще раз сначала придется выполнить команды Git, и только затем выполнять +restore.cmd:

@echo off
SETLOCAL
set TcPlcCtrl="C:\TwinCAT\Plc\TCatPlcCtrl.exe"

choice /c YN /T 30 /D N /M "Do you want to restore working dir up to the last commit [default = N]"
if %ERRORLEVEL% EQU 2 EXIT 1

if exist "*.pro" (
    FOR %%i IN ("*.pro") DO (
        CALL :RestoreProject %%~ni
    )
)

del %cmd%
exit /b

:RestoreProject

set ProjectName=%1

set cmd=__project_import.tmp
set ProjectPath=%ProjectName%.pro
set ImportFrom=~%ProjectName%

echo replace yesall > %cmd%
echo query off ok >> %cmd%
echo file open %ProjectPath% >> %cmd%
echo project import %ImportFrom%\*.* >> %cmd%
echo file save
echo file close >> %cmd%
echo file quit >> %cmd%

%TcPlcCtrl% /show hide /cmd %cmd%

exit /b

ENDLOCAL