из библиотеки Вы будете использовать конкретный ФБ, главная программа будет только место занимать, а редактировать можно, в проекте где используется библиотека, должно окошко появлятся что произошли изменения
из библиотеки Вы будете использовать конкретный ФБ, главная программа будет только место занимать, а редактировать можно, в проекте где используется библиотека, должно окошко появлятся что произошли изменения
Поясните по подробней как можно редактировать библиотеку.Сообщение от capzap
запретить не могем, но вероятность, что не заработает большая, особенно с конфигурационными. Делали на ПЛК110 - попробуйте её потом на ПЛК63 запустить...
Элементы библиотеки - это как шаблоны, родители (забыл термин из языков высокого уровня) То есть это в чистом виде описание алгоритма работы узла.
Например у Вас 5 одинаковых комнат. И Вы можете использовать 5 экземпляров одного и того же блока, подавая ему на входы, и получая с выходов уже конкретные переменные, привязанные к входам\выходам.
Но последнее уже в чистом виде рекомендация
За Ваше сообщение №18 - мерси! А рассуждения о таинственном поведении КДС как-то настораживают.
Я попробую сформулировать несколько положений, поправьте, в чем ошибаюсь.
Имеется проект. К нему подключили некую внутреннюю библиотеку.
1) Внутренняя библиотека (ВБ) - это всего лишь POU, созданные ранее и названные ВБ. Будучи подключенной к проекту, эти POU добавлены в список модулей для компиляции и, соответственно, компилируютсяе КДС при работе с нашим проектом.
2) Как POU из списка для компиляции, эти библиотечные модули никак не отличаются от остальных POU, входящих в проект.
3) Если в библиотечном POU есть обращение к глобальным переменным проекта - компилятор не обидится. Это вопрос исключительно вкуса программиста (как и вообще широта использования глобальных переменных). Да, может быть неудобство - если эта ВБ предназначена для широкого использования. Но это не ошибка.
4) Аналогично не есть ошибкой синтаксиса обращение из библиотечных POU к конфигурационным переменным - это же, по сути, тоже глобальные переменные.
5) Если в составе ВБ есть глобальные переменные и-или конфигурационные данные, то они просто добавляются к проекту и учитываются при компиляции (этот постулат сдается мне сомнительным, но неохота же все проверять ручками - жду ответов от прошедших путь).
Таким образом, во внутренних библиотеках есть мало чего библиотечного. Это "куски" программы, написанные ранее и приклеиваемые к текущему проекту. Можно так считать?
В противоположность, попробую предположить, что внешние библиотеки компилируются до включения в проект и этим похожи на взрослые библиотеки. Так?
Еще раз оговорюсь: я не рассматриваю сейчас культуру программирования. Прекрасно понимаю опасность широкого использования глобальных переменных, важность заужения интерфейса модулей, вопросы портирования (часто здесь переоцениваемые) и прочая, и прочая... Речь сегодня о ФОРМАЛЬНЫХ ПРАВИЛАХ работы с ВБ.
Спасибо!
Как приятно работать с человеком, который фундаментально подходит к изучению процесса. Не иронизирую.
1. А на языках высокого уровня библиотека - это не часть кода? Библиотека - это всегда шаблонные куски кода. Будь она внешней или внутренней - вопрос только в методе реализации.
2. Дальше по культуре программирования, а именно почему не стоит включать глобальные и конфигурационные переменные:
- Мы разобрались, что библиотека - это описание алгоритма работы устройства, а не реализация управления конкретным устройством? Думаю здесь вопросов не возникает.
- Использовать глобальные переменные в подпрограммах - мовитон (мое ИМХО), так как теряется основной плюс использования библиотек: переносимость и масштабируемость. Не могу придумать задачу, где в нескольких экземплярах одного блока требуется использовать глобальную переменную (сквозную для всего проекта).
- Использовать конфигурационные переменные точно не стоит. Если Вы будете использовать данные блоки только с одним контроллером - зачем Вам библиотека? Если с разными контроллерами, то какие шансы, что совпадут адреса первого дискретного входа в ПЛК100, первого дискретного входа в ПЛК63 и первого дискретного входа у Wago750...
То есть Вы сделали библиотеку для одного, конкретного контроллера. Зачем??? В пользу ежеминутной лени? Ну не знаю.
Даст ли компилятор сделать библиотеку, включающую ссылки к глобальным и конфигурационным переменным??? Думаю даст, но я не пробовал и пробовать не собираюсь. Чего и остальным желаю
Надеюсь я ответил на Ваши вопросы.
Последний раз редактировалось Николаев Андрей; 23.03.2011 в 12:19.
Спасибо, будем считать, что мои вопросы сейчас исчерпаны.
Могу ответить на Ваш неявно заданный вопрос:
Вот моя задача: один контроллер, много РОДСТВЕННЫХ применений. То есть общая структура программы, большая часть (или даже все) глобальные переменные, конфигурационные переменные - абсолютно все совпадает. Но! есть модификации оборудования, различающиеся многими деталями в одном или нескольких модулях. И этот "уникальный" модуль или несколько модулей (у меня это SFC-программа и иже с ней) - совсем не ДЕЦКИЙ. Он большой, он варьируется, он и определяет поведение контроллера в РОДСТВЕННЫХ устройствах. Его написание, отладка, развитие, клонирование - основная работа на следующие год-два. Таких РОДСТВЕННЫХ устройств выпускается около 3-х десятков.
А вот именно вся фигня, которую я уже написал до сегодня - это "обслуживающие" модули. Это весь комплект работы с ИП-320, это (пока) штатный конфигуратор для работы с внешним АЦП по Модбасу, это хранение, контроль и редактирование конфигурационных параметров во ФЛЕШ-памяти ПЛК и во ФРАМ-памяти АЦП... Это нехилый кусок работы, который ОЧЕНЬ-ОЧЕНь связан и с глобальными переменными, и с переменными ввода-вывода. Но эта вся часть - абсолютно одинаковая во всех вариантах РОДСТВЕННЫХ устройств. Это как ЛИЦО, это интерфейс оператора, АЦП и энергонезависимой памяти. И что? Нельзя его скинуть в специальное место и хранить там в виде внутренней библиотеки? Слава Богу, что можно!
Надеюсь, достаточно ясно показал пример библиотеки, широко простирающей руки свои в дела глобальные и конфигурационные
Аналогия: все знают, что пойнтер - вещь острая. Но понимающие люди могут его использовать грамотно - и с большой выгодой. Так и с библиотеками. Лучше не делать их с глобальными переменными. Но "блатным" можно
Блатным как известно все можно. Мы же в России, ну и в Украине
Но как Вы сами подтвердили мои слова - задача одна и та же, под практически один и тот же ПЛК.
Так что считаю тему раскрытой.
Разве на представленной мною картинке не глобальная переменная из сторонней библиотеки?
Последний раз редактировалось capzap; 05.11.2011 в 21:49.
Похоже. Это подтверждает мое предположение, что "блатным все можно". Или, говоря строже, что компилятору пофиг, если в подключаемой библиотеке есть обращения к глобальным переменным (а может быть и к прямоадресуемым данным).
Что еще раз подтверждает желательность более точного и подробного описания КДС. Было бы, например, прямое указание на то, что библиотеками можно объявить любой набор POU, в котором нет (а может и есть?) PLC_PRG, что единственным отличием внутренней библиотеки от функций проекта есть то, что ее POU не редактируются, что компилятор допускает обращение в библиотечных функциях к глобальным переменным и так далее... Нам бы не приходилось самим проверять "границы дозволенного".
Кстати, я не знаю, является ли ComService.lib внешней или внутренней. Что такое "сторонняя библиотека"?
Уважаемый Игорь Петров не понимает всей глубины незнания новичков. Поэтому я расскажу о своем опыте по определению - что можно, чего нельзя.
Действительно компилятор дает не слишком жесткие ограничения при создании внутренней (я других не пробовал) библиотеки.
У меня был проект - и со сконфигурированной областью ввода-вывода, и с кучей глобальных переменных. Я нагло (в учебных целях) предложил Кодесису сохранить все это в виде внутренней библиотеки. Система поругалась немного и скушала! Весь проект стал библиотекой.
Потом я взял тот же проект, включил в него новую библиотеку и пустил на компиляцию. По мере ругани компилятора я выбросил из такого (практически удвоенного) проекта все, что компилятору не нравилось. А не нравилось ему то, что все POU и глобальные переменные дублировались
Результат: работает! Но! Вот теперь, узнав, как далеко можно изгаляться над компиляторм, начинаем и понимать, что не стОит делать. Например, попали все мои глобальные переменные в библиотеку. Да, толерантный компилятор позволил это сделать. А вот как теперь при отладке посмотреть их значения? Ага... А, не дай Бог, добавить куда-нить еще глобальную переменную? Адреса сдвинутся и тогда неизвестно, к чему программа будет обращаться.
Вот откуда вытекает правило не пихать в библиотеки глобальные переменные. Никаких чудес и "гласов свыше". Просто будет неудобно.
То же и с областью ввода-вывода. Она, будучи спрятанной в библиотеку, работать-то будет, но ни посмотреть ее толком, ни редактировать нельзя. Точнее, нужно лезть в библиотеку и там редактировать.
Значит, говорю я себе, будем все же выделять для библиотек те модули, которые работают только с локальными переменными (да со своими входными-выходными). И тут же замечаю, как безобразно раскидал по всем POU обращения к огромному пулу глобальных переменных. А ведь говорят-пишут опытные люди, что чем 'уже интерфейс программных модулей, тем надежнее и проще в отладке программа. Оказывается, тем проще и выбрасывать модули в библиотеку.
Вот пока и все, что я понял из экспериментов. Если все верно - и хорошо. Если выводы где-то ошибочны - буду благодарен за поправку. А пока начну выделять модули, действительно пригодные для канонической библиотеки.
Напоминаю, что у меня задача создания библиотеки не имеет ни какого отношения к использованию ее другими людьми. Это делается только для того, чтобы некая (желательно, значительная) часть программы была "зафиксирована". На базе одного проекта я сам буду создавать кучу вариантов - при одном и том же ПЛК, но с несколько разным поведением программы. Чем большая часть защищена от изменений, тем проще поддерживать единство такого "многовариантного" проекта.
Где-то так.
Ваши права
Ответить с цитированием