На чужом ПК «библиотека не найдена» в CODESYS: зависимости, путь и vendor

Подрядчик прислал архив проекта на флешке. Вы распаковали, открыли .project в CODESYS 3.5 - и сразу красный список: «Library not found», «Device description missing», «Placeholder device». Компиляция не идёт, в дереве устройства серые крестики. На машине автора проекта всё собиралось вчера. Заказчик ждёт правку по аварии, а вы тратите час на поиск .library в чужих папках.

Так выглядит типичная передача проекта без пакета зависимостей. Ошибка на ПК разработчика - это про пути, vendor, managed/unmanaged библиотеки и Device Repository. Это не то же самое, что «проект не загружается в ПЛК»: контроллер может быть исправен, а среда на ноутбуке просто не знает, откуда взять IoDrvModbus или кастомный FB от интегратора. Статья разбирает, как передать проект так, чтобы он открылся у коллеги, и что делать, если архив уже пришёл «голым». Урок по первому подключению к ПЛК и online download - в других материалах.

Короткий ответ

Сообщение «библиотека не найдена» в CODESYS на чужом ПК почти всегда значит: в проекте есть ссылка на .library или device description, которых нет в стандартной установке получателя. Проверьте список зависимостей в Project → Library Manager, версии CODESYS и компилятора, наличие vendor-пакета (папка производителя оборудования в Device Repository). Для передачи используйте «Project → Archive → Archive project» с включёнными библиотеками или экспортируйте managed libraries вместе с проектом. Unmanaged библиотеки кладут в общую папку ...\CODESYS V3.5.xxx\ или указывают путь в настройках. Отличие от ошибки загрузки в ПЛК: здесь проект не компилируется на ПК, до контроллера дело не доходит.

Managed и unmanaged: две разные боли

В CODESYS библиотеки бывают managed (устанавливаются через Package Manager, версионируются внутри экосистемы) и unmanaged (лежат как файлы .library в произвольной папке, на них ссылается проект по пути или по имени). Managed удобны при обновлении: одна версия на всех машинах команды. Unmanaged часто тянут за собой интеграторы - драйвер полевой шины, блоки от стороннего vendor, старый FB «с прошлого объекта».

Когда проект открывается на чужом ПК, среда ищет каждую зависимость по каталогу установки и по записям в .project. Если файл отсутствует или версия ниже требуемой, появляется «not found» или «incompatible version». Placeholder device - отдельный случай: описание устройства (device description) не установлено в Device Repository, хотя логика и библиотеки на месте.

Правило для команды: в README к релизу пишут не только номер проекта, но и список пакетов Package Manager с версиями плюс отдельный zip с unmanaged, если они есть.

Vendor folder и Device Repository

Производитель ПЛК и модулей I/O поставляет device descriptions - XML/GSD-подобные описания для CODESYS Device Repository. Путь обычно: C:\ProgramData\CODESYS\Devices\ или подпапка vendor после установки пакета с сайта производителя. На «родном» ПК интегратора пакет стоял год назад при первом пуске; на ноутбуке заказчика его никто не ставил.

Симптомы: в дереве устройства красный крест, в сообщениях - «Device not found» или «Unknown device type». Библиотеки при этом могут компилироваться, но target device не выбрать. Решение: установить тот же device package с той же или совместимой версией, что в паспорте проекта. Для оборудования с открытой документацией пакет кладут в git рядом с проектом (папка vendor/ или devices/) и фиксируют в регламенте версионирования.

Не путайте device description с библиотекой прикладного кода. Первое - «какое железо в дереве», второе - «какие FB и функции доступны в коде».

Версия CODESYS и компилятора

Проект, сохранённый в 3.5.16.40, может отказаться открываться или пересобираться в 3.5.14 без предупреждений о несовместимости библиотек. Компилятор и runtime target тоже должны совпадать с тем, что на объекте, иначе после «успешной» сборки на чужом ПК получите расхождение поведения при загрузке.

При передаче архива указывайте три числа: версия IDE, версия компилятора (Compiler version в свойствах устройства), версия runtime на ПЛК. Если получатель обновил CODESYS «просто потому что вышло обновление», Library Manager может предложить обновить зависимости - соглашайтесь только осознанно, с тегом в git и проверкой на стенде.

Базовая настройка среды и первое подключение разобраны в первом старте CODESYS 3.5 - там же про выбор target и установку пакетов под конкретное железо.

Как правильно передать проект коллеге

Надёжный способ - Archive project с опцией включения используемых библиотек (зависит от версии: «Include libraries», «Archive with libraries»). Получатель делает Install archive - зависимости разворачиваются в его профиль. Для git-команды дополнительно хранят *.library unmanaged в репозитории и скрипт копирования в %COMMONPROGRAMDATA%\CODESYS\... или в путь из .library-path в документации команды.

Плохой способ - скинуть только .project и папку PlcLogic по почте. Хороший - архив CODESYS плюс текстовый manifest: список библиотек с версиями, ссылка на installer device package, хеш коммита. Перед отправкой на чужой ПК проверьте открытие на чистой виртуалке или у коллеги без вашего vendor-кэша.

