Просмотр полной версии : Сработка выхода как условие для программы, вопрос.
Как в овен логике можно проконтролировать и использовать работу выхода для дальнейшего исполнения алгоритма программы.
Допустим в допотопных реле от омрона это делается элементарно, но там все пишется на ладе, на экранчике калькулятора (если нет спец кабеля).
Например, при условии того что работает Q1 у меня никогда не должен включится Q2 и т д в различных реализациях, как это реализовать, извиняюсь если туплю?
Смотря что вы хотите написать.
Так то через банальный AND на одном из входов которого NOT заблокирует его выход.
Если условий больше и там и И и ИЛИ то лучше чем макрос boolean ничего не придумано. Аналог из ZelioLogic.
В принципе так и делаю сейчас, но это не совсем удобно, а точнее вообще не удобно. А что за макрос boolean и как его использовать? И вообще не понятно отсутствие такой возможности, проверки выхода, как условия, изначально.
Элементарный пример. В моем случае программа большая и просто тупо не хватает места для подобных проверок, состоящих из множества блоков, вместо простой проверки состояния выхода, в логике включения которого уже все условия описаны и нет смысла их переписывать каждый раз,нужно просто проверять, включен он на данный момент или нет.
79796
В принципе так и делаю сейчас, но это не совсем удобно, а точнее вообще не удобно. А что за макрос boolean и как его использовать? И вообще не понятно отсутствие такой возможности, проверки выхода, как условия, изначально.
Элементарный пример. В моем случае программа большая и просто тупо не хватает места для подобных проверок, состоящих из множества блоков, вместо простой проверки состояния выхода, в логике включения которого уже все условия описаны и нет смысла их переписывать каждый раз,нужно просто проверять, включен он на данный момент или нет.
79796
Непонятно в чём проблема:
79797
Непонятно в чём проблема:
79797
Проблемы будут потом, в удобстве чтения и по прошествию времени, когда сам уже не помнишь, как работает что, ну и так же в том что входов используется больше 10 и так же выходов.
Проблемы будут потом, в удобстве чтения и по прошествию времени, когда сам уже не помнишь, как работает что, ну и так же в том что входов используется больше 10 и так же выходов.
Называйте переменные адекватно, пишите комментарии - проблем не будет.
Сделайте промежуточные переменные:
79798
Называйте переменные адекватно, пишите комментарии - проблем не будет.
Сделайте промежуточные переменные:
79798
Ок, ну то есть в этом софте нет такой возможности без танцев с бубном и прочими макросами?
Ок, ну то есть в этом софте нет такой возможности без танцев с бубном и прочими макросами?
Какой "такой" - читать значение выхода? Так на скрине ровно ваш вариант.
Даже если бы была такая возможность - вы сегодня используете выход Q1, завтра реле Q1 выходит из строя и вы пересаживаете провода на выход Q2. Будете по всей программе искать где вы могли использовать Q1?
К названиям и номерам входов/выходов вообще не надо привязываться. Оперируйте названиями сигналов и исполнительных устройств:
79799
Предлагаю сменить стиль программирования - выходы логических функций записывать в переменные, а переменные привязывать к выходам.
Таким образом, блокировку одновременного включения двух выходов проводить в подпрограмме (в ФБ) с соответствующим названием и описанием.
Т.е. получится картина:
- группа ФБ обрабатывает алгоритм, результаты сохраняет в переменные
- эти переменные поступают на ФБ блокировок взаимных состояний выходов, выходы которых сохраняются в переменные
- именно эти переменные и подключаются к физическим выходам ПР
Ну, и комментарии - их никто не отменял.
Пока набирал, 1exan уже все объяснил :).
Мойку линии сразу на Q3 без лишней хрени.
Все проблемы решились в AND Q1
Да я логику и не разглядывал
Какой "такой" - читать значение выхода? Так на скрине ровно ваш вариант.
Даже если бы была такая возможность - вы сегодня используете выход Q1, завтра реле Q1 выходит из строя и вы пересаживаете провода на выход Q2. Будете по всей программе искать где вы могли использовать Q1?
К названиям и номерам входов/выходов вообще не надо привязываться. Оперируйте названиями сигналов и исполнительных устройств:
79799
Согласен, спасибо, но из за того что мозг не дает покоя, как на языке ST проверить состояние выхода?
Как проверить состояние выхода - никак. Это вам не ПЛК. Тут из логики программы системные переменные маски выходов вроде недоступны.
Тут вроде можно только состояние логики проверить, а уже потом привязывать к выходам.
Как проверить состояние выхода - никак
лехко
function_block Main
var_input
...
end_var
var_output
Q1,Q2,Q3,Q4,Q5,Q6,F1,F2: bool;
end_var
//кокой-то код, где и проверяем и что хотим воротим
end_function_block
Валенок вы говорите про блок FB, где вы обозвали выходы так же, как выходы ПР. Непосредственно выход ПР вы так проверить можете?
Человек спрашивает так понимаю об этом. Но этого тут НЕТ.
Валенок вы говорите про блок FB, где вы обозвали выходы так же, как выходы ПР. .
Да.
Непосредственно выход ПР вы так проверить можете?
Да. Потому что он именно таким и будет. Не каким-то другим. И приведеная табличка - ниочём.
С диагностикой фактического состояния (выход ёк) просьба не путать. Тут вопрос не про это.
Человек спрашивает так понимаю об этом..
О чем? Чтоб где-то не в коде прописать условие? Потому что ".. но там все пишется на ладе, на экранчике калькулятора" это якобы не код?
Валенок ну могу сказать, что в схемах АВР он таким не будет, точнее ему там вообще не место. Там правильный подход при организации программы как показал 1exan в посте #6. Так как блокировки выполняются не только в конечных точках, но еще и по участкам схем.
Человек спрашивал есть ли в ПР такое, как у других. Где Q1, Q2 и т.д. основной программы по умолчанию являются как выходными реле ПР так собственно и переменными для самой программы.
ПР, точнее ПО Овен Лождик в этом плане далек от идеала. Да у него и других граблей хватает. Одна только работа художником чего стоит...
Мне вот интересно пообщаться напрямую с разработчиком ОЛ. Не с менеджерами компании Овен, мне они не интересны.
Только подозреваю, что придется применять онлайн переводчик для общения. :)
In_Da_Cher_A
03.11.2024, 07:47
О чем? Чтоб где-то не в коде прописать условие? Потому что ".. но там все пишется на ладе, на экранчике калькулятора" это якобы не код?
да. Автор думает, что типа "умное" реле Омрона, якобы как-то помимо программы запрещает сработку другого выхода
и привыкнув в шаблонному кодингу, пытается найти это в другой железке
типа как стрелец эпохи Петра Первого взяв в руки винтовку, ищет куда насыпать порох и как забить пыж в дуло
о, адепты текущего ОЛ подтягиваются :)
Ребята, попользуйтесь другими продуктами, возьмите от них лучшие идеи. а не сидите на жопе ровно... (правда тут есть скрытый подвох - тогда ПР подорожает еще на треть и тем более перестанет быть кому-то нужен - палка о двух концах :) )
я вот сейчас купил ПЛК EKF, потому что он 1 - дешевле ПР200 (да фиг бы с этим экранчиком за простите тысяч 10 разницы) 2- умеет Modbus в FBD и LAD (да, не через конфигуратор, но то же фиг бы с ним, разберемся, главное это ГРУППОВЫЕ ЗАПРОСЫ в отличии от ПР Овен).
И вот тоже сижу и плююсь от архитектуры (можно привыкнуть) и от реализации некоторых вещей.
Но с математикой у него вроде тоже все хорошо, не сравнить с Zelio или с Logo!
На счет качества ничего не скажу, первый раз :)
Maкрос boolean + excel (https://disk.yandex.ru/d/7Sp9Z-WuhMUnmg) Спасибо AI! за его создание. Это аналог блока из ZelioLogic.
Позволяет управлять выходом по маскам разрешенных комбинаций входов. Позволяет не делать простыни из AND, OR, NOT и так далее.
!!!!! ОСТНОРОЖНО !!!!! при переносе блока из проекта в проект (не помню при копировании внутри) переменная настройки сбрасывается на по умолчанию.
о, адепты текущего ОЛ подтягиваются :)
Ребята, попользуйтесь другими продуктами, возьмите от них лучшие идеи. а не сидите на жопе ровно... (правда тут есть скрытый подвох - тогда ПР подорожает еще на треть и тем более перестанет быть кому-то нужен - палка о двух концах :) )
я вот сейчас купил ПЛК EKF, потому что он 1 - дешевле ПР200 (да фиг бы с этим экранчиком за простите тысяч 10 разницы) 2- умеет Modbus в FBD и LAD (да, не через конфигуратор, но то же фиг бы с ним, разберемся, главное это ГРУППОВЫЕ ЗАПРОСЫ в отличии от ПР Овен).
И вот тоже сижу и плююсь от архитектуры (можно привыкнуть) и от реализации некоторых вещей.
Но с математикой у него вроде тоже все хорошо, не сравнить с Zelio или с Logo!
На счет качества ничего не скажу, первый раз :)
Из этого EKF выглядывают узкие глаза Haiwell.
Может групповые запросы там и есть - что при наличии приличного количества вариантов модулей на внутренней шине уже не так важно, но среда разработки и её "удобство" прямо сильно напрягают.
Может в качестве аналога ПР и нормально будет, но как ПЛК - ну нафиг
1exan да, в качестве ПЛК он тяжел из-за среды разработки. Ну разве что для мастодонтов Siemens, Allen Bradlay пойдет. Кто привык сложные программы на LAD и IL писать.
Я только голову планирую использовать, а модули для сбора положений автоматов.
In_Da_Cher_A
03.11.2024, 12:34
о, адепты текущего ОЛ подтягиваются :)
Ребята, попользуйтесь другими продуктами, возьмите от них лучшие идеи. а не сидите на жопе ровно... (правда тут есть скрытый подвох - тогда ПР подорожает еще на треть и тем более перестанет быть кому-то нужен - палка о двух концах :) )ну вот не надо, я один раз поработал с ПР100 пару лет назад и глядя на страдания на форуме, больше иметь дела с ПР и Лоджиком - не хочу и не буду, я баг-тестером не устраивался работать в ОВЕН
просто наезжать на ОВЕН и на продукт, только из-за того, что ты не можешь нормально написать программу, так, чтобы у тебя не проходило одновременно команда Закрыть/Откл и Открыть/Вкл на контакторы привода или выключателя, и ты тупо ищешь страховку от двух противоположных команд - ну так собирай тогда на реле защитнвую блокировку, если ты в душе электрик, а не программист
In_Da_Cher_A Ну на Овен наезжаю по другому поводу больше. Когда объявили о выходе версии 2 ОЛ, я размечтался, что они наконец уйдут от графического стола программы к координатному. А что они сделали? они спрятали с глаз графический, накрутили поверх свой json, который у них постоянно вываливает простынки ошибок сериализации и просто все пихнули в zip. М-А-Л-А-Д-Ц-Ы!
При этом сделали так, что даже если в новых версиях ничего не менялось скажем по отношению к ПР200, я один фиг вынужден скачивать новые и новые версии. Ну вот НА КОЙ?
Ну если ПР200 не менялась в 10-ти версиях подряд ОЛ и человек в версии образно 2.3.10 сделал что-то для ПР200, почему я не могу открыть это программой версии 2.3.0 ?
Как-то энтузазизм пропал, теперь в проекты Овен даже не закладываю, должно чудо произойти, что вот там лучше будет какой-то ПР применить...
Валенок ну могу сказать, что в схемах АВР он таким не будет, точнее ему там вообще не место. Там правильный подход при организации программы как показал 1exan в посте #6. Так как блокировки выполняются не только в конечных точках, но еще и по участкам схем.
Человек спрашивал есть ли в ПР такое, как у других. Где Q1, Q2 и т.д. основной программы по умолчанию являются как выходными реле ПР так собственно и переменными для самой программы.
ПР, точнее ПО Овен Лождик в этом плане далек от идеала. Да у него и других граблей хватает. Одна только работа художником чего стоит...
Мне вот интересно пообщаться напрямую с разработчиком ОЛ. Не с менеджерами компании Овен, мне они не интересны.
Только подозреваю, что придется применять онлайн переводчик для общения. :)
Да именно об этом и была речь, уже понял что этого функционала здесь нет.
melky, при смене платформы довольно критична возможность использования старых наработок - перенабирать все затратно и осложняется различиями аппаратных ограничений платформ (по измерению времени цикла, "обратным связям", "запись в конце цикла", импорт-экспорт переменных и прочим штучкам).
Даже переход с ПР200 на ПР205 вызывает массу вопросов неалгоритмического характера...
Честно, пока не прижало - у меня нет желания бросить "нажитое" и уйти обживать "чужой дом".
Не имею по вопросу выбора платформы другой позиции, кроме "жалко наработки".
Если не затруднит, поделитесь мнением.
По правде, не уяснил для себя критичных преимуществ "условного EKF" перед ПР.
Всякие неоправданные обновления сойдут за неприятные особенности. Цена - платит заказчик и стоимость ПР исчезает среди стоимости остального оборудования, в том числе монтажных работ. Формат внутреннего хранения проекта волнует меня меньше всего, только в контексте постепенного медленного отхода от Windows к Linux.
Нет ли ощущения того, что "условный EKF" не имея русскоговорящего форума с постоянными вопросами об одном и том же от разных рвачей от автоматизации, создаёт иллюзию более подготовленной аудитории?
Вы упомянули только групповые запросы - насколько они именно критичны?
Вы упомянули, что перешли на другие ПР, какие преимущества ощутили?
In_Da_Cher_A
03.11.2024, 15:11
In_Da_Cher_A Ну на Овен наезжаю по другому поводу больше. .....ну это понятно, ребята пытаются сделать свою "экосистему" но что-то выходит на троечку, из-за неудачного софтового решения страдает нормальный в общем-то прибор
я не могу позволить себе тратиться на другое железо без понимания стабильного качества железа и такого же понимания, что через условных пару лет, железка не исчезнет, потому что кучка менегеров прекратила её завозить из китая
поэтому готовлюсь мигрировать на плк2хх
поделитесь мнением.меня не спрашивали конечно , но в продолжении разговора о какой-то миграции и куда
-читая на сайте ЕКФ в описании модуля вот такую срань, рождённую в мозгу менеджера
Устройства, предназначенные для выполнения логических операций по заданной программе. Способны решать задачи любого уровня сложности. Используются для повышения энергоэффективности, безопасности и цифровизации предприятий всех сфер деятельности
и глядя на самую важную, по мнению менегера, для меня информацию, которая стоит в первых самых первых строчках описания железки
Есть штрихкод на каждой штуке товара - Дая понимаю - ЕКФ это не про автоматизацию, это про бабло
если они смогут вытащить это направление в нормальный бизнес по автоматизации, буду рад.
Но пока это выглядит в общем и в дальнем горизонте 3-5 лет - не очень перспективно, несмотря на декларируемые, интересные "заготовки", которых у ОВЕНа нет.
поэтому как бы не было грустно, но придётся и дальше работать с ОВЕНом
Ну, по EKF F100, F200 могу так сказать.
Не софтовое решение как CodeSys, но выберу CodeSys для большого проекта.
Писать все и вся на LAD, FBD, IL это надо в этом постоянно работать и давно.
По мне это больше замена ПР от Овен.
Математика там как у ПЛК.
А вот ПР других производителей по математике слабы. Да и не для серьезных задач в принципе. Для АВР в щитах нормально, ну и подобных задач.
Например Carel попадался, PCo3 ну это для вентиляции. Например для автоматизации дома никудышный.
Ещё у EKF компактность. Я правда не его когда-то планировал на замену Allen Bradlay, рассматривал Овен в том числе. Но оказалось, чтобы поставить Овен, пришлось бы ещё и корпуса щитов на установках менять.
В общем в разных задачах, разные подходы а выбору.
Для электрических щитов сейчас EKF рассматриваю. Тем более большую часть программировать будут щитовики, так что самому как-то пофигу.
Больше всего убивает Софт от Овен. Через Ж. писанный.
ну это понятно, ребята пытаются сделать свою "экосистему"
Ну, по EKF F100, F200 могу так сказать.
Спасибо, коллеги
Сергей0308
03.11.2024, 15:55
Да именно об этом и была речь, уже понял что этого функционала здесь нет.
Может чего не понимаю, но мне это кажется полным бредом сивой кобылы, в смысле, ничто не мешает создать(добавить) промежуточную переменную и использовать её в программе, где захочется!
Сергей0308 выход ПР или ПЛК это и есть переменная. Как во многих других средах. Но тут надо создать дополнительную.
з.ы. ну импортозамещение у человека идет, понятно же :)
а ведь никто не мешает добавить в Системные. Причем и маской, раз появился ST и отдельными для FBD варианта.
То же и со входами. Но там только часы :)
Сергей0308
03.11.2024, 17:39
Сергей0308 выход ПР или ПЛК это и есть переменная. Как во многих других средах. Но тут надо создать дополнительную.
з.ы. ну импортозамещение у человека идет, понятно же :)
а ведь никто не мешает добавить в Системные. Причем и маской, раз появился ST и отдельными для FBD варианта.
То же и со входами. Но там только часы :)
Мне кажется это особенности языка программирования!
Тут уж извините, в смысле в каждом языке свои нюансы.
Что было в LD - забудьте, в смысле, в FBD это будет по другому!
Мне кажется это особенности языка программирования!
Тут уж извините, в смысле в каждом языке свои нюансы.
Что было в LD - забудьте, в смысле, в FBD это будет по другому!
В Омроновском ZEN не LD, а полный аналог обычной релейной схемы, там даже "обгон" есть, ситуация когда две релюхи с взаимной блокировкой одновременно включить пытаются.
Сергей0308
03.11.2024, 19:13
В Омроновском ZEN не LD, а полный аналог обычной релейной схемы, там даже "обгон" есть, ситуация когда две релюхи с взаимной блокировкой одновременно включить пытаются.
Хорошо, там не LD, если товарищ ранее в этой среде программировал, что это меняет, вся проблема в чём, мне кажется - нет никакой проблемы, добавил переменную и используй где хочешь, весь разговор выеденного яйца не стоит, мне так кажется!
[.. а ведь никто не мешает добавить в Системные. Причем и маской, раз появился ST..
Ну и что - усе пропало? ОЧЕВИДНОСТЬ и до меня сказана, и мной показана, и после меня повторили. Сделали оболочку поверх рученьками и усе есть, и маски и что хошь. Или тут пряма таки сразу с ложечки надо? В чем суть вопроса? В ложечке?
Валенок не в ложечке, а понять нюансы архитектуры. Меня вот тех поддержка вежливо послала учиться. :)
Например в ПР можно поставить счетчики CTU (со сбросом на нужном значении) каскадом и будут работать.
Делаю то же самое по сути в EKF - последующий счетчик даже не пытается начинать счет. - Фокус, сброс счетчика происходит в теле цикла, до следующего FBD сигнал даже не доходит.
В справке по этому поводу буй. И так вот то там, то сям.
Мне так кажется, что производители к справке должны прикладывать еще методичку с подобными вещами, учитывая опыт других сред.
Людям легче будет переходить.
... апример в ПР можно поставить счетчики CTU (со сбросом на нужном значении) каскадом и будут работать.
Делаю то же самое по сути в EKF - последующий счетчик даже не пытается начинать счет. - Фокус, сброс счетчика происходит в теле цикла, до следующего FBD сигнал даже не доходит.. В справке по этому поводу буй...
Ну и? я как то обплевался на таймеры ton/tof в степе, ну не пошел же в форум ним жалится. Ну не возможно ВСЕ предусмотреть в справках.
Валенок, так это и относится к нюансам архитектуры и среды разработки.
Даже если человек первый раз берется за программирование.
Ну например если внимательно читать документацию на тот же Siemens условно. То там все это есть. А тут как бы сухая справка, пойди догадайся как правильно, и возможно ли вообще.
Я кажется понял, в чем причина не работоспособности CTU. Проверю во вторник.
И что там в результате - рандом?
Если память не изменяет, то хуже, рандом приводит к дребезгу.
з.ы. проверил дома. В общем как во всех ПЛК, set - reset - set - reset можно в любых частях программы писать, и влияет роль порядок исполнения. В общем не как в ПР.
Если память не изменяет, то хуже, рандом приводит к дребезгу.
Т.е. в Омроновском ZEN при такой логической схеме-программе дребезг?
з.ы. проверил дома. В общем как во всех ПЛК, set - reset - set - reset можно в любых частях программы писать, и влияет роль порядок исполнения. В общем не как в ПР.
Что значит не как в ПР?
Валенок, в ПР нельзя писать в одну переменную в разных местах программы.
Сброс счётчика можно выполнять прямо на нем, сброс будет только на следующем цикле, все блоки после счётчика получат сигнал.
Хорошо, там не LD, если товарищ ранее в этой среде программировал, что это меняет, вся проблема в чём, мне кажется - нет никакой проблемы, добавил переменную и используй где хочешь, весь разговор выеденного яйца не стоит, мне так кажется!
Вообше нет проблем, всё везде одинаково, везде одни принципы, с принципов Мицубиши влёгкую пересеть на Сименс, а потом на Кодесис, (или другая комбинация начала и продолжения)
Если в этои списке ПР или ZEN появится, то вообще всё пофиг, никаких проблем, всё как в....???
Валенок, в ПР нельзя писать в одну переменную в разных местах программы..
Давайте будем точнее - в квадратиковом поле ПР это нельзя т.к. (видимо) мешает самой идеологии квадратиков
Но в ПР есть ST
Сергей0308
03.11.2024, 23:13
Давайте, пожалуйста, без фантазий, в смысле, я макросы создавал и на форуме выкладывал чтобы писать в переменную из двух и более мест.
Даже, если не ошибаюсь, в менеджере компонентов такие есть!
79815
писать в переменную из двух и более мест.
Сергей, не "из двух и более", а в двух и более" местах низя
Сергей0308
03.11.2024, 23:23
Сергей, не "из двух и более", а в двух и более" местах низя
Объясните разницу, что-то не могу её понять!
Сергей0308
03.11.2024, 23:57
Хорошо что Вы не на юриста учились. Не сдали бы))
---
из одной или разных емкостей в один пустой стакан налить можно 1 раз
Мне понятно, что разница в предлоге, остальное словоблудие! В смысле, разницы в действиях я не вижу!
Т.е. в Омроновском ZEN при такой логической схеме-программе дребезг?
Если память не изменяет. Проверить не могу.
............полный аналог обычной релейной схемы, там даже "обгон" есть, ситуация когда две релюхи с взаимной блокировкой одновременно включить пытаются.
Запомнилось, наверно потому что сам этого не ожидал.
Сергей0308 разница просто в том, что есть зверушки ромиро пр, ну хотя бы плк200. Далеко то ходить на надо.
Сергей0308
04.11.2024, 04:47
..............
Х это переменная?
Ей непосредственно присваивается два значения?
Так у вас получился квантовый компьютер, кстати к слову, наши недавно состряпали подобный на 50 кубит: https://www.youtube.com/watch?v=zWmF_jLahAc&t=210s
Типа состояния суперпозиции, в смысле, кубит может находится во всех состояниях(0 и 1) одновременно, здесь ничего необычного нет!
https://habr.com/ru/companies/droider/articles/531708/
Нет, Х присваивается по одному значению в процессе работы программы. В конце цикла будет последнее записанное значение. Например если это булевый выход, где-то его включили, потом по какому-то условию можно выключить. Если условие не выполнено, значит останется включенным (то, что его где-то включило).
Сергей0308
04.11.2024, 13:17
Нет, Х присваивается по одному значению в процессе работы программы. В конце цикла будет последнее записанное значение. Например если это булевый выход, где-то его включили, потом по какому-то условию можно выключить. Если условие не выполнено, значит останется включенным (то, что его где-то включило).
Так Вы сказочники, в смысле, в ОЛ так не может быть, в смысле, за один цикл программы не может быть переменной присвоено несколько значений, только одно, не может переменная несколько раз менять значение в течении одного цикла! Собственно цикл это минимальный шаг программы, если так можно выразится.
Так Вы сказочники, в смысле, в ОЛ так не может быть, в смысле, за один цикл программы не может быть переменной присвоено несколько значений, только одно, не может переменная несколько раз менять значение в течении одного цикла! Собственно цикл это минимальный шаг программы, если так можно выразится.
Ну, почему же?..
На ST в OwenLogic возможна же конструкция
A := B+C;
A := A+D;
И LD, как текстовый по содержания, хоть и графический по отображению, позволяет подобные вещи.
Единственно, в разных реализациях встречал варианты:
1) второе присвоение невозможно
2) последнее присвоение и определяет значение переменной по окончанию цикла программы пользователя
3) добавлена специальная катушка OROUT, которая при повторном присвоении той же переменной, по сути выполняет логическое сложение с предыдущим присвоением A := A OR CONDITION
В том и фокус, что это невозможно в FBD ОЛ, но это возможно в FBD того же EKF или CFC в CodeSys. А малюешь что-то по привычке, или берешь пример из ОЛ, а тут бац... :)
И уже как-то писал, есть ПЛК, в теле цикла программы которого, можно даже выход включить
Королев Кирилл
05.11.2024, 10:00
Коллеги, если изначальный вопрос еще актуален, то возможность следить за состоянием выходов напрямую есть у ПР103/205 (как выйдет, будет у ПР225)):
79837
Для ПР200/102/100 такой функционал вряд ли будет поддержан.
Powered by vBulletin® Version 4.2.3 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot