Это баг или фича:
баг фича.png
Инкрементирую переменную. Но настроил выход блока неправильно. Получаю из-за этого ошибку. (показано красным)
Причина в элементе 70, но это совсем другой элемент. (показано зеленым)
Как так?
Это баг. Бывает.
16719041905990.jpg
Связь со мной: telegram: @JuneSmellsLikeBlood | e-mail: e.kislov@owen.ru (личка на форуме - не подходит)
Раздел CDS V3.5 на сайте | Основные темы по CDS V3.5 на форуме: Вопросы и ответы | Визуализация | Настройка обмена с другими устройствами
Repository Archive V3.5 SP4 (необходим для СПК207/СПК1хх без Eth/ПЛК3xx)
oscat.ru | Как обратиться в техподдержку? | Как отлаживать ошибки | Отладка проектов в CODESYS V3.5 | Проблема XY | Как правильно задавать вопросы | AnyDesk
Есть вопрос.
Каждый раз перед приёмом информации мне нужно очистить приемные буфера (.)(.)
Я использую шаги (CASE). На шаге 65 я использую функциональный блок MEM.MemFill. Потом ухожу на шаг 70. См. рисунок:
Л - логика.png
Этот блок не отрабатывается, потому что в первом квадрате MEM.MemFill постоянно включен выход MemFill, хотя разрешение EN уже отключено.
И во втором квадрате MEM.MemFill выход MemFill постоянно активен. Из-за этого квадрат move постоянно переключает bState в значение 70.
Разве отсутствие входного сигнала EN не должно блокировать все выходы в квадрате? Это было бы логичнее!
Последний раз редактировалось ВладОвен; 26.12.2022 в 18:40.
Разработчики стандарта МЭК 61131-3 считают иначе:
26-12-2022 18-52-09.png
26-12-2022 18-49-34.png
Т.е. для функций состояние выходов при EN = FALSE не специфицировано и определяется конкретной реализацией.
Для ФБ состояние выходов при EN = FALSE специфицировано - они сохраняют свои значения из предыдущего вызова.
Разработчики CODESYS выбрали для функций ту же реализацию обработки выходов при EN = FALSE, что и для ФБ - и это вполне закономерно.
Собственно, если вы ENO заведете на EN - то ваша проблема исчезнет сама собой.
Последний раз редактировалось Евгений Кислов; 26.12.2022 в 18:56.
Связь со мной: telegram: @JuneSmellsLikeBlood | e-mail: e.kislov@owen.ru (личка на форуме - не подходит)
Раздел CDS V3.5 на сайте | Основные темы по CDS V3.5 на форуме: Вопросы и ответы | Визуализация | Настройка обмена с другими устройствами
Repository Archive V3.5 SP4 (необходим для СПК207/СПК1хх без Eth/ПЛК3xx)
oscat.ru | Как обратиться в техподдержку? | Как отлаживать ошибки | Отладка проектов в CODESYS V3.5 | Проблема XY | Как правильно задавать вопросы | AnyDesk
Спасибо за разъяснения.
Как бы вы решили такую задачу? Как словить именно фронт выходного сигнала MemFill? Есть какие-либо "одновибраторы - фронтовики" ?
Триггер может какой?
Связь со мной: telegram: @JuneSmellsLikeBlood | e-mail: e.kislov@owen.ru (личка на форуме - не подходит)
Раздел CDS V3.5 на сайте | Основные темы по CDS V3.5 на форуме: Вопросы и ответы | Визуализация | Настройка обмена с другими устройствами
Repository Archive V3.5 SP4 (необходим для СПК207/СПК1хх без Eth/ПЛК3xx)
oscat.ru | Как обратиться в техподдержку? | Как отлаживать ошибки | Отладка проектов в CODESYS V3.5 | Проблема XY | Как правильно задавать вопросы | AnyDesk
Так:
rtrig.png
Второй очищающий квадрат постоянно включен.
Получается он постоянно очищает второй буфер.
Честно говоря, не понял логики.
Что я делаю не так?
PS. Разобрался...
Евгений, а этот R-Trig он при фронте на входе дает единичный импульс на выходе? Так?
Последний раз редактировалось ВладОвен; 27.12.2022 в 10:52.
Именно так.Евгений, а этот R-Trig он при фронте на входе дает единичный импульс на выходе? Так?
Связь со мной: telegram: @JuneSmellsLikeBlood | e-mail: e.kislov@owen.ru (личка на форуме - не подходит)
Раздел CDS V3.5 на сайте | Основные темы по CDS V3.5 на форуме: Вопросы и ответы | Визуализация | Настройка обмена с другими устройствами
Repository Archive V3.5 SP4 (необходим для СПК207/СПК1хх без Eth/ПЛК3xx)
oscat.ru | Как обратиться в техподдержку? | Как отлаживать ошибки | Отладка проектов в CODESYS V3.5 | Проблема XY | Как правильно задавать вопросы | AnyDesk
Евгений, подскажите, правильно ли я вызываю метод? (основная прога называется main). См.рис.:
method.png
Это прием пакета через RS-232. Асинхронные прилеты пакетов заставляют контролировать целостность и склеивать иногда разорванные данные.
Поэтому реализован обычный метод, который реально вызывается 1 раз в 10 секунд (реально наблюдал) для склейки двух буферов.
Весь автомат заточен так, что bState приравнивается к 85 только когда пакет оказался разорванным. В остальных (99%) случаях этот шаг пропускается.
Правильно ли я понял, что метод не запускается сам по себе и не отнимает ресурс ПЛК.