Просмотр полной версии : Как создать библиотеку?
1) Если у меня в проекте есть несколько POU, которые есть смысл использовать в ряде проектов, но при этом не хочу создавать много копий, т.к. вопрос внесения изменений в эти POU в будущем сильно усложняется - верно ли, что самое время создать библиотеку?
2) И второе. Если это самое оно, то как это делается? По меню КДС "Сохранить как" открывается немало вариантов, из которых, наверное, наиболее интересны сейчас:
- Внутренняя биб-ка (сокращение придумал не я :)
- Кодированная внутренняя биб-ка
Какая между ними разница? Или вообще я не тудЫ смотрю?
3) И еще смущает, что сохраняется весь проект. Мне нужны не все POU этого проекта в библиотеке... Так мне нужно сначала сделать проекту обрезание или пусть лишние POU болтаются?
Спасибо!
Больше того, можно не привязываться к контроллеру, т.е. None. И POU_PRG создавать не нужно
Больше того, можно не привязываться к контроллеру, т.е. None. И POU_PRG создавать не нужно
Пробую трактовать.
Значит, по вопросу 1 - ДА.
Вопрос 2 - ?
Вопрос 3 - можно и следует чистить проект перед сохранением в виде библиотеки, например, удалить главный POU и удалить те модули, в которых наличиствует таргет-зависимость. Но! - проект тогда не скомпилируется! А в описалово КДС написано, что проект, который успешно компилируется, можно сохранить в виде библиотеки.
Иначе говоря, как это делается? Вот, ставилась ли специально задача создать библиотеку, или, как в моем случае, в обычном рабочем проекте возникло ощущение, что пора выделить несколько ПОУ в библиотеку - что вы делаете после этого? Есть канонический путь?
я создал новый проект, при выборе ПЛК, то ли None выбрал, то ли вообще отмену нажал, появилось окно создать POU_PRG, тоже отказался, создал объект FB, написал код, в моем случае ПИД-регулятор, в меню выбрал сохранить как, выбрал внутреннюю библиотеку, не кодированную, так как не для комеррческих целей создавал, сохранил и пользуюсь в других проектах
Своя библиотека очень даже хорошо и создается она очень просто, при сохранении проекта выберите сохранить, как и выберите тип lib все POU сохранятся в одной библиотеке.
Ага! Значит, вопрос 2 - это по защите авторских прав. Спасибо! А если проект вполне коммерческий, то где почитать об йентом кодировании?
Значит, как всегда, куцая документация успешно дополняется опытом смелых :) Перед обзыванием нескольких ПОУ гордым словом "библиотека" нет условия их компилировать. Внутренняя библиотека - это просто нечто, добавляемое системой КДС при компиляции проекта. Будет ли это один голый ПОУ или целая куча - все равно. И их компилируемость проверится уже в целевом проекте. Верно?
Если верно, то тогда PLC-PRG надо точно вырезать. Ведь в целевом проекте он будет...
Своя библиотека очень даже хорошо и создается она очень просто, при сохранении проекта выберите сохранить, как и выберите тип lib все POU сохранятся в одной библиотеке.
То есть, PLC-PRG не нужно удалять?
Если собираетесь вырезать, то воспользуйтесь хорошими инструментами КДС, то бишь Меню -> Проект -> Контроль
А для коммерческой защиты используется специальная утилита от КДС она платная.
То есть, PLC-PRG не нужно удалять?
Само собой собираете все POU для удобства в одном проекте и сохраняете одной полной библиотекой.
Большое спасибо за дележку опытом!
Да, я смотрел на проверялку. Поработаю.
Итак, я создаю проект, в идеале его даже юзаю некоторое время, отлаживаю, проверяю на всякие глупости типа неиспользуемых переменных... Затем (так и не понял, вырезаю главную программу или нет - но по ходу разберусь) сохраняю его в виде внутренней "бибки".
Затем подгружаю к другому проекту.
Вроде ясно. А при последующей доработке библиотеки - мне нужно возвращаться в том исходный проект? Или я могу ее рихтовать прямо при работе в следующем проекте? Могу ли я править что-то в ПОУ, загруженных как библиотека?
из библиотеки Вы будете использовать конкретный ФБ, главная программа будет только место занимать, а редактировать можно, в проекте где используется библиотека, должно окошко появлятся что произошли изменения
А при последующей доработке библиотеки - мне нужно возвращаться в том исходный проект? Или я могу ее рихтовать прямо при работе в следующем проекте? Могу ли я править что-то в ПОУ, загруженных как библиотека?
Редактированию библиотека не подаётся. Исходный проект надо хранить.
из библиотеки Вы будете использовать конкретный ФБ, главная программа будет только место занимать, а редактировать можно, в проекте где используется библиотека, должно окошко появлятся что произошли изменения
Поясните по подробней как можно редактировать библиотеку.
А при последующей доработке библиотеки
:) для меня эти слова были ключевыми, дальше я не прочитал сам вопрос
дальше я не прочитал сам вопросНе расстраивайся! С моими многословными вопросами это обычное дело :)
Спасибо! Начинаю ваять "бибку" :)
Большое спасибо за дележку опытом!
Да, я смотрел на проверялку. Поработаю.
Итак, я создаю проект, в идеале его даже юзаю некоторое время, отлаживаю, проверяю на всякие глупости типа неиспользуемых переменных... Затем (так и не понял, вырезаю главную программу или нет - но по ходу разберусь) сохраняю его в виде внутренней "бибки".
Затем подгружаю к другому проекту.
Вроде ясно. А при последующей доработке библиотеки - мне нужно возвращаться в том исходный проект? Или я могу ее рихтовать прямо при работе в следующем проекте? Могу ли я править что-то в ПОУ, загруженных как библиотека?
1. PLC_PRG вырезается обязательно
2. "Рихтовать" библиотеку в проекте невозможно, можно только просмотреть в разделе Менеджер библиотек
Николаев Андрей
22.03.2011, 18:12
1. PLC_PRG вырезается обязательно
2. "Рихтовать" библиотеку в проекте невозможно, можно только просмотреть в разделе Менеджер библиотек
+1.
Создаете проект. В нем:
PLC_PRG
Необходимое количество модулей (на любых языках).
Обязательно отлаживаетесь, проверяете работу всех блоков, что Вы все необходимые переменные как var_input и var_output объявили.
Если уверенны, что править и отлаживать после правки не надо:
Оставляем только Необходимые подпрограммы.
Сохраняем ка внутреннюю библиотеку.
Если будете править, или дополнять библиотеку:
Сохраните проект. Создайте копию, и уже из копии делайте библиотеку.
ВАЖНО: никаких глобальных и уж тем более конфигурационных переменных внутри подпрограмм для библиотеки.
ВАЖНО: никаких глобальных и уж тем более конфигурационных переменных внутри подпрограмм для библиотеки.
Это рекомендация (понимаю, что настоятельная) или все же можно утверждать, что недопустимо?
Николаев Андрей
22.03.2011, 18:20
запретить не могем, но вероятность, что не заработает большая, особенно с конфигурационными. Делали на ПЛК110 - попробуйте её потом на ПЛК63 запустить...
Элементы библиотеки - это как шаблоны, родители (забыл термин из языков высокого уровня :)) То есть это в чистом виде описание алгоритма работы узла.
Например у Вас 5 одинаковых комнат. И Вы можете использовать 5 экземпляров одного и того же блока, подавая ему на входы, и получая с выходов уже конкретные переменные, привязанные к входам\выходам.
Но последнее уже в чистом виде рекомендация :)
За Ваше сообщение №18 - мерси! А рассуждения о таинственном поведении КДС как-то настораживают.
запретить не могем, но вероятность, что не заработает большая
Я попробую сформулировать несколько положений, поправьте, в чем ошибаюсь.
Имеется проект. К нему подключили некую внутреннюю библиотеку.
1) Внутренняя библиотека (ВБ) - это всего лишь POU, созданные ранее и названные ВБ. Будучи подключенной к проекту, эти POU добавлены в список модулей для компиляции и, соответственно, компилируютсяе КДС при работе с нашим проектом.
2) Как POU из списка для компиляции, эти библиотечные модули никак не отличаются от остальных POU, входящих в проект.
3) Если в библиотечном POU есть обращение к глобальным переменным проекта - компилятор не обидится. Это вопрос исключительно вкуса программиста (как и вообще широта использования глобальных переменных). Да, может быть неудобство - если эта ВБ предназначена для широкого использования. Но это не ошибка.
4) Аналогично не есть ошибкой синтаксиса обращение из библиотечных POU к конфигурационным переменным - это же, по сути, тоже глобальные переменные.
5) Если в составе ВБ есть глобальные переменные и-или конфигурационные данные, то они просто добавляются к проекту и учитываются при компиляции (этот постулат сдается мне сомнительным, но неохота же все проверять ручками - жду ответов от прошедших путь).
Таким образом, во внутренних библиотеках есть мало чего библиотечного. Это "куски" программы, написанные ранее и приклеиваемые к текущему проекту. Можно так считать?
В противоположность, попробую предположить, что внешние библиотеки компилируются до включения в проект и этим похожи на взрослые библиотеки. Так?
Еще раз оговорюсь: я не рассматриваю сейчас культуру программирования. Прекрасно понимаю опасность широкого использования глобальных переменных, важность заужения интерфейса модулей, вопросы портирования (часто здесь переоцениваемые) и прочая, и прочая... Речь сегодня о ФОРМАЛЬНЫХ ПРАВИЛАХ работы с ВБ.
Спасибо!
Николаев Андрей
23.03.2011, 12:17
Как приятно работать с человеком, который фундаментально подходит к изучению процесса. Не иронизирую.
1. А на языках высокого уровня библиотека - это не часть кода? Библиотека - это всегда шаблонные куски кода. Будь она внешней или внутренней - вопрос только в методе реализации.
2. Дальше по культуре программирования, а именно почему не стоит включать глобальные и конфигурационные переменные:
Мы разобрались, что библиотека - это описание алгоритма работы устройства, а не реализация управления конкретным устройством? Думаю здесь вопросов не возникает.
Использовать глобальные переменные в подпрограммах - мовитон (мое ИМХО), так как теряется основной плюс использования библиотек: переносимость и масштабируемость. Не могу придумать задачу, где в нескольких экземплярах одного блока требуется использовать глобальную переменную (сквозную для всего проекта).
Использовать конфигурационные переменные точно не стоит. Если Вы будете использовать данные блоки только с одним контроллером - зачем Вам библиотека? Если с разными контроллерами, то какие шансы, что совпадут адреса первого дискретного входа в ПЛК100, первого дискретного входа в ПЛК63 и первого дискретного входа у Wago750...
То есть Вы сделали библиотеку для одного, конкретного контроллера. Зачем??? В пользу ежеминутной лени? Ну не знаю.
Даст ли компилятор сделать библиотеку, включающую ссылки к глобальным и конфигурационным переменным??? Думаю даст, но я не пробовал и пробовать не собираюсь. Чего и остальным желаю ;)
Надеюсь я ответил на Ваши вопросы.
Спасибо, будем считать, что мои вопросы сейчас исчерпаны.
Могу ответить на Ваш неявно заданный вопрос:
Не могу придумать задачу, где в нескольких экземплярах одного блока требуется использовать глобальную переменную (сквозную для всего проекта).
...
То есть Вы сделали библиотеку для одного, конкретного контроллера. Зачем??? В пользу ежеминутной лени? Ну не знаю.
Вот моя задача: один контроллер, много РОДСТВЕННЫХ применений. То есть общая структура программы, большая часть (или даже все) глобальные переменные, конфигурационные переменные - абсолютно все совпадает. Но! есть модификации оборудования, различающиеся многими деталями в одном или нескольких модулях. И этот "уникальный" модуль или несколько модулей (у меня это SFC-программа и иже с ней) - совсем не ДЕЦКИЙ. Он большой, он варьируется, он и определяет поведение контроллера в РОДСТВЕННЫХ устройствах. Его написание, отладка, развитие, клонирование - основная работа на следующие год-два. Таких РОДСТВЕННЫХ устройств выпускается около 3-х десятков.
А вот именно вся фигня, которую я уже написал до сегодня - это "обслуживающие" модули. Это весь комплект работы с ИП-320, это (пока) штатный конфигуратор для работы с внешним АЦП по Модбасу, это хранение, контроль и редактирование конфигурационных параметров во ФЛЕШ-памяти ПЛК и во ФРАМ-памяти АЦП... Это нехилый кусок работы, который ОЧЕНЬ-ОЧЕНь связан и с глобальными переменными, и с переменными ввода-вывода. Но эта вся часть - абсолютно одинаковая во всех вариантах РОДСТВЕННЫХ устройств. Это как ЛИЦО, это интерфейс оператора, АЦП и энергонезависимой памяти. И что? Нельзя его скинуть в специальное место и хранить там в виде внутренней библиотеки? Слава Богу, что можно!
Надеюсь, достаточно ясно показал пример библиотеки, широко простирающей руки свои в дела глобальные и конфигурационные :) И не парит меня, что В ДРУГИХ СЛУЧАЯХ это не культурно. В моем случае это есть добро.
Аналогия: все знают, что пойнтер - вещь острая. Но понимающие люди могут его использовать грамотно - и с большой выгодой. Так и с библиотеками. Лучше не делать их с глобальными переменными. Но "блатным" можно :)
Николаев Андрей
23.03.2011, 12:42
Блатным как известно все можно. Мы же в России, ну и в Украине ;)
Но как Вы сами подтвердили мои слова - задача одна и та же, под практически один и тот же ПЛК.
Так что считаю тему раскрытой.
Разве на представленной мною картинке не глобальная переменная из сторонней библиотеки?
Разве на представленной мною картинке не глобальная переменная из сторонней библиотеки?
Похоже. Это подтверждает мое предположение, что "блатным все можно". Или, говоря строже, что компилятору пофиг, если в подключаемой библиотеке есть обращения к глобальным переменным (а может быть и к прямоадресуемым данным).
Что еще раз подтверждает желательность более точного и подробного описания КДС. Было бы, например, прямое указание на то, что библиотеками можно объявить любой набор POU, в котором нет (а может и есть?) PLC_PRG, что единственным отличием внутренней библиотеки от функций проекта есть то, что ее POU не редактируются, что компилятор допускает обращение в библиотечных функциях к глобальным переменным и так далее... Нам бы не приходилось самим проверять "границы дозволенного".
Кстати, я не знаю, является ли ComService.lib внешней или внутренней. Что такое "сторонняя библиотека"?
Доброе время суток. Подскажите правильную последовательность действий при создании и использовании библиотеки, а то у меня не получается. Вроде делаю как описано, при компиляции нет ошибок и предупреждений, а при сохранении выдает предупреждение: Access variables and variable configurations are not save in a library. А в новом проекте как я понимаю нужно воспользоватся менеджером библиотек для подключения своей библиотеки?
Николаев Андрей
30.03.2011, 11:03
Это видимо случай "блатных"... :)
Я к ним не отношусь. И если интересно мое мнение - смотрите правила создания выше. Судя по всему на конфигурационные переменные он и ругается...
Игорь Петров
30.03.2011, 11:12
Не надо отдельно сохранять проект для внутренней бибки. Файл с расширением .lib можно открыть всегда. Если это внутренняя бибка, то вы увидите все потроха. Для примера, попробуйте открыть Util.lib. Все получиться.
Вы можете ввести права доступа и поставить пароль на внутреннюю бибку чтобы никто не лазил. Это бесплатно. Вышеупомянутый платный инструмент – Менеджер лицензирования библиотек нужен только для организации их продажи (генерация ключей, создание демо и т.п.), если вдруг возникнет желание таким бизнесом заняться.
Внешние бибки так называются поскольку их код создан внешними инструментами и встроен в рантайм ПЛК. Это опция для изготовителей ПЛК. Если открыть внешнюю бибку в CoDeSys, то будут видны только объявления POU. Реализация будет пустой. Так можно их отличить.
В документации я не представляю как для каждого чиха исхитриться выдумать все варианты и каждый разрешить. Что нельзя - написано, остальное можно.
Как правило, если делается бибка, то предполагается ее давать другим людям. Тут вырастают разумные правила, которые Андрей детально пояснил. Для себя своя рука хозяйка.
nestor Вы все правильно делаете. Предупреждение просто информирует, типа надписи на заборе :)
nestor Вы все правильно делаете. Предупреждение просто информирует, типа надписи на заборе :)
Но вопрос то остается как мне воспользоваться моей библиотекой? Может я неправильно подключаю? Я думал, что после того как я добавлю её в менеджере библиотек, то она должна появится в Ассистенте ввода (F2), но там её нет. Кроме того, в менеджере библиотек в правой части есть описание переменных и рисунок, а в моей - пусто. И в информации о библиотеке тоже пусто.
Игорь Петров
30.03.2011, 13:16
..в менеджере библиотек в правой части есть описание переменных и рисунок, а в моей - пусто. И в информации о библиотеке тоже пусто.
Вы сохранили биб-ку как внешнюю! Надо как внутреннюю. Должен получиться файл с расширением lib. Проверьте чтобы он открывался в CoDeSys: Файл – Открыть – Тип файлов – Библиотека (lib).
Вы сохранили биб-ку как внешнюю! Надо как внутреннюю. Должен получиться файл с расширением lib. Проверьте чтобы он открывался в CoDeSys: Файл – Открыть – Тип файлов – Библиотека (lib).
Именно, что сохранил как внутреннюю, есть файл с расширением lib. Открывается нормально.
Игорь Петров
30.03.2011, 13:43
Именно, что сохранил как внутреннюю, есть файл с расширением lib. Открывается нормально.
Открывается нормально и вся реализация в нем видна? Если так, то обязан подключаться. Выложите тут, посмотрим.
Из картинки следует биб-ка внешняя - external.
Открывается и выглядит как обычный проект, при этом всё работает.
Открывается нормально и вся реализация в нем видна? Если так, то обязан подключаться. Выложите тут, посмотрим.
Из картинки следует биб-ка внешняя - external.
Вот выкладываю что есть. После сохранения появляются предупреждения 1900 и 1901. Именно 1900-я меня настораживает: из Справки -
Начальный POU (т.е. PLC_PRG) не доступен, если проект используется как библиотека.
а зачем Вы прогрмму создали, приглядитесь к стандартным библиотекам, там одни ФБ и функции
Игорь Петров
30.03.2011, 15:39
Начальный POU (т.е. PLC_PRG) не доступен, если проект используется как библиотека.
Так и есть.
Какой набор POU Вы рассчитываете получить из этого проекта? В нем всего 1 единственный начальный POU c именем PLC_PRG. Он при создании биб-ки удаляется, поскольку начальный POU обязан быть в проекте, где биб-ка будет применятся. 2 их быть не должно. Получим пустую библиотеку. Биб-ка предполагает много POU.
В своем проекте сделайте отдельную функцию для сложения. В PLC_PRG ее можно вызвать и протестировать. Теперь сохраняем проект как внутреннюю биб-ку. Эта функция и будет включена в биб-ку. PLC_PRG будет выброшена.
В своем проекте сделайте отдельную функцию для сложения. В PLC_PRG ее можно вызвать и протестировать. Теперь сохраняем проект как внутреннюю биб-ку. Эта функция и будет включена в биб-ку. PLC_PRG будет выброшена.
Спасибо большое, сделал так и всё заработало. Точнее я сделал библиотеку из функционального блока, тут всё ясно: вход - VAR_INPUT, выход - VAR_OUTPUT, а с функцией не совсем понятно, входные переменные я могу задать как VAR_INPUT, а для выхода нет варианта VAR_OUTPUT. Может просвятите и по этому вопросику? Заранее благодарен.
:) повторюсь, возмите чужую библиотеку, например ModBus.lib, откройте и посмотрите как выглядит FUN(функция) например MB_RTU_RX
Игорь Петров
31.03.2011, 10:03
..а с функцией не совсем понятно, входные переменные я могу задать как VAR_INPUT, а для выхода нет варианта VAR_OUTPUT
Из хелпа:
Правильно объявленная функция выглядит следующим образом:
FUNCTION Fct: INT
Имя функции используется как выходная переменная, которой присваивается результат вычислений.
Fct := 2;
Похоже ... компилятору пофиг, если в подключаемой библиотеке есть обращения к глобальным переменным (а может быть и к прямоадресуемым данным).
Уважаемый Игорь Петров не понимает всей глубины незнания новичков. Поэтому я расскажу о своем опыте по определению - что можно, чего нельзя.
Действительно компилятор дает не слишком жесткие ограничения при создании внутренней (я других не пробовал) библиотеки.
У меня был проект - и со сконфигурированной областью ввода-вывода, и с кучей глобальных переменных. Я нагло (в учебных целях) предложил Кодесису сохранить все это в виде внутренней библиотеки. Система поругалась немного и скушала! Весь проект стал библиотекой.
Потом я взял тот же проект, включил в него новую библиотеку и пустил на компиляцию. По мере ругани компилятора я выбросил из такого (практически удвоенного) проекта все, что компилятору не нравилось. А не нравилось ему то, что все POU и глобальные переменные дублировались :) Но, заметьте, выбрасывать пришлось не из библиотеки, а из проекта, в который библиотеку включили. Ведь библиотека уже скомпилирована! В конце концов, от исходного проекта осталось что? Верно, только PLC_PRG. Так как при генерации библиотеки компилятор сам выбросил из нее этот POU.
Результат: работает! Но! Вот теперь, узнав, как далеко можно изгаляться над компиляторм, начинаем и понимать, что не стОит делать. Например, попали все мои глобальные переменные в библиотеку. Да, толерантный компилятор позволил это сделать. А вот как теперь при отладке посмотреть их значения? Ага... А, не дай Бог, добавить куда-нить еще глобальную переменную? Адреса сдвинутся и тогда неизвестно, к чему программа будет обращаться.
Вот откуда вытекает правило не пихать в библиотеки глобальные переменные. Никаких чудес и "гласов свыше". Просто будет неудобно.
То же и с областью ввода-вывода. Она, будучи спрятанной в библиотеку, работать-то будет, но ни посмотреть ее толком, ни редактировать нельзя. Точнее, нужно лезть в библиотеку и там редактировать.
Значит, говорю я себе, будем все же выделять для библиотек те модули, которые работают только с локальными переменными (да со своими входными-выходными). И тут же замечаю, как безобразно раскидал по всем POU обращения к огромному пулу глобальных переменных. А ведь говорят-пишут опытные люди, что чем 'уже интерфейс программных модулей, тем надежнее и проще в отладке программа. Оказывается, тем проще и выбрасывать модули в библиотеку.
Вот пока и все, что я понял из экспериментов. Если все верно - и хорошо. Если выводы где-то ошибочны - буду благодарен за поправку. А пока начну выделять модули, действительно пригодные для канонической библиотеки.
Напоминаю, что у меня задача создания библиотеки не имеет ни какого отношения к использованию ее другими людьми. Это делается только для того, чтобы некая (желательно, значительная) часть программы была "зафиксирована". На базе одного проекта я сам буду создавать кучу вариантов - при одном и том же ПЛК, но с несколько разным поведением программы. Чем большая часть защищена от изменений, тем проще поддерживать единство такого "многовариантного" проекта.
Где-то так.
Игорь Петров
21.04.2011, 15:29
Напоминаю, что у меня задача создания библиотеки не имеет ни какого отношения к использованию ее другими людьми. Это делается только для того, чтобы некая (желательно, значительная) часть программы была "зафиксирована". На базе одного проекта я сам буду создавать кучу вариантов - при одном и том же ПЛК, но с несколько разным поведением программы. Чем большая часть защищена от изменений, тем проще поддерживать единство такого "многовариантного" проекта.
Нормальное решение.
Вообще, специально для этих целей к CoDeSys есть доп. платный компонент ENI сервер. Стоит 2.5 к.у.е. Покупается 1 раз на организацию. Идея состоит в переходе от проекта и библиотек, к полноценной базе данных. Все POU всех сотрудников компании лежат в базе. Я делаю проект и включаю в него нужные блоки. Например, управлен6ие приводами, которые делает Иванов, регуляторы, которые делает Сидоров, ну и свои всякие. Ивановские блоки я могу смотреть и включать в проект, но править не могу. Такие права он может мне не давать. В базе лежит много проектов. Все они имеют общедоступные блоки и свои. Для изменения POU я выписываю его себе из базы, правлю и записываю назад, причем не поверх, а как отдельную версию, с указанием сути правки. Сохраняется вся история целиком. Видно кто делал, что и когда. В любой момент на любую дату можно откатиться. Обычный проект в CoDeSys всякий раз перезаписывается, уничтожая старый. В ENI запоминается все.
На западе серьезные компании ставят ENI сервер, для ускорения работы и исключения нежданных ошибок людей. В России применения пока единичные.
платный ENI сервер...о_О
Тогда понятно почему программы CoDeSys в засекреченом формате .prg.
Чтобы не возможно было использовать другие, в том числе и бесплатные, серверы контроля версий типа JEDI или SVN.
Не красиво, однако...
не удивительно что в России редки случаи использование Кодесисовской системы контроля версий, не каждая фирма (и моя в том числе) может позволить себе такую деньгу выложить...
Игорь Петров
22.04.2011, 14:51
платный ENI сервер...о_О
Тогда понятно почему программы CoDeSys в засекреченом формате .prg.
:) Стандартного формата для МЭК сред не существовало до самого последнего времени. Был вариант текстовый, но он ущербный. Для профессионального инструмента не годится. Форматы от компьютерных сред не подходят. В известной конкурирующей МЭК среде проект записывается кучей разрозненных файлов, что не айс. Формат *.prg сложился исторически. Он обеспечивает хранение всех нужных объектов в одном файле, гарантирует целостность и восстановление при сбоях питания компьютера. Работает четко и надежно. Существующие альтернативы слабее.
В CoDeSys бесплатны все базовые средства разработки, в том числе OPC сервер. Сугубо опциональные, сервисные вещи платные. Они требуют работ по установке, настройке, обучению и сопровождению. Бесплатно тут никак, при всем желании. Цена ENI для организации (черные схемы не предлагать) это работа одного специалиста месяц. Ничего заоблачного тут нет. Разумный инструмент с высокой отдачей. Красивость/справедливость цен/зарплат не вопрос технического форума.
ИМХО правильно обеспечивать широкий выбор: бесплатные библиотеки, открытые, закрытые, средства ограничения прав доступа к ним, инструмент лицензирования, если нужно, командные файлы, платные инструменты и сервисы под ключ, открытые форматы и др. Каждый сам выберет нужное.
ОК, принимаю Ваше замечание в работу. В тематику приближающийся конференции (http://www.users-conference.com/index.shtml?ucru_cocept) будет включена презентация по использованию нового открытого формата проектов PLCopen XML. Он уже есть в CoDeSys. Автоматизировать операции позволяет встроенный язык скриптов. Все детали реализации мы покажем. Как стыковаться со сторонними инструментами думайте уже сами ;)
Вы можете ввести права доступа и поставить пароль на внутреннюю бибку чтобы никто не лазил. Это бесплатно. Что-то я этого проделать не могу. Откуда начинать, скажите пожалуйста!
http://images.devs-on.net/Image/jsH9BeTZ63HZCbPO-.png
Ух ты! Здорово! Спасибо!
А я сделал так: сначала проект, который делаю библиотекой, защитил паролем (Проект - Оции - Пароли), записал его просто как внутреннюю библиотеку, а затем включил эту библиотеку в "материнский" проект. и знаете, так теперь в Менеджере библиотек я вижу то, что и требовалось: только интерфейсную часть всех функций. А тело фугкций не вижу.
Наверное, от указанного Вами способа получим то же самое? Или нет? В чем будет отличие?
В чем будет отличие?
Пробую сравнить из собственных экспериментов:
1) Сохраняю проект-библиотеку как "внутрення библиотека"
2) Сохраняю проект-библиотеку как "внутрення библиотека", но сам проект защищаю паролем
3) Сохраняю проект-библиотеку как "внутрення кодированная библиотека"
После включения этой библиотеки в "материнский" проект я получаю
1) Открывается проект, втягивается библиотека (если все пути правильные) и в Менеджере библиотек я вижу только интерфейсные части всех POU библиотеки
2) абсолютно то же.
3) При открытии проекта с закодированной библиотекой меня спрашивают код.
Мне интересны варианты 1 и 2. Но в чем отличие между ними? Получается, что в любом случае тело POU внутренних библиотек не видно из проекта, в который эта библиотека включена. Верно ли я понял? Это сейчас самый главный вопрос.
А пароль на проект - исключительно защита самого проекта-библиотеки, чтобы его не испортить (или чужой не читал) Верно?
Ладно, как-то проехали.
Возник вопрос о минимальном наборе файлов, которые должны сопровождать проект при его сборке. И о конфигурировании директорий проекта.
Грубо говоря, я хочу создавать "мобильные" проекты, легко переносимые с компа на комп. Насколько я понимаю сам термин "мобильный" применительно к таким проектам, у меня на флешке может быть создана директория, в ней размещены все необходимые файлы для сборки и запуска проекта. И меня интересует, естественно, чтобы в этом наборе был минимум, необходимый и достаточный для данного проекта. Тянуть весь гамуз, щедро напиханый в директории КоДеСиса, я не хочу.
Поэтому я создал папку, в которой сам проект, а также 4 папки, требуемые КоДеСис-ом:
Библиотеки
Компил. файлы
Аплоуды (вообще не понимаю назначения)
Таргеты
В библиотеки я записал строго тот десяток либов, которые требует проект.
В таргеты скопировал то, что нужно под мой ПЛК.
Остальные свободны.
Проект собирается и даже вроде работает :)
Вопрос: как заставить КоДеСис брать таргет-файлы из моей директории, а не из той, которая в "Проект - Опции - Директории - Целевая платформа - Конфиг.файлы". Там этот путь не подсвечен и не редактируется. Но похоже, что КДС береь таргеты именно оттуда, а не из моей самодельной директории в "мобильной" папке.
Спасибо!
Ну можно заставить из своей директории. Правда левой ногой правое ухо почесать надо :)
Ну можно заставить из своей директории. Правда левой ногой правое ухо почесать надо :)
Да, я так и понял. Когда КДС установлена, то она создает свои директории таргет-файлов - и только оттуда хочет брать. Примитивно, конечно, но нам не привыкать. У КДС все через... правое ухо, если говорить о юзерском интерфейсе.
Так что - понял, при перенесении на другой комп запустить полностью готовый проект сходу нельзя. Нужно настраивать опции целевой платформы (или рассказывать заскорузлым пацанам по телефону, как это сделать).
Или я пропустил самое интересное: может на объект можно передать сразу собранный проект (ну, аналогия при программировании встраиваемых МК - .bin или .hex файл) и его как-то можно скушать в КДС, а затем в онлайне просто прошить ПЛК? Или это я же совсем оборзел?
Да, я так и понял. Когда КДС установлена, то она создает свои директории таргет-файлов - и только оттуда хочет брать. Примитивно, конечно, но нам не привыкать. У КДС все через... правое ухо, если говорить о юзерском интерфейсе.
Так что - понял, при перенесении на другой комп запустить полностью готовый проект сходу нельзя. Нужно настраивать опции целевой платформы (или рассказывать заскорузлым пацанам по телефону, как это сделать).
Или я пропустил самое интересное: может на объект можно передать сразу собранный проект (ну, аналогия при программировании встраиваемых МК - .bin или .hex файл) и его как-то можно скушать в КДС, а затем в онлайне просто прошить ПЛК? Или это я же совсем оборзел?
Вы же вроде всегда досконально разбираетесь с вопросами. А как же полазить в настройках КДС, до места где устанавливаются пути. А как же пункт меню экспорт проекта
Вы же вроде всегда досконально разбираетесь с вопросамиЧувствую, что задел святое :)
Я очень уважаю КДС, дорогой коллега. Она помогает мне решать мои задачи. Но могла бы это делать легче.
А как же полазить в настройках КДС, до места где устанавливаются пути. А как же пункт меню экспорт проекта
Поясните, плз, как это мне поможет.
1) Если Вы знаете другие места кроме Проект-Опции-Директории, то буду признателен за информацию, а не намеки.
Если это именно те места, то я там все уже вытоптал. И написал здесь, что директория Конфиг.файлы в окошке Целевая платформа моими слабыми рученками не правится. Вы знаете, как туда занести директорию, которая находится не по абсолютному адресу, скажем
C:\CoDeSys\... ,
а в моем компактном переносимом окружении, например,
..\targets\
Поделитесь, пожалуйста. Вы же вроде всегда даете хорошие практические советы.
2) А что мне даст экспорт? Вот, по Вашей подсказке сделал следующее: нормально собираемый проект экспортировал.
Запускаю КДС, открываю новый проект. Оказывается, КДС сразу хочет, чтобы я создал проект, даже если моим желанием было бы просто импортировать. И, конечно, сразу опачки: спрашивает настройки целевой платформы. Ну, приехали. Кака была кака есть. Ладно, задаю целевую платформу.
Делаю "Импорт". И что-то не то: опять все библиотеки потерялись.
Вы вслушайтесь в мой вопрос, если я еще не очень Вас замучил своими букоФФками: меня интересует перенесение проекта в максимально готовом виде (как я уже говорил, лучше всего скомпилированный) на другой комп, причем такое перенесение, чтобы там раз! - загрузил проект в КДС и можешь его компилировать и шить в ПЛК.
Пока я вижу, что на другом компе нужно танцы с бубном делать. Я это уже умею, но думал, мож есть пути попроще...
На видео экспорт импортУх ты! Оказывается. я так и делал, точь-в-точь! Спасибо!
Можно поступить как это делают модераторы, в месте с проектом в архиве расположена папка с нужным таргетом под который написан проектДык... Да. Но правильно ли я понимаю, что потом нужно эту папку подбросить в вот ту самую "нередактируемую" директорию? Вот же что меня удивляет!
Другими словами: Каково назначение строки "Конфиг.файлы" поля "Проект", если все равно КДС ищет таргеты только в тех папках, которые указаны в "нередактируемом" поле "Конфиг.файлы" поля "Целевая платформа"?
Не могу поверить, что то поле просто так. Хочу понять и использовать "свою, редактируемую" директорию.
с установкой КДС устанавливается и утилита установки таргетов, так что поставить таргет из папки куда нужно самой КДС трудностей не возникнет. Для меня удобно что можно поменять бибку с библиотеками, например на расшаренном диске в локальной сети, с любого ПК КДС будет брать именно из неё, а при таком раскладе залив последние версии только в одном месте, со всех рабочих мест бибки будут самые актуальные, остальное меня не слишком волнует, точно так же как наличие несметного количества папок в проекте из под сименса
с установкой КДС устанавливается и утилита установки таргетов, так что поставить таргет из папки куда нужно самой КДС трудностей не возникнет. Для меня удобно ...
Да, в каких-то случаях удобно. Хорошо бы, чтобы у разработчиков КДС было больше фантазии, чтобы представить разные случаи.
Вот, вожусь-экспериментирую, и снова натыкаюсь на хомут, иначе не назовешь. Во время открытия проекта, если путь к описанию целевой платформы не указан, КДС предлагает поискать. И, если чего напутал, выскакивает очень интересное предупреждение, перевести которое кому-то стало влом:
7255
А перевести следовало бы, как минимум. Ибо, нажав Да, теряешь всю конфигурацию ПЛК (которая, к тому же, никак не может быть перенесена ни копипастом, ни экспорт-импортом). Веселенькая фича. Мало того, что с конфигурацией не сделали никакой автоматизации, так ее еще и утратить запросто.
Я понимаю, что неча кликать куды не попадя, но с учетом вот такой корявости, могущей привести к потере куска проекта, не позволить юзеру таскать все свое с собой (те же таргеты, на которые сделал раз ссылку и забыл) - не слишком дальновидно.
Или я не все знаю? Может все же есть таинственный способ указать КДС место хранения описателей целевых платформ? А может и Конфигурацию ПЛК можно копипастить?
А у Вас что во время экспорта конфигурация не сохранилась?
А у Вас что во время экспорта конфигурация не сохранилась?
Экспорт, вроде, нормально. Но он мне никак не решает задачу мобильности проекта. Поэтому только попробовал и все.
Конфигурация при копировании проекта переносится, конечно в новый, слава Богу. Но играться со сменой целевой платформы (или, скажем, с указателями путей к файлам) - небезопасно. Как только КДС увидит смену ЦП, тут же и грохнет конфигурацию. С немецким предупреждением, конечно :)
drvlas наверное имел ввиду что как раз с либами - это не проблема. Все мобильно. А вот с таржетами - почему-то странные сложности.
А вот с таржетами - почему-то странные сложности.Richtig!
Движок форума отказался у меня принять сообщение менее чем из 10 символов. Не поощряется лаконичность, однако :)
А возможно ли создать библиотеку в которую входят ФБ из других библиотек.
Например написал программу, для подключения к плк сторонней аппаратуры, которая использует: ComService, Syslibcom, Util...
и хочу эту программу добавлять в другие программы.
Создал как внутреннию, сделал Фб без имени PLC_PRG, загрузил в другой проект, объявил и ничего не работает.
Фб просто не реагирует (есть и Input(EN) и Output(результат вычислений))
блоки использовать можно внутри своей бибки, только в проекте добавлять необходимо всё что используется, тогда работать будет
Попробовал просто добавить Ton, сделал бибку, загрузил в др проект, скомпилировалось, но перед загрузкой в плк выскочила ошибка о том, что использование не разрешенно. Как разрешить?
ну как бы тон входит в стандартную библиотеку. Вы либо что то не договариваете, либо используете библиотеки не подходящие для Вашего плк
Всё, спасибо, разобрался. Забыл цикл увеличить плк (тонкости моей бибки).
Библиотеки такие как ComService, syslibfile, syslibcom написаны на Codesys или другом ПО?
Вопрос вот к чему
Если написаны в Codesys, то значит в какой то мере можно самому реализовать, например открыть порт без использование бибки?
Библиотеки такие как ComService, syslibfile, syslibcom написаны на Codesys или другом ПО?
Вопрос вот к чему
Если написаны в Codesys, то значит в какой то мере можно самому реализовать, например открыть порт без использование бибки?
:) мне кажется когда проплатите лицензию или что там есть у S3 software, за разработку системных библиотек, то сможете и напрямую работать с аппаратной частью
Powered by vBulletin® Version 4.2.3 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot