С условием по выходу триггера проще делать без таймера:Теперь осталось понять, как правильно вызывать таймер по IF...Код:VAR timeout: TIME; output: BOOL; END_VAR IF что-нибудь THEN timeout := TIME() + T#5s; END_IF output := TIME() >= timeout;
С условием по выходу триггера проще делать без таймера:Теперь осталось понять, как правильно вызывать таймер по IF...Код:VAR timeout: TIME; output: BOOL; END_VAR IF что-нибудь THEN timeout := TIME() + T#5s; END_IF output := TIME() >= timeout;
А у нас TIME() меньше 0 при старте ?
То что изображено - это NOT TOF.Q
К первому циклу уже больше, если не ошибаюсь.А у нас TIME() меньше 0 при старте ?В данном случае немного иначе: «если „что-нибудь“ TRUE, то на следующие 5 секунд output сделать FALSE, в остальное время держать TRUE»."Если 'что-нибуть' TRUE, то через 5 сек. output будет TRUE"... Так?
Таймер в таких ситуациях задалбывает требованием его вызывать. Если б хоть можно было писать timer(IN := ..., NOT Q => output) — ан нет, хрен тебе (при том, что в диаграммах отрицание ставится на любой вход или выход). В итоге лишние строки. Конечно, когда условие включения таймера держится, то лучше использовать нормальные TON, TOF и т.п.
Последний раз редактировалось Yegor; 18.09.2012 в 05:15.
Я знал! Я знал!
notq.png
В Стандарте есть эта фишка! Кодесис в очередной раз подтверждает своё весьма условное соответствие. Причём третья версия тоже это не поддерживает.
А ничего, что при постоянном что-нибудь=TRUE output будет иногда подниматься ?Код:VAR timeout: TIME; output: BOOL; END_VAR IF что-нибудь THEN timeout := TIME() + T#5s; END_IF output := TIME() >= timeout;
При «постоянном что-нибудь=TRUE» output будет постоянно FALSE. Ну и вообще я не просто так ограничил применимость этого решения:С условием по выходу триггера
Авторы Arian-5 тоже так предполагали
Т.е. этот код зависит не только от "что-нибудь" ?
В 1996 году отличились французы. Из-за ошибок в программном обеспечении 4 июня был прерван полет космической ракеты Ariane 5. Убытки в результате составили более 500 миллионов долларов. А причина крылась в том, что по недосмотру переменная, которая описывала горизонтальную скорость ракеты, была представлена целым 16-битным числом. В результате, как только эта значение переменной превысило 32 768 (2 в 15-й степени), система управления ракетой, что называется, “подвисла”, а “сошедшую с ума” ракету пришлось уничтожить.уже в 90-х годах. На этот раз пострадали бравые американские военные ракетчики, принимавшие участие в операции “Буря в пустыне”. К их удивлению, ракеты “Пэтриот”, использовавшиеся для перехвата в воздухе иракских ракет, периодически проходили мимо цели. Разбирательства начались после того, как пропущенная иракская ракета привела к гибели 28 американских солдат. Первоначально зародилось подозрение, что часть “Пэтриотов” технически неисправны. Однако созданная по этому поводу комиссия с удивлением обнаружила, что все обследованные ракеты абсолютно работоспособны. Вы уже, наверное, догадались, где пряталась ошибка? Конечно же, в программном обеспечении, использовавшимся американским зенитно-ракетным комплексом. Выяснилось, что система создавалась в расчете на то, что время ее непрерывной работы не будет превышать 14 часов, однако на практике комплексы непрерывно работали по 100 и более часов.Вроде бы пустяк, но оказалось, что используемое для определения времени программное обеспечение накапливало ошибки. За 100 часов работы набегала разница в 0,34 секунды. Программисты, оказывается, знали об этом, да посчитали факт несущественным...
Последний раз редактировалось Валенок; 18.09.2012 в 15:00.
Да хоть и триггером - те же проблемы. И тогда же :При «постоянном что-нибудь=TRUE» output будет постоянно FALSE. Ну и вообще я не просто так ограничил применимость этого решения ..c условием по выходу триггера
Бывает такая нездоровая фигня как стабильное питание и безаварийная работа. Ну мы ж сразу закладываем броски и ПНР бесконечно-периодический...ввиду, когда пройдет 49 с хвостиком суток от включения плк