Сергей0308 а можно ваш вариант тоже в виде программы а не фотографий
Сергей0308 а можно ваш вариант тоже в виде программы а не фотографий
Если Вы имеете ввиду оптимизированный, то пожалуйста:
Регистрация аварий.owl
Последний раз редактировалось Сергей0308; 07.05.2019 в 22:08.
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
Естественно оптимизированный, спасибо!
Вот ещё возможный вариант, сигнал(ы) аварии можно всегда сбросить, несмотря на присутствие на входах и отслеживать только вновь поступающие аварии, пока сигнал на входе не передёрнется(выключится-включится):
Регистрация аварий_2.PNG
Регистрация аварий_2.owl
Вот ещё, модернизированный вариант:
Регистрация аварий_5.PNG
Регистрация аварий_5.owl
Теперь обработка изменения может быть быстрей до 8 раз!
Можно очень-очень легко расширить до 32 аварий!
Последний раз редактировалось Сергей0308; 10.05.2019 в 14:54.
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
Сергей0308! спасибо за большое количество вариантов, но вот "магию" отображения только активных аварий подряд на экране я так и не понял. можете на пальцах объяснить, зачем нужно последовательно прибавлять все аварии ALx в Yx. я не нашел, куда эти Yx задействованы в проекте. нашел... они координатах Y аварий задействованы? О! теперь понятно, как происходит сортировка аварий на экранах! для каждого текущего набора аварий вычисляется текущая координата по Y!!! Это же прям огонь!
с переходами тоже понятно. я просто не думал, что можно одновременно организовывать переходы с экранов и по переменной и по сочетанию кнопок.
блин.. да у меня вообще одни сплошные вопросы... тааак... начинает картина проясняться! но пока ничего не понимаю по поводу использования ramp_bit блока.... не вкуриваю в его суть...
Еще не понял прикола с переменной сброса как вообще работает инструкция R-TP-R? я понял, что она сбрасывает переменную. но не понимаю логического механизма!
ну и последняя непонятка, как масштабировать ваш вариант контроля аварий и можно ли из него как-то создать универсальный макрос на большее количество аварий?
По поводу макроса RAMP_BIT и RAMP_BIT_M - это я свой вариант предложил с возможностью всегда сбросить аварии и отслеживать только вновь поступающие, когда сигнал аварии передёрнется(выключится и вновь включится), можно конечно сделать и на детекторах переднего фронта и RS-триггерах, подобно, как Юрий Ревака делал, но мне кажется мой вариант проще(может и ошибаюсь, исследования не проводил по этому вопросу) и количество аварии можно легко расширить до 32, включительно, заменив макросы записи-чтения бита с 8 входами-выходами на 32, есть в этом проекте: Аварии, тест.owl, ну и соответственно сортировку аварий дополнить придётся до нужного количества аварий, всё!
Я ещё где-то предлагал вариант, сделать отображение аварий в виде бегущей строки, по очереди, последовательно все активные аварии будут проплывать, а то со строками не очень удобно в том плане, что для просмотра всех аварий их надо листать! С бегущей строкой там не сложней выйдет, чем со строками, только желательно уложится в 128 знаков(говорят столько максимально для строки), чтобы 2 строки не склеивать.
Последний раз редактировалось Сергей0308; 11.05.2019 в 16:53.
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
Сергей0308 я понял, какую цель преследует ваш вариант, я просто просил в двух словах объяснить смысл макроса рамп_бит в данном применении, а то я что-то туплю, если это конечно возможно.
В данном случае я написал для каких целей они используется(там 2 разных макроса)! А вообще макрос RAMP_BIT ограничивает количество изменяемых бит во времени, например если во входной переменной изменилось допустим 5 бит, то в выходной будет меняться по 1 биту за цикл, начиная со старшего и дальше по уменьшению старшинства(номера бита, весового коэффициента). В макросе RAMP_BIT_M при каждом изменении входной переменной в выходной меняется только один старший бит и имеются в обеих макросах отдельные входы разрешения работы на увеличение и уменьшение, что добавляет дополнительных функций, например в данном случае, в макросе RAMP_BIT_M, я задал только работу на увеличение и макрос запоминает кратковременные поступившие сигналы аварий, подобно RS(SR)-триггеру, всё!
И коль пошла такая пьянка, режь последний огурец, вот сортировку строк сделал в порядке поступления аварий: Регистрация аварий_6.owl
Регистрация аварий_6.PNG
Ну и первая сработавшая авария показывается, точнее её номер(0-31), если несколько аварий сработало и первая сработавшая пропадает, то индицируется вторая сработавшая и т. д. кроме того в строках аварии пишутся в порядке поступления, короче посмотрите, если кому такое надо, ну и если что не так, скажите, не таите в себе!
И макрос рассчитан на 32 аварии, в проекте есть всё необходимое для этого! И правильно на вход макроса Очередь подать переменную Q2, я в проекте специально Q1 подал для демонстрации в симуляторе возможностей(работы) макроса.
Ещё вариант: Регистрация аварий_7.owl
Регистрация аварий_7.PNG
Последний раз редактировалось Сергей0308; 13.05.2019 в 18:45.
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
Всё это костыли. А как вернуться на тот экран, где были до перехода на экран аварий? Да никак. Нужен экран аварий реализованный производителем.
stesel на каком были никак но на любой выбранный так же программно.