Без понятия. У меня в Google Chrome работает.Сообщение от Сергей0308
Я говорю про этот пост:
Без понятия. У меня в Google Chrome работает.
Я говорю про этот пост:
pop70 - по буквам, если на вход С Д-триггера пришел сигнал РАНЬШЕ, чем на вход Д, состояние его поменяться не должно. То есть на входе Д уже должна быть единица, чтобы фронт сигнала на С передал ее на выход. то есть работать должен ТОЛЬКО момент фронта сигнала...
Один Д триггер работает правильно, ну он один и есть. а два уже нет. Так как заявления разработчиков о том, что все элементы выполняются последовательно согласно расстановке на схеме не соответствуют действительности Оба Д триггера определяют фронт одновременно, но у второго триггера по отношению к первому должна быть задержка сигнала на входе Д, так как сперва должен отработать первый и только потом второй элемент, а они почему-то разом это делают, на железе кто-нить проверял ?
о, кажется мелкий всё же взглянул на эпюры входов/выходов триггера, жаль правда не обратил внимание на генератор импульсов, который в схемах нужно не спомощью TON-а делать(импульс на один цикл), а используя блинк с периодом больше чем цикл ПР, возможно и связка D-FF будет работать
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Ну так, я же Вам чёрным по белому писал, что ЛЗ - это не для выхода, а для входа.
А в схеме, ОЛ понятия не имеет о линии задержки внутри макроса. Он делает "трассировку" того, что видит. Макрос для него - такой же элемент, как любой ФБ.
Забейте на предупреждение и запустите со связью вместо ЛЗ и увидите, что линия задержки в макросе прекрасно работает.
capzap не смотрел эпюры, просто знаю как он работает и читал заявления разработчиков что в ОЛ схема работает согласно расстановке на холсте (как впрочеми во многих других программах такого рода), что получается не соответствует действительности, потому что цепочка Д триггеров срабатывает одновременно, чего быть не должно, так что тут Сергей308 прав.
еще раз повторю, на его картике нарисован генератор на основе TON, а нужен BLINK. Просто если уж все знают так хорошо как устроен триггер, то почему все решили что он должен срабатывать за один цикл ПР, он работает от синхроимпульсов, увеличите их и вся связка триггеров успеет сформировать нужные сигналы, разве не так, только все уперлись в линию задержки
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
В этом и есть баг. Как раз ОЛ вполне могло бы смотреть на фактический состав макроса.
Ещё раз русским по форуму объясняю. На вход с сигнал "приходит" тогда, когда ПР(ОЛ) начинает считать конкретный триггер. А считать второй, ПР (ОЛ) начинает после того, как посчитает первый! Строго в соответствии с заявлением "расчёт ведётся последовательно от входа к выходу". Т.е., к этому моменту на д УЖЕ 1 (то, что на выходе УЖЕ ПОСЧИТАННОГО ПЕРВОГО)! Отсюда такое поведение. Чтобы этого избежать, состояния входов д всех триггеров нужно "заморозить" в состоянии прошлого цикла. Именно это делает ЛЗ.
Зачем? Каждый раз перекомпилировать блок, который уже скомпилирован?
Макрос - это уже не "набор логики с паутиной связей", а готовый блок-подпрограмма/процедура/функция.
Важно, что ЛЗ в макросе никуда не потерялась. Она работает. Хоть и использована неправильно.
Последний раз редактировалось pop70; 03.08.2017 в 17:59.
pop70, блин, когда первый посчитал, на входе с второго ДАВНО 1, то есть "поезд" фронт сигнала прошел. а в ОЛ они почему то выполнились одновременно.
Ваши права
Ответить с цитированием