Как создать библиотеку?

[drvlas]

Похоже ... компилятору пофиг, если в подключаемой библиотеке есть обращения к глобальным переменным (а может быть и к прямоадресуемым данным).

Уважаемый Игорь Петров не понимает всей глубины незнания новичков. Поэтому я расскажу о своем опыте по определению - что можно, чего нельзя.
Действительно компилятор дает не слишком жесткие ограничения при создании внутренней (я других не пробовал) библиотеки.
У меня был проект - и со сконфигурированной областью ввода-вывода, и с кучей глобальных переменных. Я нагло (в учебных целях) предложил Кодесису сохранить все это в виде внутренней библиотеки. Система поругалась немного и скушала! Весь проект стал библиотекой.
Потом я взял тот же проект, включил в него новую библиотеку и пустил на компиляцию. По мере ругани компилятора я выбросил из такого (практически удвоенного) проекта все, что компилятору не нравилось. А не нравилось ему то, что все POU и глобальные переменные дублировались Но, заметьте, выбрасывать пришлось не из библиотеки, а из проекта, в который библиотеку включили. Ведь библиотека уже скомпилирована! В конце концов, от исходного проекта осталось что? Верно, только PLC_PRG. Так как при генерации библиотеки компилятор сам выбросил из нее этот POU.

Результат: работает! Но! Вот теперь, узнав, как далеко можно изгаляться над компиляторм, начинаем и понимать, что не стОит делать. Например, попали все мои глобальные переменные в библиотеку. Да, толерантный компилятор позволил это сделать. А вот как теперь при отладке посмотреть их значения? Ага... А, не дай Бог, добавить куда-нить еще глобальную переменную? Адреса сдвинутся и тогда неизвестно, к чему программа будет обращаться.
Вот откуда вытекает правило не пихать в библиотеки глобальные переменные. Никаких чудес и "гласов свыше". Просто будет неудобно.
То же и с областью ввода-вывода. Она, будучи спрятанной в библиотеку, работать-то будет, но ни посмотреть ее толком, ни редактировать нельзя. Точнее, нужно лезть в библиотеку и там редактировать.

Значит, говорю я себе, будем все же выделять для библиотек те модули, которые работают только с локальными переменными (да со своими входными-выходными). И тут же замечаю, как безобразно раскидал по всем POU обращения к огромному пулу глобальных переменных. А ведь говорят-пишут опытные люди, что чем 'уже интерфейс программных модулей, тем надежнее и проще в отладке программа. Оказывается, тем проще и выбрасывать модули в библиотеку.

Вот пока и все, что я понял из экспериментов. Если все верно - и хорошо. Если выводы где-то ошибочны - буду благодарен за поправку. А пока начну выделять модули, действительно пригодные для канонической библиотеки.

Напоминаю, что у меня задача создания библиотеки не имеет ни какого отношения к использованию ее другими людьми. Это делается только для того, чтобы некая (желательно, значительная) часть программы была "зафиксирована". На базе одного проекта я сам буду создавать кучу вариантов - при одном и том же ПЛК, но с несколько разным поведением программы. Чем большая часть защищена от изменений, тем проще поддерживать единство такого "многовариантного" проекта.
Где-то так.

[Игорь Петров]

Напоминаю, что у меня задача создания библиотеки не имеет ни какого отношения к использованию ее другими людьми. Это делается только для того, чтобы некая (желательно, значительная) часть программы была "зафиксирована". На базе одного проекта я сам буду создавать кучу вариантов - при одном и том же ПЛК, но с несколько разным поведением программы. Чем большая часть защищена от изменений, тем проще поддерживать единство такого "многовариантного" проекта.

Нормальное решение.

Вообще, специально для этих целей к CoDeSys есть доп. платный компонент ENI сервер. Стоит 2.5 к.у.е. Покупается 1 раз на организацию. Идея состоит в переходе от проекта и библиотек, к полноценной базе данных. Все POU всех сотрудников компании лежат в базе. Я делаю проект и включаю в него нужные блоки. Например, управлен6ие приводами, которые делает Иванов, регуляторы, которые делает Сидоров, ну и свои всякие. Ивановские блоки я могу смотреть и включать в проект, но править не могу. Такие права он может мне не давать. В базе лежит много проектов. Все они имеют общедоступные блоки и свои. Для изменения POU я выписываю его себе из базы, правлю и записываю назад, причем не поверх, а как отдельную версию, с указанием сути правки. Сохраняется вся история целиком. Видно кто делал, что и когда. В любой момент на любую дату можно откатиться. Обычный проект в CoDeSys всякий раз перезаписывается, уничтожая старый. В ENI запоминается все.

На западе серьезные компании ставят ENI сервер, для ускорения работы и исключения нежданных ошибок людей. В России применения пока единичные.

[Crusash]

платный ENI сервер...о_О
Тогда понятно почему программы CoDeSys в засекреченом формате .prg.
Чтобы не возможно было использовать другие, в том числе и бесплатные, серверы контроля версий типа JEDI или SVN.

Не красиво, однако...

