Спасибо. Я разобрался благодаря вашему видосу. Стало понятно.
Вид для печати
Это баг или фича:
Вложение 64836
Инкрементирую переменную. Но настроил выход блока неправильно. Получаю из-за этого ошибку. (показано красным)
Причина в элементе 70, но это совсем другой элемент. (показано зеленым)
Как так?
Это баг. Бывает.
Вложение 64837
Есть вопрос.
Каждый раз перед приёмом информации мне нужно очистить приемные буфера (.)(.)
Я использую шаги (CASE). На шаге 65 я использую функциональный блок MEM.MemFill. Потом ухожу на шаг 70. См. рисунок:
Вложение 64839
Этот блок не отрабатывается, потому что в первом квадрате MEM.MemFill постоянно включен выход MemFill, хотя разрешение EN уже отключено.
И во втором квадрате MEM.MemFill выход MemFill постоянно активен. Из-за этого квадрат move постоянно переключает bState в значение 70.
Разве отсутствие входного сигнала EN не должно блокировать все выходы в квадрате? Это было бы логичнее!
Разработчики стандарта МЭК 61131-3 считают иначе:
Вложение 64842
Вложение 64841
Т.е. для функций состояние выходов при EN = FALSE не специфицировано и определяется конкретной реализацией.
Для ФБ состояние выходов при EN = FALSE специфицировано - они сохраняют свои значения из предыдущего вызова.
Разработчики CODESYS выбрали для функций ту же реализацию обработки выходов при EN = FALSE, что и для ФБ - и это вполне закономерно.
Собственно, если вы ENO заведете на EN - то ваша проблема исчезнет сама собой.
Спасибо за разъяснения.
Как бы вы решили такую задачу? Как словить именно фронт выходного сигнала MemFill? Есть какие-либо "одновибраторы - фронтовики" ? :)
Триггер может какой?
Так:
Вложение 64868
Второй очищающий квадрат постоянно включен.
Получается он постоянно очищает второй буфер.
Честно говоря, не понял логики.
Что я делаю не так?
PS. Разобрался...
Евгений, а этот R-Trig он при фронте на входе дает единичный импульс на выходе? Так?
Именно так.Цитата:
Евгений, а этот R-Trig он при фронте на входе дает единичный импульс на выходе? Так?
Евгений, подскажите, правильно ли я вызываю метод? (основная прога называется main). См.рис.:
Вложение 64875
Это прием пакета через RS-232. Асинхронные прилеты пакетов заставляют контролировать целостность и склеивать иногда разорванные данные.
Поэтому реализован обычный метод, который реально вызывается 1 раз в 10 секунд (реально наблюдал) для склейки двух буферов.
Весь автомат заточен так, что bState приравнивается к 85 только когда пакет оказался разорванным. В остальных (99%) случаях этот шаг пропускается.
Правильно ли я понял, что метод не запускается сам по себе и не отнимает ресурс ПЛК.