Без понятия. У меня в Google Chrome работает.Цитата:
Сообщение от Сергей0308
Я говорю про этот пост:
Цитата:
Сообщение от Владимир Ситников
Без понятия. У меня в Google Chrome работает.Цитата:
Сообщение от Сергей0308
Я говорю про этот пост:
Цитата:
Сообщение от Владимир Ситников
pop70 - по буквам, если на вход С Д-триггера пришел сигнал РАНЬШЕ, чем на вход Д, состояние его поменяться не должно. То есть на входе Д уже должна быть единица, чтобы фронт сигнала на С передал ее на выход. то есть работать должен ТОЛЬКО момент фронта сигнала...
Один Д триггер работает правильно, ну он один и есть. а два уже нет. Так как заявления разработчиков о том, что все элементы выполняются последовательно согласно расстановке на схеме не соответствуют действительности Оба Д триггера определяют фронт одновременно, но у второго триггера по отношению к первому должна быть задержка сигнала на входе Д, так как сперва должен отработать первый и только потом второй элемент, а они почему-то разом это делают, на железе кто-нить проверял ?
о, кажется мелкий всё же взглянул на эпюры входов/выходов триггера, жаль правда не обратил внимание на генератор импульсов, который в схемах нужно не спомощью TON-а делать(импульс на один цикл), а используя блинк с периодом больше чем цикл ПР, возможно и связка D-FF будет работатьЦитата:
Сообщение от melky
Ну так, я же Вам чёрным по белому писал, что ЛЗ - это не для выхода, а для входа.Цитата:
Сообщение от Владимир Ситников
А в схеме, ОЛ понятия не имеет о линии задержки внутри макроса. Он делает "трассировку" того, что видит. Макрос для него - такой же элемент, как любой ФБ.
Забейте на предупреждение и запустите со связью вместо ЛЗ и увидите, что линия задержки в макросе прекрасно работает.
capzap не смотрел эпюры, просто знаю как он работает и читал заявления разработчиков что в ОЛ схема работает согласно расстановке на холсте (как впрочеми во многих других программах такого рода), что получается не соответствует действительности, потому что цепочка Д триггеров срабатывает одновременно, чего быть не должно, так что тут Сергей308 прав.
еще раз повторю, на его картике нарисован генератор на основе TON, а нужен BLINK. Просто если уж все знают так хорошо как устроен триггер, то почему все решили что он должен срабатывать за один цикл ПР, он работает от синхроимпульсов, увеличите их и вся связка триггеров успеет сформировать нужные сигналы, разве не так, только все уперлись в линию задержкиЦитата:
Сообщение от melky
В этом и есть баг. Как раз ОЛ вполне могло бы смотреть на фактический состав макроса.Цитата:
Сообщение от pop70
Ещё раз русским по форуму объясняю. На вход с сигнал "приходит" тогда, когда ПР(ОЛ) начинает считать конкретный триггер. А считать второй, ПР (ОЛ) начинает после того, как посчитает первый! Строго в соответствии с заявлением "расчёт ведётся последовательно от входа к выходу". Т.е., к этому моменту на д УЖЕ 1 (то, что на выходе УЖЕ ПОСЧИТАННОГО ПЕРВОГО)! Отсюда такое поведение. Чтобы этого избежать, состояния входов д всех триггеров нужно "заморозить" в состоянии прошлого цикла. Именно это делает ЛЗ.Цитата:
Сообщение от melky
Зачем? Каждый раз перекомпилировать блок, который уже скомпилирован?Цитата:
Сообщение от Владимир Ситников
Макрос - это уже не "набор логики с паутиной связей", а готовый блок-подпрограмма/процедура/функция.
Важно, что ЛЗ в макросе никуда не потерялась. Она работает. Хоть и использована неправильно.
pop70, блин, когда первый посчитал, на входе с второго ДАВНО 1, то есть "поезд" фронт сигнала прошел. а в ОЛ они почему то выполнились одновременно.
Так, потому, что никто не умеет писать программы, работающие параллельно.Цитата:
Сообщение от melky
Триггеры обсчитываются ОДИН ЗА ДРУГИМ.
ОЛ смотрит твою схему и составляет себе "план действий":
1. Считать состояния входов ПР.
2. Посчитать триггер1
3. Посчитать триггер2
4. Посчитать триггер3
.....
nn. Записать выходы ПР.
Попробуйте написать ему задание, чтобы все триггеры считались одновременно. :)
Потому, что вся связка д-триггеров должна отработать по одному-единственному ФРОНТУ на входах с, за один-таки цикл. Иначе, это не д-триггер!Цитата:
Сообщение от capzap
Во время расчёта одного цикла, нет "давно". От начала цикла, до его конца "времени нет". "Давно" - это прошлый цикл.Цитата:
Сообщение от melky
Это в "железе" время идёт непрерывно, а в программе
"Время остановилось", считались входы, посчиталась программа цикла, записались выходы, "время прыгнуло вперёд на 1 цикл". :)
да ладно, в железе есть фронт, может быть он всегда упоминается с определением нарастающий, нет?Цитата:
Сообщение от pop70
Вот эпюра, самая первая сработка выхода, как раз случай когда генератор имеет логическую единицу, а D-вход подошел с "опозданием", выход сработает, а по Вашему должен пропустить подъем потому что фронт не "словил"
Ну, wal79 утверждал, что ОЛ и так перекомпилирует схему на каждый чих.Цитата:
Сообщение от pop70
Тем не менее, для анализа "наличия циклических" связей не обязательно учитывать все-все-все связи внутри макроса.
Достаточно один раз его скомпилировать и понять между какими входами и выходами есть цепочки связей, исключая линии задержки.
Т.е. процесс перекомпиляции может быть быстрым и инкрементальным.
Это уже не вам судить. Хочу -- ставлю задержку. Говорить "неправильно" без конкретной решаемой задачи "неправильно".Цитата:
Сообщение от pop70
Эта эпюра не имеет никакого отношения к д-триггеру.Цитата:
Сообщение от capzap
И да! Вход С "настоящего" д-триггера - динамический. Т.е., активен в момент перехода сигнала с 0 на 1 (или с 1 на 0 в случае инверсного входа)
P.S.
Кстати, да. Я был не прав. Бывает д-триггер со статическим входом С.
Мы какой обсуждаем?
Судя по эпюрам из справки ОЛ - динамический.
а так тоже не онЦитата:
Сообщение от pop70
Перекомпилирует схему, а не все её составляющие.Цитата:
Сообщение от Владимир Ситников
Вас напрягает предупреждение, которое можно игнорировать, если знаешь что делаешь?
"Не правильно" с точки зрения идеи "линии задержки" как "значение входа в прошлом цикле".
В схеме больше, чем один вход на конец ЛЗ не поставишь.
Кстати, попал на один косяк в работе ЛЗ.
В макросе CTMAX.
В чём дело - хз. Повторить не могу. И в программе, и в новом макросе работает. А в том пришлось константу делать 0 и вставлять инвертор - тогда всё работает.
И? Я же говорил, что перекомпилировать макросы (если они не менялись) не обязательно.Цитата:
Сообщение от pop70
Меня напрягает то, что ОЛ вставляет лишнюю задержку при "самозамыкании макроса, который внутри уже содержит задержку".Цитата:
Сообщение от pop70
По-моему, лишней задержки добавляться не должно.
А вдруг я реально хочу, чтобы у меня блок выдавал "отрицание того, что было на прошлом цикле"?Цитата:
Сообщение от pop70
Не пойму чего тут неправильного с точки зрения "линии задержки".
Тоже не он. Это всё, о чём Вы пишете - статический Д-триггер.Цитата:
Сообщение от capzap
А на картинке вход обозначен динамическим.
Такой лажи в и-нете можно полно найти.
"Неверь глазам своим"(с). Даже если врут по-английски :)
А поменяйте связи на входах местами и схема заработает.Цитата:
Сообщение от pop70
ОЛ ничего не добавляет. Он говорит программисту, что обнаружил сомнительное место. Можешь его тупо послушаться, если плохо понимаешь что делаешь, а можешь оставить как есть.Цитата:
Сообщение от Владимир Ситников
Отрицание того, что было в прошлом цикле, это ЛЗ+NOT (NOT(вчера)), а не NOT+ЛЗ (Завтра(NOT(???))
Сравните результат при запуске
Угу. Почему-то :)Цитата:
Сообщение от Василий Кашуба
Вот это - баг.
Вот видеозапись: http://recordit.co/EjrZEKJELy (это же видео в виде анимированного gif: http://g.recordit.co/EjrZEKJELy.gif )Цитата:
Сообщение от pop70
Макрос NOTD это вход ==> NOT =задержка=> выход
Очевидно, что вариант "макрос" и "вне макроса" выдают разный ответ.
Ой, неужели вас так вводит в ступор линия задержки на выходе?Цитата:
Сообщение от pop70
Да пёс с ней. Могу сделать такой же пример с задержкой по входу:
http://recordit.co/D78FxgJAtw (оно же http://g.recordit.co/D78FxgJAtw.gif )
Результат всё равно один и тот же: вариант с "макросом" требует двух циклов на переключение состояния, а точно такой же вариант (но без макроса) переключается на каждом цикле. Отсюда вывод: в варианте с макросом ОЛ добавляет лишнюю задержку. Иначе как ещё объяснить то, что период генератора меняется?
Вы же хотите, чтобы, при анализе схемы, она анализировалась на наличие циклов без ЛЗ?Цитата:
Сообщение от Владимир Ситников
А для этого, придётся макрос вставлять в схему в развёрнутом виде, и заново просчитывать всё дерево связей.
У Вас полцикла в макросе, а полцикла снаружи. Как проверить на ЛЗ внутри, не развернув и не "перекомпилировав" дерево проекта с развёрнутым макросом?
Это не баг. Первым обрабатывается верхний вход, а нижний вторым.Цитата:
Сообщение от pop70
Вопрос хороший и он тесно пересекается с вопросом "а как вообще должны вычисляться значения выходов".Цитата:
Сообщение от pop70
Как вам такой вариант?
1) Берём выход
2) Смотрим что к нему подключено
3) Если подключен ФБ / функция, то пытаемся вычислить этот самый ФБ/функцию. Что для этого нужно? Нужно знать значения входов.
4) Пытаемся вычислить значение каждого входа:
4.1) Если на вход подключена линия задержки, то просто берём её значение
4.2) Если вход подключена простая связь, то пытаемся вычислить значение того, откуда эта связь выходит (точно так же как на шаге 3)
5) Потом обновляем значения в линиях задержки (не хочу заострять внимание на том как именно)
Если же на этапе 4.2 наступает цикл, то говорим "ай-яй-яй, взрываем ПР и заканчиваем работу".
Теперь о том, как сделать "раздельную компиляцию".
Для того, чтобы знать "можно ли замыкать выход X на вход A" не обязательно знать весь состав макроса.
Достаточно лишь знать, что "при попытке вычислить выход X этого самого макроса нам потребуются входы A и B.
Иными словами, при компиляции макроса мы выполняем алгоритм (шаги 1..5) и таким образом мы узнаём какие входы являются "обязательными".
В конкретном же примере: Макрос DNOT(вход) == NOT(DELAY(вход)). На шаге 4.1 алгоритм понимает, что для вычисления значения макроса будет браться значение из линии задержки. И, таким образом, получается, что "выход 1 не связан напрямую со входом", и, значит, можно без проблем в результирующей программе замыкать выход на вход.
Если у макроса M входов и N выходов, то дополнительно нужно M*N бит информации, чтобы зафиксировать то, между какими входами-выходами есть прямая связь. Содержимое же макроса уже играет роли.
Или я чего-то путаю?
O__OЦитата:
Сообщение от Василий Кашуба
Что значит "первым обрабатывается верхний вход"? Вы что вкладываете в понятие "обработка входа XOR"?
Блин, да. Вставляет. :)Цитата:
Сообщение от Владимир Ситников
Это да - косяк, однако :)
да как в javascript: foo && bar, если первое false то второе уже не проверяетсяЦитата:
Сообщение от Владимир Ситников
capzap, в железе будет так, есть t фронта, если на момент перехода D=0 то и выход будет равен 0. и так далее.
Никакого опоздавшего железо не ждет, никогда...
http://digitalchip.ru/d-trigger - это железячный + его элементная схема - повторите на ПР или ПЛК...
Сейчас это реализовано по-другому.Цитата:
Сообщение от Владимир Ситников
Видимо, при наступлении "цикла", входу просто назначается статическая переменная, инициализируется нулём (при компиляции), и вычисляется тот самый выход, исходя из значения этой переменной. Значение выхода пишется в переменную "зацикленного" входа.
Т.е., "автоматом" встаёт ЛЗ.
Да вот нифига. У xor-a в любом случае нужно оба входа считать.Цитата:
Сообщение от capzap
Это же, всёже, or, а не and.
Да и в нерабочем варианте видно, что 1 на вход xor-a не пришла по "железной связи".
Тут какой-то другой косяк.
И ведь в другом макросе работает и с нижним входом.
я про то что применяется некоторая последовательность,слева на право, сверху внизЦитата:
Сообщение от pop70
да уже сказали что картинка не правильнаяЦитата:
Сообщение от melky
PS раз уж картинки лажевые бывают, можно и на осциллограф посмотреть https://www.google.ru/url?sa=t&rct=j...u2TKWAWYhIg-8A и главное ангицкий не нужен и так подсказки дают
Нет. Тут какая-то проблема с моментом инициализации константы, скорее всего. Похоже, она в том примере, почему-то, инициализируется позже нижнего входа xor-а, но до ЛЗ. Не понятно почему в других случаях такого нет. Как-то видимо связано с построением дерева вычислений и с остальной схемой. Хотя, константы, по идее, должны инициализироваться в первую очередь - раньше всего остального.Цитата:
Сообщение от capzap
Интересно. Оно и в ПР так же будет, или это симулятор только дурит?
ну специалист по оптимизации здесь не я, но например считаю что на уровне асма легче взять значение и найти его предыдущее состояние, чем искать значение как текущего так и предыдущего значения, хранящихся независимо друг от друга
А вообще, разбор схемы и составление последовательности операций, примерно так и идёт.Цитата:
Сообщение от Владимир Ситников
Т.е, на этапе "компиляции", создаётся "дерево" с корнем на выходе, выстраиваются ветви к узлам ФБ пока не доберёмся до входов или до констант. Циклы "обрубаются" статическими переменными.
Если макросы будут с "необязательными" входами, то от этих входов придётся ростить новые деревья, иначе, на них никогда ничего не придёт. А как от них считать "расстояние", задающее порядок расчёта (дальше от корня раньше считается, а они от главного корня отрублены)?
Вобщем, хз. Наверное, можно, но не просто.
А их не надо искать. И текущее состояние, впринципе не надо хранить. Вычислили, записали в стат.переменную (ЛЗ), отдали по этапу, и забыли.Цитата:
Сообщение от capzap
сделал сейчас D-Trigger в Logo, в общем та же песня, сам по себе работает правильно, 3 последовательно ведут себя так же, пока не добавишь задержки между ними.