Да, уж, картина Репина! Как говорится: всё правильно, только наоборот!Сообщение от K123
Как раз от одного TON изменится продолжительность нахождения в том или ином состоянии(это может быть не принципиально, но факт), лучше тогда сделать симметричный фильтр с одинаковой задержкой на включение-выключение, тогда этого не случится(за что Вы так радеете), можно примерно как-то так:
Фильтр.PNG
Фильтр.owl
Вы поставте такой фильтр и счётчик на каждый вход(что у Вас запараллелены) и посмотрите, значения счётчиков должны совпадать, а то детский сад какой-то, даже не детский сад, а ясли, так точнее будет!
И вообще, если логика может некорректно работать от фильтров, то и не ставьте эти фильтры на вашу логику, пусть они(фильтры) только для счётчиков будут, как на картинке!
И я ещё несколько лет тому назад предлагал помехозащищённую фильтрацию, где даже 2-а десятка ошибок подряд не приведут к ложному срабатыванию, разумеется короткие сигналы он будет игнорировать:
Фильтрация_9.PNG
Фильтрация_9.owl
Принцип работы этого фильтра таков: каждый цикл программы запоминается состояние дискретного входа("0" или "1") и суммируются состояния входа за последние 32 цикла работы программы ПР. Если значение превышает "24"(75% от максимального), то включается триггер на выходе фильтра и принимается что вход имеет состояние "1". Если значение менее "8"(25%), то выключается триггер на выходе фильтра и принимается что вход имеет состояние "0".
Сейчас бы сделал всё по другому, примерно как-то так:
Фильтрация_10.PNG
Фильтрация_10.owl
Даже так:
Фильтрация_11.PNG
Фильтрация_11.owl
И есть дальнейшие перспективы совершенствования, в плане упрощения сумматора бит!
Ответить с цитированием