не удивительно что в России редки случаи использование Кодесисовской системы контроля версий, не каждая фирма (и моя в том числе) может позволить себе такую деньгу выложить...

[Игорь Петров]

платный ENI сервер...о_О
Тогда понятно почему программы CoDeSys в засекреченом формате .prg.

Стандартного формата для МЭК сред не существовало до самого последнего времени. Был вариант текстовый, но он ущербный. Для профессионального инструмента не годится. Форматы от компьютерных сред не подходят. В известной конкурирующей МЭК среде проект записывается кучей разрозненных файлов, что не айс. Формат *.prg сложился исторически. Он обеспечивает хранение всех нужных объектов в одном файле, гарантирует целостность и восстановление при сбоях питания компьютера. Работает четко и надежно. Существующие альтернативы слабее.

В CoDeSys бесплатны все базовые средства разработки, в том числе OPC сервер. Сугубо опциональные, сервисные вещи платные. Они требуют работ по установке, настройке, обучению и сопровождению. Бесплатно тут никак, при всем желании. Цена ENI для организации (черные схемы не предлагать) это работа одного специалиста месяц. Ничего заоблачного тут нет. Разумный инструмент с высокой отдачей. Красивость/справедливость цен/зарплат не вопрос технического форума.

ИМХО правильно обеспечивать широкий выбор: бесплатные библиотеки, открытые, закрытые, средства ограничения прав доступа к ним, инструмент лицензирования, если нужно, командные файлы, платные инструменты и сервисы под ключ, открытые форматы и др. Каждый сам выберет нужное.

ОК, принимаю Ваше замечание в работу. В тематику приближающийся конференции будет включена презентация по использованию нового открытого формата проектов PLCopen XML. Он уже есть в CoDeSys. Автоматизировать операции позволяет встроенный язык скриптов. Все детали реализации мы покажем. Как стыковаться со сторонними инструментами думайте уже сами

[drvlas]

Вы можете ввести права доступа и поставить пароль на внутреннюю бибку чтобы никто не лазил. Это бесплатно.

Что-то я этого проделать не могу. Откуда начинать, скажите пожалуйста!

[Yegor]

[drvlas]

Ух ты! Здорово! Спасибо!

А я сделал так: сначала проект, который делаю библиотекой, защитил паролем (Проект - Оции - Пароли), записал его просто как внутреннюю библиотеку, а затем включил эту библиотеку в "материнский" проект. и знаете, так теперь в Менеджере библиотек я вижу то, что и требовалось: только интерфейсную часть всех функций. А тело фугкций не вижу.

Наверное, от указанного Вами способа получим то же самое? Или нет? В чем будет отличие?

[drvlas]

В чем будет отличие?

Пробую сравнить из собственных экспериментов:

1) Сохраняю проект-библиотеку как "внутрення библиотека"
2) Сохраняю проект-библиотеку как "внутрення библиотека", но сам проект защищаю паролем
3) Сохраняю проект-библиотеку как "внутрення кодированная библиотека"

После включения этой библиотеки в "материнский" проект я получаю

1) Открывается проект, втягивается библиотека (если все пути правильные) и в Менеджере библиотек я вижу только интерфейсные части всех POU библиотеки
2) абсолютно то же.
3) При открытии проекта с закодированной библиотекой меня спрашивают код.

Мне интересны варианты 1 и 2. Но в чем отличие между ними? Получается, что в любом случае тело POU внутренних библиотек не видно из проекта, в который эта библиотека включена. Верно ли я понял? Это сейчас самый главный вопрос.
А пароль на проект - исключительно защита самого проекта-библиотеки, чтобы его не испортить (или чужой не читал) Верно?

[drvlas]

Ладно, как-то проехали.

Возник вопрос о минимальном наборе файлов, которые должны сопровождать проект при его сборке. И о конфигурировании директорий проекта.

Грубо говоря, я хочу создавать "мобильные" проекты, легко переносимые с компа на комп. Насколько я понимаю сам термин "мобильный" применительно к таким проектам, у меня на флешке может быть создана директория, в ней размещены все необходимые файлы для сборки и запуска проекта. И меня интересует, естественно, чтобы в этом наборе был минимум, необходимый и достаточный для данного проекта. Тянуть весь гамуз, щедро напиханый в директории КоДеСиса, я не хочу.

Поэтому я создал папку, в которой сам проект, а также 4 папки, требуемые КоДеСис-ом:
Библиотеки
Компил. файлы
Аплоуды (вообще не понимаю назначения)
Таргеты

В библиотеки я записал строго тот десяток либов, которые требует проект.
В таргеты скопировал то, что нужно под мой ПЛК.
Остальные свободны.

Проект собирается и даже вроде работает

Вопрос: как заставить КоДеСис брать таргет-файлы из моей директории, а не из той, которая в "Проект - Опции - Директории - Целевая платформа - Конфиг.файлы". Там этот путь не подсвечен и не редактируется. Но похоже, что КДС береь таргеты именно оттуда, а не из моей самодельной директории в "мобильной" папке.

Спасибо!

[Валенок]

Ну можно заставить из своей директории. Правда левой ногой правое ухо почесать надо