А в чем? Инкапсуляция и наследование - это хорошо, но малоинтересно.
А в чем? Инкапсуляция и наследование - это хорошо, но малоинтересно.
Весь код я пока не готов написать, потому что некоторые идеи еще не продуманы до конца, я пока представляю скелет в терминах ООП, который наполняется функционалом по мере реализации идей. Да и мне не требуется, чтобы кто-то полностью за меня решил задачу. Я лишь хочу понять некоторые вещи.
Могу попробовать описать задачу еще раз, другими словами.
Есть автоматические ворота, у них есть несколько входов для управления: вкл/выкл, открыть, закрыть. Так же у них есть два выхода, сигнализирующих о достижении воротами конечных положений открыто и закрыто соответственно. Все это подключено к 5 портам ПЛК.
Соответственно нужно иметь возможность этими воротами управлять: включать/отключать, открывать, закрывать, обрабатывать сигналы о достижении конечных положений.
Цель не просто написать программу, которая будет связывать одно с другим по определенному алгоритму, а сделать это в виде самостоятельной сущности, черного ящика, отдельного блока. Чтобы при программировании сценариев управления воротами абстрагироваться от "внутренностей" и железа и предоставить "пользователю", готовый и полностью функциональный инструмент.
Как я понимаю в этом плане ФБ в первом приближении мне подходит.
На текущий момент не понятно следующее:
1. Есть ли у него что-то типа конструктора? Хочу инициализировать параметры. Можно ли как-то передавать при инициализации номера портов, с которыми он будет уже сам работать. Если такого нет, как это обычно делается? Могу ли я как-то обращаться к портам (или другому оборудованию) из ФБ?
2. ФБ потом вставляется в программу, которая "крутится" в рамках задачи с определенным временем цикла исполнения. И тут вот что не понятно. Есть, например, элемент F_TRIG, он действительно будет срабатывать по заднему фронту сигнала? Или это будет приурочено к следующему циклу программы? Или, например, таймер, установлен на 50 мс, а цикл задачи, в которой крутится программа с этим блоком, равен 200 мс, как это будет работать? В момент срабатывания таймера будет осуществляться переход к программе или это будет приурочено к следующему циклу программы?
3. Вопрос алгоритмического характера. На входе есть два параметра: isOpen и isClosed (сигналы конечных положений ворот), на выходе нужно получить два сигнала: Opening и Closing, которые true только во время открывания/закрывания ворот, в остальное время false. Как это сделать в виде FB? Мне удалось сделать схему, которая для каждого выхода использует по одному F_TRIG и R_TRIG, один AND и один SR, но мне кажется это слишком громоздко для такой простой вещи. По крайней мере с использованием ООП это делается гораздо проще.
пока все
Заранее спасибо.
Последний раз редактировалось turkish945; 28.04.2020 в 21:31.
Объясните, почему 200 мс не крутится? Если для задачи не требуется чаще, зачем крутиться чаще?
Так работать не будет, я забыл упомянуть, что управляющий сигнал на открытие/закрытие это короткий импульс, а не импульс на все время открывания/закрывания. И еще второе, сигнал на открытие может быть подан не через ПЛК, а, например, с пульта напрямую на блок управления воротами и мы об этом сможем узнать только косвенно по тому, что изменилось состояние концевика, соответственно управляющий сигнал на открытие в этих целям мы использовать не можем.
Ничего я не путаю. Как я говорил, я попытался это реализовать с помощью ФБ на CFC, получилось громоздко и я решил оформить отдельным ФБ, у которого это как раз входы, а выходы Opening и Closing.
В ООП можно сделать, чтобы свойство класса менялось через вызов функции set, в которой можно было бы установить Opening в нужное значение, а заодно еще кое что сделать. Например так: property isOpen: boolean read isOpen write Set_isOpen;
Извините, если мои вопросы кажутся глупыми, но ведь я только в самом начале. И не только спрашиваю тут, но и читаю материалы.
могу выложить FB (макрос для ПР200) управления роллетой через одну единственную кнопку (физическая кнопка открыть-стоп-закрыть) и управления из ПР200 по сети. Переделаете в CodeSys и добавите необходимое. Там как раз тоже использовались концевики роллеты для контроля. Из особенности, так как кнопка единственная и неизвестно положение роллеты (например человек руками открыл не полностью и потом остановил) а нам надо открыть, что делается только через эту единственную кнопку, то следующее действие будет на закрытие. Соответственно роллета сперва закроется, хотя по сети мы дали команду на открытие, и еще раз нажмет кнопку для открытия, так как команда была открыть. з.ы. работает на приводе Came уже долго, нареканий нет.
А так capzap правильно написал, FB и есть сущность, и FB можно размножать, под них выделяется память под каждый и это надо учитывать, чтобы переменные одного не пересекались с переменными другого (не лезть из кода FB в глобальные переменные например)
Насколько помню, R-Trig и F-Trig работают за два цикла программы. Можете код посмотреть (не помню. можете или нет код штатных FB посмотреть)...
Вопрос задал потому что мне это не понятно, может быть пример с таймером некорректный, я там еще и с F_TRIG привел аналогичный. Просто мне не понятно, работают ли эти вещи по своим событиям независимо от программы или все происходит в те временные интервалы, которые установлены для задачи. Я подозреваю, что работает все как надо, но пока в голове нет ясной картинки как это происходит.
По поводу длительности цикла, я думаю Вы согласитесь, что все зависит от задачи и нет такого, что в любом случае цикл должен быть максимально коротким. Хотя если привязываться к примеру с таймером, тут соглашусь. Но я уже сказал, что пример некорректный.
Или Вы что-то не понимаете или я.
Смотрите, есть ворота, со своим блоком управления, своим пультом, который ими управляет независимо ни от ПЛК ни от той сущности, о которой мы тут разговариваем. При этом мне важно знать в рамках этой моей сущности о том, что какая-то другая система/сущность отправила управляющий сигнал. Хотя и ворота могут управляться и другими способами, но она должна четко отражать их состояние независимо ни от чего. Это можно сделать только косвенно, по сигналам от концевиков. Поэтому в данном случае, во-первых, нельзя использовать управляющий сигнал, т.к. он не уникальный, а во-вторых, то выражение все равно не дает нужного результата, т.к. длительность управляющего импульса и длительность результирующего не совпадают.
Можно не выкладывать, я понял как это сделать, спасибо
Сильно не пинайте, давно делал, когда еще не было возможности подцепить концевики и человек по камере ориентировался, так что может в нем что-то лишнее. Ну и Putbit и Extractbit не помню как родились, кажется с подсказок на форуме, заменяют логику проверок.
Или вам самим макросом для ОЛ ?
Второй такой же макрос управляет воротами, там тоже привод Came и кнопка управления одна единственная.
Я сегодня пообщался с товарищем, он мне все объяснил. Я то думал, что тут аппаратный таймер (как это там, где я до этого имел опыт) и программа работает на его прерываниях, а оказывается нифига и все завязано на циклы задач, теперь многие вещи стали понятны.
Ну первое Вам не понравилось, объяснил по-другому, при этом выкинул один управляющий сигнал (ButtonEnabled), т.к. на суть вопроса он не влияет, чтобы не объяснять что это и зачем.
Есть ворота со своим блоком управления, это стандартная комплектация, обычно ограничиваются этим, открывают/закрывают с пульта или кнопки, которая напрямую к блоку управления подключается. При этом блок управления умеет принимать сигналы управления: вкл/выкл, открыть, закрыть и умеет отдавать сигналы с концевиков. Вот эти 5 каналов подключены к ПЛК и ими я хочу рулить в рамках этой сущности. А рулить ими я хочу в рамках системы умного дома.
В целом у меня вроде как сформировалось общее понимание как это все должно быть реализовано, пока вопросов больше не имею, буду пробовать, возможно что-то возникнет в процессе. Всем спасибо.
PS: насчет ООП в codesys, интерес я не потерял, все равно изучу вопрос, чтобы знать что там к чему