Если проект использует сетевые репозитории библиотек (внутренний NuGet-подобный сервер компании), получатель должен иметь VPN и те же URL в Package Manager. Иначе managed libs тоже окажутся «not found».

Что делать, когда архив уже «голый»

Откройте Library Manager и выпишите всё с жёлтым/красным статусом. Запросите у автора архив или точные версии пакетов. Временный обход - заменить missing library на placeholder и закомментировать вызовы - только для чтения логики, не для пуска.

Для unmanaged попросите файлы .library и положите их в каталог, который CODESYS сканирует (Tools → Options → Paths, или стандартная папка Libraries). Перезапустите IDE. Если библиотека проприетарная и автор «потерял» файл - остаётся реверс по скомпилированному .app на ПЛК, что долго и не всегда законно по договору.

Device missing решается установкой пакета vendor. Не подставляйте «Generic PLC» и не грузите в чужое железо без сверки - это путь к другой статье про отладку после download.

Отличие от ошибки загрузки в ПЛК

На объекте инженер иногда путает «не компилируется у меня на ноутбуке» и «не качается в контроллер». Второе: build успешен, при Login/Download - ошибка связи, несовпадение application, нехватка памяти, неверный boot project. Первое: в статусной строке уже на этапе Build - missing library, unresolved reference.

Если библиотека найдена, но версия старше требуемой в проекте, компилятор может выдать warning и собрать с другим поведением FB - это опаснее, чем явный «not found». Сверяйте столбец Required version в Library Manager.

Online-отладка при отсутствующих libs на ПК невозможна; при этом ПЛК может продолжать работать со старым application, загруженным когда-то с машины автора. Оператор видит процесс, а новый инженер не может внести правку - классический разрыв между полем и офисом.

Git, manifest и повторяемая сборка

Минимальный регламент для двух-трёх человек: в репозитории лежат проект, libraries/ с unmanaged, devices/readme.txt со ссылками на installers, файл codesys-version.txt. CI не обязателен - достаточно, чтобы любой клонировал repo и прошёл чек-лист установки пакетов перед Build. Подробнее про ветки и теги релизов - в версионировании проектов ПЛК.

Не коммитьте гигабайтные кэши Package Manager целиком - только то, что реально нужно для сборки, иначе через год никто не разберёт, какая половина устарела.

Package Manager: обновления, которые ломают чужой ПК

Кнопка «Update all libraries» на свежей установке CODESYS - частая причина «у меня не собирается». Проект требовал Standard 3.5.16.0, Package Manager поставил 3.5.17.x, изменилась сигнатура FB - компилятор ругается на несовместимость или молча меняет поведение. На чужом ПК правильнее: открыть Archive, не трогать глобальные обновления, установить ровно те версии из manifest.

Если автор проекта уволился, а в git только .project без libraries - ищите старый ноутбук или бэкап C:\Users\...\CODESYS\.... В крайнем случае заказчик ставит ту же сборку CODESYS с официального образа, что в паспорте объекта, и только потом Archive.

Чек-лист перед отправкой проекта заказчику

Перед передачей на сторону интегратор делает четыре шага на своей машине. Собрать проект Clean + Rebuild без warning по missing. Создать Archive project с библиотеками. На второй машине (или VM) установить Archive с нуля и повторить Build. Записать в сопроводительном письме версию IDE, список device packages и хеш git-тега. Это дешевле одного дня простоя на пуске из-за «библиотека не найдена».

При сопровождении объекта храните копию последнего успешного Archive на файловом сервере заказчика, не только на ноутбуке наладчика. Флешки теряются, пути забываются.

Если заказчик запрещает установку сторонних библиотек на свой ПК, передавайте не проект для разработки, а подписанный .app и исходники в read-only архиве для аудита - иначе «библиотека не найдена» станет постоянным статусом сопровождения.

Сообщение, причина и передача проекта

Вопросы с пуска

Можно ли открыть проект без библиотеки, только посмотреть код?
Частично - в режиме read-only с placeholder, но FBD/ST с вызовами missing FB не разберёшь. Для аудита запросите полный архив у автора.

Достаточно ли скопировать папку CODESYS V3.5 целиком?
Ненадёжно: лицензии, пути, мусор в кэше. Лучше штатный Archive project и manifest версий.

Кто виноват - отправитель или получатель?
По договору обычно отправитель обязан передать собираемый комплект. Получатель обязан не обновлять среду без согласования. Фиксируйте версии письменно.

Placeholder device - можно ли так оставить на объекте?
Нет для эксплуатации. Только для просмотра логики на ПК до установки vendor package.

Нужен ли тот же Windows и тот же диск C:?
Нет, но пути к unmanaged иногда прописаны абсолютные в старых проектах - тогда правят Paths в Options или кладут lib в ожидаемое имя файла.

Ссылки по теме

• Первый старт CODESYS 3.5: документация, подключение, интерфейс;
• Версионирование проектов ПЛК: Git на практике;
• Structured Text: почему инженеры ПЛК его выбирают;
• Технический долг legacy-ПЛК: когда рефакторить;
• Пакет документов при вводе в эксплуатацию АСУ ТП.