Просмотр полной версии : Критическая ошибка в среде программирования Овен ЛОДЖИК или это я д-ак
alek4322
21.05.2017, 01:54
Помогите пожалуйста, пишу программу для мойки самообслуживания на ПР200, столкнулся с проблемой из-за которой пришлось написать около 120 не работающих программ с разными концепциями логики работы, но так и не смог обойти, как мне кажется ошибку в среде программирования Овен лоджик, может это я чего-то не понимаю, дело в том что выходящий сигнал из одного места при разветвлении в разные места приходит не одновременно, на одну или несколько ножек разных логических блоков он приходит сразу, а на остальные позже на один цикл, из-за этого пришлось отказаться от многих (фишек) и переписать проще. Только так она заработала. Подскажите пожалуйста это правда как я думаю ошибка в ОВЕН ЛОДЖИК или это я что-то не так делаю. Видео прилагаю
https://youtu.be/PVYxMVW-TaE
Используйте линии задержки ....Алгоритм то выполняется последовательно и в сложных схемах ,с множеством обратных связей такое возможно .
Василий Кашуба
21.05.2017, 12:35
А можете выложить вашу программу, с описанием работы, на форум, или подробное ТЗ. Посмотрим, чем можно помочь.
Владимир Ситников
21.05.2017, 13:29
или это я что-то не так делаю.
У вас цикл из связей, и таких программ по-хорошему, вообще разрешать нельзя.
Подскажите пожалуйста это правда как я думаю ошибка в ОВЕН ЛОДЖИК
Ага, проблема ОЛ 1.8 в том, что оно позволяет программы с циклами и никак не говорит о проблеме.
Скопируйте проект, и откройте его в ОЛ 1.9 (http://www.owen.ru/forum/showthread.php?t=25870). Та версия покажет где у вас циклы. Исправите циклы -- будут данные приходить "одновременно".
alek4322
22.05.2017, 23:25
Используйте линии задержки ....Алгоритм то выполняется последовательно и в сложных схемах ,с множеством обратных связей такое возможно .
Использую линии задержки, внизу программы на видео, и ещё в некоторых местах, а иногда просто подстраиваю логику работы программы под (не одновременность сигналов), но дело в том что программа начинает рушится как карточный домик, пытаешься исправить в одном месте начинает работать неправильно в другом месте и т.д.
Тогда ,как сказал Василий -проект в студию ,иначе никто не поможет
alek4322
23.05.2017, 00:32
А можете выложить вашу программу, с описанием работы, на форум, или подробное ТЗ. Посмотрим, чем можно помочь.
Выложить программу полностью не могу, так как коммерческий проект (принадлежит не мне, хотя я её делаю). ТЗ. примерно таково. Если нажимаешь какую либо кнопку на щите управления, то ни чего произойти не должно, пока пользователь не кинет жетон или монету в жетоноприёмник (жетоноприёмник эталонного типа), как только пользователь кинул жетон, на СМИ2 выставляется время соответствующее уставке, то есть один жетон равен, допустим, 33 секундам, если закинул второй жетон, то соответственно время обратного отсчёта на СМИ2 выставляется 33+33=106 (то есть одна минута шесть секунд и т.д.) эту уставку, соответствия, секунд жетонам, пользователь должен выставлять сам, как ему захочется на экране ПР200. Далее должна также быть изменяемая на экране ПР200 уставка рублей, соответствующая стоимости одного жетона, это для журнала прибыли, который записывает ПР200 каждый день и пользователь должен по своему желанию через экран ПР200 узнать прибыль, которую заработал пост мойки за, допустим, предыдущий день или любой другой день текущего месяца, к сажелению на ПР200 мне удалось создать только месячный журнал, а не годовой, так как в ПР200 не хватает памяти для энергонезависимых переменных на год. Далее, все уставки времени, рублей и т.д пользователь может изменить только если знает пароль входа в меню изменения уставок. Далее, должна быть возможности смены пароля через (пин код) который знает только хозяин мойки (пользователь). Ещё должен быть (сервис код) который знает только сервисный работник который выполняет плановое сервисное обслуживание АВД (аппаратов высокого давления) обслуживание это замена масла, чистка смазка и т.д. При этом естественно в программе на ПР200 реализован счётчик моточасов, по истечении 400 часов работы загорается светодиод на ПР200, который сигнализирует пользователю что пора вызывать сервисного работника для обслуживания, при этом в ПР200 производится запись того что одно обслуживание произведено ещё не было, если проходит ещё 400 часов и обслуживания произведено не было, то производится запись того что обслуживаний аппаратов АВД не было два раза и т.д. когда сервисный работник произвёл обслуживание то он производит запись в ПР200 что было произведено одно обслуживание и т.д. при этом запись необслуживаний обнуляется. Далее когда пользователь кинул жетон программа позволяет произвести запуск мойки в режеме вода, вода+химия, вода+воск естественно одновременно подать воду химию и воск программа должна запрещать, выбор режима мойки осуществляется через кнопку пауза. Далее, время обратного отсчёта в режиме вода должен соответствовать реальному времени, то есть секунда обратного отсчёта выводимая на СМИ2 должна соответствовать реальной секунде, а вот когда выбирается режим работы вода+химия или вода+воск, то время должно ускорятся в два раза или во сколько раз установит сам хозяин, тем самым изменяется стоимость одной минуты или секунды (неважно) режима роботы мойки вода, химия или воск. Далее, необходимо что бы хозяин мог сам выбирать что будет выводится на СМИ2, обратный отсчёт времени или обратный отсчёт рублей соответствующий обратному отсчёту времени. Ну вот примерно всё техническое задание.
alek4322
23.05.2017, 00:47
А можете подробнее объяснить что такое цикл связей и почему таких программ по-хорошему, вообще разрешать нельзя, дело в том что я начинающий пользователь ОВЕН ЛОДЖИК. Смотрел ОЛ 1.9 как я понял ещё не вышла она только в БЕТА версии. Заранее благодарен за помощь.
Владимир Ситников
23.05.2017, 01:20
Смотрел ОЛ 1.9 как я понял ещё не вышла она только в БЕТА версии
Так какая разница бета или нет? Её же открыть только для того, чтобы она показала есть циклы или нет.
Проблема циклов в том, что, если в программе есть цикл из связей, то совершенно непонятно как выполнять такую программу.
Для примера, представьте такую программу:
+-----+
1 --->| |
| ADD |---+----> ?
,->| | |
| +-----+ |
| v
^------------'
Чему должен быть равен результат такого блока?
Невозможно "досчитать до бесконечности". Поэтому программы с циклами плохие -- их непонятно как вычислять.
Единственно правильный вариант -- использовать "обратные связи" (начиная с 1.9 будут называться "линии задержки"). И, возможно, переменные помогут (но не факт)
alek4322
23.05.2017, 02:42
Так какая разница бета или нет? Её же открыть только для того, чтобы она показала есть циклы или нет.
Проблема циклов в том, что, если в программе есть цикл из связей, то совершенно непонятно как выполнять такую программу.
Для примера, представьте такую программу:
+-----+
1 --->| |
| ADD |---+----> ?
,->| | |
| +-----+ |
| v
^------------'
Чему должен быть равен результат такого блока?
Невозможно "досчитать до бесконечности". Поэтому программы с циклами плохие -- их непонятно как вычислять.
Единственно правильный вариант -- использовать "обратные связи" (начиная с 1.9 будут называться "линии задержки"). И, возможно, переменные помогут (но не факт)
Пробую установить ОЛ 1.9 не получается, видео прилагаю
https://youtu.be/LQrwzSW5N9c просмотрел программу вроде вечных циклов не обнаружил, что такое использовать обратные связи, как их использовать?
Пробую установить ОЛ 1.9 не получается, видео прилагаю.... просмотрел программу вроде вечных циклов не обнаружил, что такое использовать обратные связи, как их использовать?
Так Вы же OL новый установили. У Вас старые проекты не открываются и, судя по всему, отсутствует интернет соединение для связи с сервером критических обновлений. По крайней мере, судя по Вашему видео.
32351
Доброе время суток. Помогите пожалуйста разобраться. Что можно сделать с критической ошибкой на схеме? Линия задержки не вставляется. Хотя сам макрос в режиме симуляции работает. ПР200 ОЛ версии 1.9. Спасибо
32351
Доброе время суток. Помогите пожалуйста разобраться. Что можно сделать с критической ошибкой на схеме? Линия задержки не вставляется. Хотя сам макрос в режиме симуляции работает. ПР200 ОЛ версии 1.9. Спасибо
Удалить выделенную связь, вместо неё поставить "линию задержки"
Здесь и ниже (подсветит когда эту замените)
Спасибо большое, но дело в том ,что не заменяется. Пробовал удалить и вставить линию задержку. Т.е. соединение удаленной связи не происходит
Спасибо большое, но дело в том ,что не заменяется. Пробовал удалить и вставить линию задержку. Т.е. соединение удаленной связи не происходит
Сохраните проект и снова загрузите .
Спасибо большое всем кто ответил. поставил логику И вместо этой связи, все нормально, не ругается
Владимир Ситников
01.08.2017, 13:41
Спасибо большое всем кто ответил. поставил логику И вместо этой связи, все нормально, не ругается
Покажите картинку как получилось.
Если такая картинка без линий задержки и ОЛ не ругается, то это похоже на ошибку в самом ОЛ.
Сергей0308
01.08.2017, 14:24
Мне тоже не понятно, почему в некоторых случаях подсвечивается, например в этом:
32354
И Д-триггеры неверно работают, когда из них регистр сдвига составляешь, без задержки(обратной связи) никак:
32355
По-моему это устранить надо, а не лабудой заниматься!
Василий Кашуба
01.08.2017, 14:44
Мне тоже не понятно, почему в некоторых случаях подсвечивается, например в этом:
32354
И Д-триггеры неверно работают, когда из них регистр сдвига составляешь, без задержки(обратной связи) никак:
32355
По-моему это устранить надо, а не лабудой заниматься!
Всё тут правильно, сигналы нужно разнести по времени, относительно синхронизирующего.
потому что программисты не могут сделать, чтобы и так и так работало. Всегда будет где-то косяк, либо как раньше либо как сейчас.
Мне тоже не понятно, почему в некоторых случаях подсвечивается, например в этом:
32354
И Д-триггеры неверно работают, когда из них регистр сдвига составляешь, без задержки(обратной связи) никак:
32355
По-моему это устранить надо, а не лабудой заниматься!
Проблема мифических обратных связей - это и есть ошибка самого ОЛ.
Нигде таких запретов нет, только в ОЛ.
Владимир Ситников
01.08.2017, 14:45
Мне тоже не понятно, почему в некоторых случаях подсвечивается, например в этом:
32354
А чего непонятного?
Есть цикл (с выхода на вход) -- такое не должно работать.
Буквально недавно я показывал пример (http://www.owen.ru/forum/showthread.php?t=26787&p=248608&viewfull=1#post248608) почему такие схемы не должны работать.
Сергей0308
01.08.2017, 14:50
А чего непонятного?
Есть цикл (с выхода на вход) -- такое не должно работать.
Буквально недавно я показывал пример (http://www.owen.ru/forum/showthread.php?t=26787&p=248608&viewfull=1#post248608) почему такие схемы не должны работать.
Ну тогда программистам не помешало бы посмотреть как работает Д-триггер и так же сделать!
Проблема циклов в том, что, если в программе есть цикл из связей, то совершенно непонятно как выполнять такую программу.
Для примера, представьте такую программу:
+-----+
1 --->| |
| ADD |---+----> ?
,->| | |
| +-----+ |
| v
^------------'
Чему должен быть равен результат такого блока?
Невозможно "досчитать до бесконечности". Поэтому программы с циклами плохие -- их непонятно как вычислять.
Тогда и в символьных языках
Чему должен быть равен результат такого блока?
A=A+1
То же не должно работать?
https://www.youtube.com/watch?v=1FXkpAETmgE
Василий Кашуба
01.08.2017, 14:59
Тогда и в символьных языках
Чему должен быть равен результат такого блока?
A=A+1
То же не должно работать?
Символьные языки построчно обрабатываются.
Сергей0308
01.08.2017, 15:03
Так нет там ни каких циклов в данном случае с Д-триггером, неоднократно вопросы задавались, собрал из Д-триггеров регистр сдвига, почему не работает как надо, ну сколько уже нормальные, кто понимает как Д-триггер работает будет страдать, мучится из-за неграмотности других, почему нельзя нормально, по-человечьи сделать?
Символьные языки построчно обрабатываются.
А в ОЛ как?
А в КДС как?
И не только в КДС
https://www.youtube.com/watch?v=w596vHHVm5A
Мифические обратные связи - фирменная фишка ОВЕН
Василий Кашуба
01.08.2017, 15:22
Как то не по порядку считает.
Владимир Ситников
01.08.2017, 15:22
А в КДС как?
И не только в КДС
Вы серьёзно или троллите?
Разумеется, вся проблема именно в неопределённости того, в каком порядке должны выполняться элементы на схеме.
В строчном языке порядок явно указывается.
Если сказано
A = A+1
B = A,
то ясно, что сначала A увеличится на 1, а потом B обновится.
В случае же графического языка, нет однозначного порядка выполнения.
Да, можно было бы говорить, что "да в том же КДС есть возможность перенумеровать блоки". Кто-то может сказать, что "и в ОЛ есть возможность пронумеровать блоки".
Но, блин, часто ли этой возможностью пользуются?
Удобно ли следить за этими цифорками и сверять "в нужном ли порядке выполнилась схема"?
А что делать, если схему нужно поменять? Номера же все съезжают.
Даже в мою бытность на форуме много раз поднимались вопросы типа "у меня две одинаковые линии от выхода принимают разные значения".
В этом плане, запрет "циклических связей" на самой схеме позволяет составлять программы вообще без использования "явной нумерации".
В нужных местах добавили линии задержки и ОЛ выстраивает выполнение "как нужно".
Пример с "самозамкнутой операцией AND" показывает лишь то, что две одинаковые линии, выходящие из результата AND по факту принимают разные значения. Одна оказывается равна обновлённому значению, а вторая -- предыдущему. Хотя, визуально они неотличимы.
Да, документацию стоит доработать, но, на мой взгляд, ручная расстановка "линий задержки" гораздо проще для последующего понимания (сразу видно, что значение приходит из прошлого такта), и гораздо проще в разработке-поддержке схем, ведь абсолютно не нужно думать о порядке выполнения блоков. Как нарисовано, так и выполняется.
Так для этого же и сделана линия задержки ,как в реальном железе .Лет пять назад этот вопрос обсуждали ,пока разработчики не добавили линию задержки .Задержки нужны не только в регистрах сдвига - ставь куда нужно.
Сергей0308
01.08.2017, 15:54
Так для этого же и сделана линия задержки ,как в реальном железе .Лет пять назад этот вопрос обсуждали ,пока разработчики не добавили линию задержки .Задержки нужны не только в регистрах сдвига - ставь куда нужно.
В реальном железе для создания регистра сдвига соединяют выход Д-триггера с D входом последующего непосредственно, без всяких устройств задержки сигнала, в ОЛ Д-триггер работает не так, как в железе, об этом я и толкую, что вводит в заблуждение большинство людей и я на эти грабли наступал, зачем делать так?
Владимир Ситников
01.08.2017, 16:03
В реальном железе для создания регистра сдвига соединяют выход Д-триггера с D входом последующего непосредственно, без всяких устройств задержки сигнала
Именно со следующим и в ОЛ можно соединить простой связью.
Но в вашей схеме есть как минимум 1 цикл, и тут ОЛ резонно требует линию задержки.
То, что вы её воткнули между D-триггерами это лишь ваш выбор. Можно было (и, скорее всего, логичнее было бы) и после них
в ОЛ Д-триггер работает не так, как в железе, об этом я и толкую
Можете простой пример сделать на одном-двух-трёх Д-триггерах, на котором было бы видно, что "ОЛ работает не так"?
По-моему, ваш пример с цепочкой Д-триггеров лишь подтверждает то, что ОЛ работает верно (требует задержку), а вы не понимаете смысл этой самой задержки и ставите её куда попало.
Сергей0308
01.08.2017, 16:20
Именно со следующим и в ОЛ можно соединить простой связью.
Но в вашей схеме есть как минимум 1 цикл, и тут ОЛ резонно требует линию задержки.
То, что вы её воткнули между D-триггерами это лишь ваш выбор. Можно было (и, скорее всего, логичнее было бы) и после них
Можете простой пример сделать на одном-двух-трёх Д-триггерах, на котором было бы видно, что "ОЛ работает не так"?
По-моему, ваш пример с цепочкой Д-триггеров лишь подтверждает то, что ОЛ работает верно (требует задержку), а вы не понимаете смысл этой самой задержки и ставите её куда попало.
Соединить в железе инверсный выход Д-триггера со входом данных это так делают для получения Т-триггера, ничего плохого в этом нет, а что регистр сдвига, не кольцевой из Д-триггеров неадекватно работает уже много лет всем известно, неоднократно вопросы задавались(я участвовал в обсуждении в таких темах) и палец о палец не стукается, ни чего не исправили за много-много лет!
Василий Кашуба
01.08.2017, 16:25
Мне тоже не понятно, почему в некоторых случаях подсвечивается, например в этом:
32354
И Д-триггеры неверно работают, когда из них регистр сдвига составляешь, без задержки(обратной связи) никак:
32355
По-моему это устранить надо, а не лабудой заниматься!
Всё тут правильно, сигналы нужно разнести по времени, относительно синхронизирующего, иначе они все разом изменят своё состояние.
Сергей0308
01.08.2017, 16:27
Всё тут правильно, сигналы нужно разнести по времени, относительно синхронизирующего, иначе они все разом изменят своё состояние.
Василий, я не понял Вы за, как в железе сделать или против?
Вы поймите, я не для себя это прошу, а для новичков, я то уже почти по всем граблям прошёлся!
Владимир Ситников
01.08.2017, 16:48
я то уже почти по всем граблям прошёлся!
Вы второй раз пройдитесь, и разберитесь в том, почему нельзя просто брать и замыкать выход на вход.
"В железе" оно работает только из-за того, что вы там не следите за "количеством тактов, которые потребуются для выполнения схемы".
Соединили -- и оно как-то работает, за какое-то время устаканивается.
В ОЛ же поведение должно быть предсказуемо. Т.е. должно быть достаточно посмотреть на схему и понять куда пойдут сигналы, где задержатся и т.п.
Вот в железе можно подать выход "NOT" на его же вход.
Что теперь? Из-за этого и в ОЛ должна быть возможность замкнуть выход NOT'а на его вход? И что получится? Генератор со случайной частотой?
Или взорваться должно?
Сергей0308
01.08.2017, 17:07
Вы второй раз пройдитесь, и разберитесь в том, почему нельзя просто брать и замыкать выход на вход.
"В железе" оно работает только из-за того, что вы там не следите за "количеством тактов, которые потребуются для выполнения схемы".
Соединили -- и оно как-то работает, за какое-то время устаканивается.
В ОЛ же поведение должно быть предсказуемо. Т.е. должно быть достаточно посмотреть на схему и понять куда пойдут сигналы, где задержатся и т.п.
Вот в железе можно подать выход "NOT" на его же вход.
Что теперь? Из-за этого и в ОЛ должна быть возможность замкнуть выход NOT'а на его вход? И что получится? Генератор со случайной частотой?
Или взорваться должно?
Вот Вы опять ничего не поняли, я даже не за то чтобы что-то изменить, а хотя бы за то, что бы вещи называть своими именами, вот в ОЛ UINT обозвали INT, многие вопросы задают спрашивают почему так-то да так-то, элемент обозвали Д-триггером который не работает как железный, вот может кто ответит на элементарный вопрос зачем намерено людей путать, ну назовите вы уинт уинтом или как ещё по-своему и расшифруйте значение, также с Д-триггером и никто бы не путался, лишних и ненужных вопросов не задавал бы, ну почему так нельзя???
вот в ОЛ UINT обозвали INT, многие вопросы задают спрашивают почему так-то да так-то
напрашивается вопрос а где в ОЛ пишут про типы данных, заходим в справку находим типы переменных и после упоминания про (int) дальше описывается его диапазон, ничего не утаивается
Не утаивается, но есть сложившееся правила.
Сергей0308
01.08.2017, 17:26
напрашивается вопрос а где в ОЛ пишут про типы данных, заходим в справку находим типы переменных и после упоминания про (int) дальше описывается его диапазон, ничего не утаивается
Хорошо что не написали что в ОЛ плюс это минус, а минус это плюс, смысл какой?
Если что-то назвали чёрным, оно должно быть чёрным, иначе понятия попутаются чёрного и белого!
Хорошо что не написали что в ОЛ плюс это минус, а минус это плюс, смысл какой?
Если что-то назвали чёрным, оно должно быть чёрным, иначе понятия попутаются чёрного и белого!
официальный тип данных в ОЛ - целочисленный, алиас (https://ru.wikipedia.org/wiki/Alias) в скобках можно посмотреть опять же в вики https://ru.wikipedia.org/wiki/%D0%A6%D0%B5%D0%BB%D0%BE%D0%B5_(%D1%82%D0%B8%D0%BF _%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85), про наличие знака упоминается с третьего абзаца, так что не ищите смысла где его нет
Владимир Ситников
01.08.2017, 17:44
Хорошо что не написали что в ОЛ плюс это минус, а минус это плюс, смысл какой?
Если что-то назвали чёрным, оно должно быть чёрным, иначе понятия попутаются чёрного и белого!
Про INT vs UINT действительно сомнительная штука. Даже то, что оно задокументировано не делает чести.
Если в ОЛ D-триггерах вам не нравится, что "железные D-триггеры всегда дают задержку, а ОЛ-Д-триггер срабатывает сразу", то так и пишите.
Вы же пишете, что "вот такая, мол, схема неправильно работает". Из этого тяжело понять, что имелось ввиду "сам по себе ФБ Д-триггера в ОЛ не соответствует обычному пониманию".
Сергей0308
01.08.2017, 18:13
Про INT vs UINT действительно сомнительная штука. Даже то, что оно задокументировано не делает чести.
Если в ОЛ D-триггерах вам не нравится, что "железные D-триггеры всегда дают задержку, а ОЛ-Д-триггер срабатывает сразу", то так и пишите.
Вы же пишете, что "вот такая, мол, схема неправильно работает". Из этого тяжело понять, что имелось ввиду "сам по себе ФБ Д-триггера в ОЛ не соответствует обычному пониманию".
Вы опять меня не правильно поняли, мне всё нравится в ОЛ и что бы там не написали всё равно найдём ему правильное имя и разберёмся как оно работает, это наоборот добавляет какую-то изюминку! Но другому, кто не знаком с ОЛ, а знает как работает Д-триггер и другие привычные понятия придётся потратить гораздо больше времени на постижение азов ОЛ из-за таких "особенностей", это даже по вопросам видно!
Вы опять меня не правильно поняли, мне всё нравится в ОЛ и что бы там не написали всё равно найдём ему правильное имя и разберёмся как оно работает, это наоборот добавляет какую-то изюминку! Но другому, кто не знаком с ОЛ, а знает как работает Д-триггер и другие привычные понятия придётся потратить гораздо больше времени на постижение ОЛ из-за таких "особенностей", это даже по вопросам видно!
В любом случае нужно потратить время на изучение ОЛ или прочтение темы форума,где это было сказано .Задержки нужны не только в д-триггерах ,но и стеках на сел ,везде где есть смена информации с привязкой ко времени одновременно в нескольких разрядах или регистрах .Нужно разделить по времени старое и новое значение (разнести по разным циклам) ,пока небыло линий задержки я ставил тон между разрядами, имитируя железо .
Сам принцип работы ПР подразумевает ,что все вычисления (действия) производятся в течении ОДНОГО цикла ПР. Ну нельзя же сделать изменения дважды в одном цикле .Даже генератор (инвертор с обратной связью) формирует 1 в течении одного цикла ,а потом 0 в следующем цикле .
Василий Кашуба
01.08.2017, 21:20
Василий, я не понял Вы за, как в железе сделать или против?
Вы поймите, я не для себя это прошу, а для новичков, я то уже почти по всем граблям прошёлся!
Вы что думаете в железе нет входных и выходных RC цепей, которые задерживают сигнал?
Сергей0308
01.08.2017, 21:59
Вы что думаете в железе нет входных и выходных RC цепей, которые задерживают сигнал?
Речь совсем не об этом, я во внутренности триггеров не лез, да и не важно как они устроены внутри, а как они работают! Вы же не смотрите как устроен например элемент 2И, Вам достаточно знать как он работает!
А так да там существует задержка распространения сигнала и например асинхронные счётчики дают "хвосты"(промежуточные состояния), поэтому и придумали синхронные счётчики, тоесть обвесили счётчик дополнительной логикой, зато сигнал на выходе всех разрядов появляется одновременно!
надо справочник по микросхемам найти и посмотреть, наверняка там есть задержки, так как d-trigger собран на элементарной базе и задержки там есть, ибо там транзисторы и прочее...
Сергей0308
01.08.2017, 22:08
надо справочник по микросхемам найти и посмотреть, наверняка там есть задержки, так как d-trigger собран на элементарной базе и задержки там есть, ибо там транзисторы и прочее...
Я же советовал: автор Шило "Популярные цифровые микросхемы", там очень доходчиво, автор наверно талант, овен порой напишет РЭ, без бутылки не разберёшься, а там сразу видно не овен писал!
Владимир Ситников
01.08.2017, 22:14
Речь совсем не об этом, я во внутренности триггеров не лез, да и не важно как они устроены внутри, а как они работают! Вы же не смотрите как устроен например элемент 2И, Вам достаточно знать как он работает!
Вы по-русски скажите: через какое количество циклов ПР на выходе AND должен появляться ответ?
По-просту говоря, подали сигнал на оба входа AND, и вопрос в том, через какое количество тактов должен получиться результат на выходе?
А должна ли связь между блоками вносить задержку? Скажем, чем длиннее связь, тем дольше "идёт сигнал".
А через какое количество циклов ПР должно стабилизироваться значение на выходе SEL?
А через какое количество циклов ПР должно стабилизироваться значение на выходе RTRIG?
А через какое количество циклов ПР должно стабилизироваться значение на выходе DTRIG?
В любом железе есть задержки .Они в основном играют отрицательную роль в схемотехнике (Гонки) и как следствие "волосы" на выходе (очень короткие импульсы) .НО в регистрах на D-триггерах они полезны и дают возможность построения регистров сдвига ,тоесть играют положительную роль .Ибо каждый разряд сначала переписывает старые значения со входа D ,а уж потом,с задержкой на выход выдает новые значения ...Все логические элементы в одном цикле делают одно обновление - считывание входов ,операция ,выдача на выход ...и так по всем элементам в одном цикле от выхода ко входу
Сергей0308
01.08.2017, 22:21
И обычно люди стараются повысить быстродействие устройств(счётчиков), а не задержки ввести!
Василий Кашуба
01.08.2017, 22:57
И обычно люди стараются повысить быстродействие устройств(счётчиков), а не задержки ввести!
Не ввести задержки и не удалить их, а уменьшить, для увеличения быстродействия.
И обычно люди стараются повысить быстродействие устройств(счётчиков), а не задержки ввести!
Вы про железо или эмулятор?
Сергей0308
02.08.2017, 00:21
Вы про железо или эмулятор?
Про микросхемы!
Сергей0308 отличия микросхем от любого ПР(ПЛК) заключается в том, что части микросхем работают параллельно всегда.
Например микросхема с 4-мя ИЛИ, каждый элемент ИЛИ работает параллельно друг другу. В ПР(ПЛК) такого НИКОГДА не будет, пока в них стоит один процессор.
Я как-то делал какой-то trigger на Logo!, который по схемотехнике состоит из И, ИЛИ, НЕ, но в чистом виде как в справочнике получил шиш с маслом, пока не начал добавлять задержки....
Так что просто примите это как данность работы ПР(ПЛК), тут каждый элементик работает четко последовательно, даже код внутри D-trigger и любого другого элемента.
Сергей0308 отличия микросхем от любого ПР(ПЛК) заключается в том, что части микросхем работают параллельно всегда.
Например микросхема с 4-мя ИЛИ, каждый элемент ИЛИ работает параллельно друг другу. В ПР(ПЛК) такого НИКОГДА не будет, пока в них стоит один процессор.
Я как-то делал какой-то trigger на Logo!, который по схемотехнике состоит из И, ИЛИ, НЕ, но в чистом виде как в справочнике получил шиш с маслом, пока не начал добавлять задержки....
Так что просто примите это как данность работы ПР(ПЛК), тут каждый элементик работает четко последовательно, даже код внутри D-trigger и любого другого элемента.
Ну почему. Принципиально возможно написать программу, однозначно обрабатывающую любые логические схемы из кучи элементов. Если их обработку вести по принципу работы самого ПР. Когда в начале цикла запоминаются все значения на входах элементов, потом расчитываются все состояния выходов исходя только из логики работы элемента, а в конце цикла записывается всё что насчитали на выходы.
Эквивалентно тому, что все внутренние связи заменить на "линии задержки" :)
Но действительно правильной "параллельной" работы всёравно не получится. :)
так я и написал, что замены микросхемам программно никогда не дождешься. Конечные выходы не самое главное бывает в программе.
Владимир Ситников
02.08.2017, 12:52
Ну почему. Принципиально возможно написать программу, однозначно обрабатывающую любые логические схемы из кучи элементов. Если их обработку вести по принципу работы самого ПР
Задумайтесь над тем, что является "принципом работы самого ПР".
Что туда создатели заложили, так оно и работает.
Сделать так, чтобы блок AND в ПР задерживал сигнал "на пол-такта", а блок DTRIG задерживал сигнал "на 2 такта" вообще никаких сложностей нет.
Сделать так, чтобы несколько блоков AND работали "одновременно" -- тоже никаких сложностей.
Можно сделать и так, чтобы от длины линии на схеме зависела задержка прохождения сигнала.
Будет ли это "прямо как реальная микросхема"? Вполне.
Но нужен ли реальным потребителям такой режим работы ОЛ-ПР?
Да никому такой режим не нужен, т.к. схемы будет составлять очень сложно. Придётся думать не только над самой схемой, но и придётся считать-учитывать задержки прохождения сигналов.
Для любителей эмуляции железа есть Verilog. Зачем превращать ОЛ в Verilog?
Задумайтесь над тем, что является "принципом работы самого ПР".
Я же написал как работает ПР.
Прочитал все входы, обработал по программе, записал результат на выходы. И снова по кругу.
Если составлять схемы из ПР как ФБ, то получится как будто все они соединены "линиями задержки"
Поставьте между входом и выходом ПР инвертор, и соедините их проводом.
Получится "генератор" с частотой, равной половинной частоте цикла.
"Железный" инвертор из любой цтфровой мс, с соединённым входом и выходом - полный аналог аналогового повторителя. Не будет он ничего генерировать - будет работать в режиме "усилителя" с коэффициентом усиления по напряжению 1(зато с огромным входным сопротивлением). Чтобы заставить его что-то генерировать, придётся ставить rc, lc и тому подобные "линии задержки", а точнее - фазосдвигающие цепочки.
Владимир Ситников вы когда нибудь настраивали компьютеры при помощи осцилографа ? знакомы с таким названием как ZX Spectrum ?
Просто так проще объяснить, когда у вас на выход попадают конечные сигналы а так же сигналы из середины схемы.
еще раз - НИКОГДА программа, работающая на одном процессоре не сможет выполнить эмуляцию работы микросхем сложного устройства.
На это способны только многопоточные чипсеты. Простой пример - синхронизация работы электронного зажигания в автомобиле с большими оборотами двигателя.
Вы просто не сможете это повторить на ПЛК с одним процессором. Даже если туда Intel воткнете...
Владимир Ситников
02.08.2017, 15:43
еще раз - НИКОГДА программа, работающая на одном процессоре не сможет выполнить эмуляцию работы микросхем сложного устройства.
Какие слова, какой типаж..
Вот именно эмуляцию можно на раз сделать, и проблем с этим никаких нет.
Иными словами, результат эмуляции будет повторять то, что вычисляют эти микросхемы.
Да, может оказаться, что "эмулятор" будет работать медленнее, чем реальное железо (ну, исходная схема выполняет вычисление за секунду, а эмулятору на это нужна минута), но именно сделать эмуляцию проблем вообще нет.
Простой пример - синхронизация работы электронного зажигания в автомобиле с большими оборотами двигателя.
Вы просто не сможете это повторить на ПЛК с одним процессором. Даже если туда Intel воткнете...
Не пойму каким образом связано электронное зажигание и невозможность это повторить на ПЛК с одним процессором.
ПЛК110М02 может реагировать на импульсы порядка 20 наносекунд. Неужели этого мало для какого-то "электронного зажигания"?
Сергей0308
02.08.2017, 15:55
Сергей0308 отличия микросхем от любого ПР(ПЛК) заключается в том, что части микросхем работают параллельно всегда.
Например микросхема с 4-мя ИЛИ, каждый элемент ИЛИ работает параллельно друг другу. В ПР(ПЛК) такого НИКОГДА не будет, пока в них стоит один процессор.
Я как-то делал какой-то trigger на Logo!, который по схемотехнике состоит из И, ИЛИ, НЕ, но в чистом виде как в справочнике получил шиш с маслом, пока не начал добавлять задержки....
Так что просто примите это как данность работы ПР(ПЛК), тут каждый элементик работает четко последовательно, даже код внутри D-trigger и любого другого элемента.
Ещё раз повторюсь, есть же сложившиеся понятия, как работает Д-триггер, ну придумали вы что-то похожее, работающее не совсем так, если у животных 4 ноги(лапы) это не значит, что их надо одинаково называть, короче можно назвать как-то иначе, например ДМ-триггер, подчёркивая эти различия в работе, если пользоваться их логикой, так одного слова достаточно в любом языке, что вводит некоторую путаницу на первых порах, капзап, похоже правильно сказал, что не надо искать смысла там где его нет, ну и зачем городить бессмыслицу???
Ещё раз повторюсь, есть же сложившиеся понятия, как работает Д-триггер, ну придумали вы что-то похожее, работающее не совсем так, если у животных 4 ноги(лапы) это не значит, что их надо одинаково называть, короче можно назвать как-то иначе, например ДМ-триггер, подчёркивая эти различия в работе, если пользоваться их логикой, так одного слова достаточно в любом языке, что вводит некоторую путаницу на первых порах, капзап, похоже правильно сказал, что не надо искать смысла там где его нет, ну и зачем городить бессмыслицу???
Так д-тригер работает правильно. Абсолютно как настоящий.
А вот цепочка из них работает не так только потому, что цепочка расчитывается "один за другим", а не вся разом.
А один триггер полностью соответствует логике своего "железного" собрата.
Сергей0308
02.08.2017, 16:12
Так д-тригер работает правильно. Абсолютно как настоящий.
А вот цепочка из них работает не так только потому, что цепочка расчитывается "один за другим", а не вся разом.
А один триггер полностью соответствует логике своего "железного" собрата.
Я об этом и говорил, что когда составляешь из Д-триггеров регистр сдвига, это Вы Ситникову растолкуйте, я об этом знаю, он похоже до сих пор не верит!
Так д-тригер работает правильно. Абсолютно как настоящий.
А вот цепочка из них работает не так только потому, что цепочка расчитывается "один за другим", а не вся разом.
А один триггер полностью соответствует логике своего "железного" собрата.
следуя этому, можно сделать вывод, что на одном холсте макроса набросав цепочку д- триггеров нужного количества все будет работать вся схема в целом
Владимир Ситников
02.08.2017, 16:43
Я об этом и говорил, что когда составляешь из Д-триггеров регистр сдвига, это Вы Ситникову растолкуйте, я об этом знаю, он похоже до сих пор не верит!
Можете объяснить чем ОЛ Д-триггер работает неправильно?
Например, в духе: "временная диаграмма Д-триггера должна быть такой-то, а в ОЛ отличается".
Ну так, у Вас же претензии к D-триггеру. Хотя, он сам (триггер) работает как надо. :)
Не как мифический "DM", а как железный D.
А вот, чтобы из нескольких D составить регистр сдвига, тут уже Вам нужно знать разницу между "параллельной" работой "железных" триггерОВ, и их работой в среде ОЛ.
Если бы можно было задать нужный порядок расчёта элементов, то и линия задержки бы не понадобилась. Считай цепочку "с хвоста" (по входам D и С) - и всё.
А потом вторым проходом "с головы" по остальным входам (R и S).
Сергей0308
02.08.2017, 17:14
Можете объяснить чем ОЛ Д-триггер работает неправильно?
Например, в духе: "временная диаграмма Д-триггера должна быть такой-то, а в ОЛ отличается".
Вот проверьте сами, мне смысла нет обманывать, сам столкнулся много лет назад и другие сталкивались, вопросы писали:
32369
32371
Как говорится, почувствуйте разницу!
Вот проверьте сами, мне смысла нет обманывать, сам столкнулся много лет назад и другие сталкивались, вопросы писали:
32369
32371
Как говорится, почувствуйте разницу!
Да причём тут "веришь - не веришь". Я не то что верю, я знаю, что верхняя часть работать не будет.
На входы С сигнал поступает одновременно, а триггеры считаются в порядке "от входа к выходу". То же самое, как если бы сигнал С пришёл вначале на 1 каскад, потом на второй, потом на 3й....
Можно было бы задать порядок расчёта триггеров (хотябы в порядке нумерации расчёт бы шёл), линии задержки не понадобились бы.
Владимир Ситников
02.08.2017, 17:45
Как говорится, почувствуйте разницу!
И?
Какие претензии к D-триггеру?
Триггер работает так же, как и описан D-триггер в Wikipedia.
Если вы пытались построить регистр сдвига на DTRIG и не учли, что все блоки в ОЛ выполняются "мгновенно, без задержек", то это ваши проблемы.
И не нужно насиловать программистов утверждениями "в ОЛ неправильные триггеры".
Всё в ОЛ правильно.
Точно так же можно собрать цепочку из AND-AND-AND-AND блоков и потом спрашивать: "а почему они сразу все вычисляются, хотя в железе последовательно"
Да, в случае с "беззнаковыми целыми" косяк. Но в DTRIG всё норм. Как описано, так работает, а описано так же, как в Wikipedia.
Сергей0308
02.08.2017, 17:46
В том-то и проблема, что господин Ситников критиковал, что я мол без разбору везде где можно линии задержки втыкаю, и что если регистр не закольцовывать всё будет адекватно работать без линий задержки, во всяком случае, я его так понял, может и ошибся!
В реальном железе для создания регистра сдвига соединяют выход Д-триггера с D входом последующего непосредственно, без всяких устройств задержки сигнала
"Именно со следующим и в ОЛ можно соединить простой связью.
Но в вашей схеме есть как минимум 1 цикл, и тут ОЛ резонно требует линию задержки.
То, что вы её воткнули между D-триггерами это лишь ваш выбор. Можно было (и, скорее всего, логичнее было бы) и после них
Можете простой пример сделать на одном-двух-трёх Д-триггерах, на котором было бы видно, что "ОЛ работает не так"?
По-моему, ваш пример с цепочкой Д-триггеров лишь подтверждает то, что ОЛ работает верно (требует задержку), а вы не понимаете смысл этой самой задержки и ставите её куда попало. "
Хорошо что теперь другое говорит!
Если вы пытались построить регистр сдвига на DTRIG и не учли, что все блоки в ОЛ выполняются "мгновенно, без задержек", то это ваши проблемы.
И не нужно насиловать программистов утверждениями "в ОЛ неправильные триггеры".
Всё в ОЛ правильно.
Точно так же можно собрать цепочку из AND-AND-AND-AND блоков и потом спрашивать: "а почему они сразу все вычисляются, хотя в железе последовательно"
Вот как раз наоборот. В железе они работают параллельно, а в ОЛ цепочка "от входа к выходу" считается ПОСЛЕДОВАТЕЛЬНО.
В случае д-триггеров, соединённых последовательно, это означает ЗАДЕРЖКУ расчёта каждого следующего на время расчёта предыдущих. В самом цикле расчёта задержка, обусловленная последовательным расчётом, которой нет и не может быть в железе.
В ОЛ как минимум не учтено, что сам ОЛ может приводить к ситуациям, когда сигнал на д входе и на с входе изменяется ОДНОВРЕМЕННО, что и в железе привело бы к неоднозначной работе триггера.
Решить эту проблему можно не только линией задержки, но и доработав триггер, "привинтив" ему статическое свойство "приоритет входа". Т.е, какой вход обрабатывать первым в случае одновременного изменения уровней на входах.
Но и с линией задержки работает.
Владимир Ситников
02.08.2017, 18:28
В том-то и проблема, что господин Ситников критиковал, что я мол без разбору везде где можно линии задержки втыкаю, и что если регистр не закольцовывать всё будет адекватно работать без линий задержки, во всяком случае, я его так понял, может и ошибся!
Да, действительно писал такие слова:
То, что вы её воткнули между D-триггерами это лишь ваш выбор. Можно было (и, скорее всего, логичнее было бы) и после них
Можете простой пример сделать на одном-двух-трёх Д-триггерах, на котором было бы видно, что "ОЛ работает не так"?
По-моему, ваш пример с цепочкой Д-триггеров лишь подтверждает то, что ОЛ работает верно (требует задержку), а вы не понимаете смысл этой самой задержки и ставите её куда попало.
Да, в словах "ставите куда попало" переборщил.
Да, действительно, если нужен "регистр сдвига из Д-триггеров", то нужны промежуточные линии задержки между DTRIG'ами.
Тем не менее, поведение ОЛ верное и предсказуемое, а все слова "Д-триггер в ОЛ работает неправильно" безосновательны.
Владимир Ситников
02.08.2017, 18:38
К слову: делать задержку бит на Д-триггерах это дичь ещё та. Уже давно было сказано по этому поводу:
19.09.2010, 09:07: за такие "логические выражения" из 15 переменных нещадно бьют в приличных программистских конторах. т.к. 2 в степени 15=32768 - столько комбинаций входных сигналов и внутренних состояний существует у такого выражения. и все надо хотя-бы в уме протестировать. что невозможно в принципе.
а значит такое выражение - просто грядка граблей и багов. 3 переменные и не больше. если больше - переделывай принцип.
Сергей0308
02.08.2017, 18:46
К слову: делать задержку бит на Д-триггерах это дичь ещё та. Уже давно было сказано по этому поводу:
А так нормально?
32372
Владимир Ситников
02.08.2017, 18:58
А так нормально?
32372
Так лучше, но, по-моему, нужно через массивы-очереди делать.
Сергей0308
02.08.2017, 23:04
Да, действительно писал такие слова:
Да, в словах "ставите куда попало" переборщил.
Да, действительно, если нужен "регистр сдвига из Д-триггеров", то нужны промежуточные линии задержки между DTRIG'ами.
Тем не менее, поведение ОЛ верное и предсказуемое, а все слова "Д-триггер в ОЛ работает неправильно" безосновательны.
Мне это сразу напоминает сравнение России и Америки(США): каждый гражданин обычно Кулибин с Менделеевым, все вместе - никчёмная страна(по сравнению с Америкой), каждый гражданин обычно ничего из себя не представляет, все вместе - великая страна!
Владимир Ситников бесполезно что-то объяснять человеку, который вместо паяльника с осцилой сразу лезет в Вики.....
На счет М02, сделайте зажигание на нем для своего авто и запишите видео, тогда разговор будет предметным.
Еще пример, вертикальную и горизонтальную развертки для видеосигнала повторите на ПЛК, если у вас вдруг авто нет.
Владимир Ситников
02.08.2017, 23:57
Мне это сразу напоминает сравнение России и Америки(США): каждый гражданин обычно Кулибин с Менделеевым, все вместе - никчёмная страна(по сравнению с Америкой), каждый гражданин обычно ничего из себя не представляет, все вместе - великая страна!
По делу есть что?
Утверждали-утверждали, что Д-триггер криво работает.
В итоге оказалось, что триггер качественный.
Сергей0308
03.08.2017, 00:10
По делу есть что?
Утверждали-утверждали, что Д-триггер криво работает.
В итоге оказалось, что триггер качественный.
Тут я считаю что это ошибка и надо было такой делать:
32378
И вот приходится опять приводить цитату, Вы вырвали слова из контекста: "И Д-триггеры неверно работают, когда из них регистр сдвига составляешь, без задержки(обратной связи) никак:"
Это первое, что написал по Д-триггеру, дальше уже спор идёт по этому поводу! Ну и что же здесь я неверно указал? Вы же только что сами это подтвердили!
Я согласен, при программной реализации существуют свои особенности, но по факту это так!
Будете против JK-триггера?
https://commons.wikimedia.org/wiki/File:JK_Trigger_Logic.gif
Кстати такие вещи без шаманства в ПР не повторяются, ни в ПР200, ни в Logo ни в Zelio Lodgic, пробовал уже и не только JK триггер.
А в железе оно просто работает как описано.
Сергей0308, как выше писал, примите как данность, что любой ПР(ПЛК) не сможет повторить в чистом виде реальные микросхемы из-за программной реализации и четкого последовательного выполнения команд.
Владимир Ситников
03.08.2017, 09:50
И вот приходится опять приводить цитату, Вы вырвали слова из контекста: "И Д-триггеры неверно работают, когда из них регистр сдвига составляешь, без задержки(обратной связи) никак:"
Это первое, что написал по Д-триггеру, дальше уже спор идёт по этому поводу! Ну и что же здесь я неверно указал? Вы же только что сами это подтвердили!
Именно эта фраза неверная.
Д-триггеры работают верно. Неверно работает регистр сдвига без задержки.
Будете против JK-триггера?
Больше триггеров хороших и разных. Почему нет?
Но по-моему, без пол-литра JK триггер не понять.
Давайте такой вопрос: допустим, у программиста ОЛ находится время на 1 ФБ. И возникает вопрос: "можно сделать ФБ-массив, а можно сделать ФБ-JK-триггер". Какой блок нужнее-полезнее?
Да, JK крутой, но массив по-моему, полезнее, т.к. на массивах можно ого-го чего сделать.
Именно эта фраза неверная.
Д-триггеры работают верно. Неверно работает регистр сдвига без задержки.
Больше триггеров хороших и разных. Почему нет?
Но по-моему, без пол-литра JK триггер не понять.
Давайте такой вопрос: допустим, у программиста ОЛ находится время на 1 ФБ. И возникает вопрос: "можно сделать ФБ-массив, а можно сделать ФБ-JK-триггер". Какой блок нужнее-полезнее?
Да, JK крутой, но массив по-моему, полезнее, т.к. на массивах можно ого-го чего сделать.
Опять Вы каку-то хрень понесли про "последний ФБ программиста" :)
Если в ОЛ нельзя сделать регистр сдвига на D триггерах без линий задержки, то это есть большой глюк самого ОЛ, как и мифическое зацикливание при соединении выхода элемента с его входом.
Если у программистов ОВЕН не получается сделать правильную работу ОЛ, то ненужно подводить сюда теоретическую базу оправдывающую это безобразие.
Если всякие лого, зелио и прочие шнайдеры тоже не могут правильно интерпретировать работу последовательно включенных логических элементов, то и их в топку!
Хорошо, что я сделал когда-то правильный выбор не в сторону лого и зелио
https://www.youtube.com/watch?v=TJz0TUci61s
https://www.youtube.com/watch?v=kWFPglWYoKM
Правда выглядит D trigger необычно, но это он
32394
Если в ОЛ нельзя сделать регистр сдвига на D триггерах без линий задержки, то это есть большой глюк самого ОЛ, как и мифическое зацикливание при соединении выхода элемента с его входом.
Если у программистов ОВЕН не получается сделать правильную работу ОЛ, то ненужно подводить сюда теоретическую базу оправдывающую это безобразие.
Если всякие лого, зелио и прочие шнайдеры тоже не могут правильно интерпретировать работу последовательно включенных логических элементов, то и их в топку!
Хорошо, что я сделал когда-то правильный выбор не в сторону лого и зелио
https://www.youtube.com/watch?v=TJz0TUci61s
https://www.youtube.com/watch?v=kWFPglWYoKM
Правда выглядит D trigger необычно, но это он
32394
Нет. Судя по описанию это не он :).
Это "Ванга-триггер" какой-то, если в нём что-то происходит "непосредственно перед тем, как входы изменят своё состояние" :)
Представляю что он там наванговать может :)
Нет. Судя по описанию это не он :).
Это "Ванга-триггер" какой-то, если в нём что-то происходит "непосредственно перед тем, как входы изменят своё состояние" :)
Представляю что он там наванговать может :)
Это классический D триггер. Просто переводчик узкоглазый, а английскую версию среды я не устанавливал.
Это классический D триггер. Просто переводчик узкоглазый, а английскую версию среды я не устанавливал.
Классический д-триггер записывает на выход состояние д-входа в момент фронта сигнала с.
А не "непосредственно перед", что без Ванги невозможно. А кто уж там "узкоглазый" - Вам виднее.
Сергей0308
03.08.2017, 13:26
Классический д-триггер записывает на выход состояние д-входа в момент фронта сигнала с.
А не "непосредственно перед", что без Ванги невозможно. А кто уж там "узкоглазый" - Вам виднее.
Тогда что обозначает треугольник, бывает наклонная линия на входе С ??? И они могут быть направленны по-разному!
32399
Тогда что обозначает треугольник, бывает наклонная линия на входе С ??? И они могут быть направленны по-разному!
32399
ГОСТ 2.743-91 Единая система конструкторской документации (ЕСКД). Обозначения условные графические в схемах. Элементы цифровой техники.
Найдите ошибку в Вашей картинке. ;)
ГОСТ 2.743-91 Единая система конструкторской документации (ЕСКД). Обозначения условные графические в схемах. Элементы цифровой техники.
Найдите ошибку в Вашей картинке. ;)
Так в РФ госты отменили давно:rolleyes: Рисуй, что хочешь, никакого ЕСКД!
Лафа!!!
32400
Проверил в ОЛ, судя по всему в штатном D-Trigg нет контроля фронта сигнала по входу С, тупо наличие 1 видит и привет, врубаются сразу все 3 а должен был как у petera сработать только первый.
Сергей0308, либо фронт сигнала либо спад (спад может не треугольником отмечаться а как-то иначе)
Василий Кашуба
03.08.2017, 14:12
Значит, в штатном D-Trigg по входу С нужно установить R_TRIG, чтобы стало как и должно быть.
Проверил в ОЛ, судя по всему в штатном D-Trigg нет контроля фронта сигнала по входу С, тупо наличие 1 видит и привет, врубаются сразу все 3 а должен был как у petera сработать только первый.
Сергей0308, либо фронт сигнала либо спад (спад может не треугольником отмечаться а как-то иначе)
Так из-за этого и весь сыр-бор разгорелся:rolleyes:
Тут уже теорию подвели грамотные специалисты, что ОБЯЗАТЕЛЬНО нужно вставлять линии задержки между выходом предыдущего и входом последующего. Мол так нужно, типа без этого невозможно чего-то там просчитать.
ЗЫ
Фронт "/"
Спад "обратный слеш"
ХА, сейчас сделал после выхода Д-триггера в схеме petera на каждый следующий линию задержки и что бы вы думали ?
при 1 на Д первого при включении С срабатывают первые 2, при следующем срабатывает третий. А вот обратное выключение работает по очереди.
КОСЯК...
Правильно работает только при R-trig общем для всех С и обратных связях с выхода на вход Д следующего.
Глюк, убрал R-trig, оставил обратные связи, тоже правильно работает, как так ? то 2 первых включало а теперь нормально все 3 включаются ?
ХА, сейчас сделал после выхода Д-триггера в схеме petera на каждый следующий линию задержки и что бы вы думали ?
при 1 на Д первого при включении С срабатывают первые 2, при следующем срабатывает третий. А вот обратное выключение работает по очереди.
КОСЯК...
Значит "по теории", которую тут втюхивают, нужно две(три?) последовательные лини задержки вставлять
http://www.owen.ru/forum/attachment.php?attachmentid=11957&d=1392751157
Классический д-триггер записывает на выход состояние д-входа в момент фронта сигнала с.
А не "непосредственно перед", что без Ванги невозможно. А кто уж там "узкоглазый" - Вам виднее.
....Правильно работает только при R-trig общем для всех С и обратных связях с выхода на вход Д следующего.
Похоже, что Ванги триггер это триггер из ОЛ!!!
Владимир Ситников
03.08.2017, 14:51
Значит "по теории", которую тут втюхивают, нужно две(три?) последовательные лини задержки вставлять
Ох уж эти "24 года", которым лишь бы поболтать.
petera, при всём уважении, тут вы ведёте себя крайне странно.
Во-первых, тупо игнорируете объяснения и примеры того, почему "нельзя просто взять и замкнуть выход на вход".
Вместо этого показываете примеры программ со словами "так вот же, работает без всяких линий задержки".
Студенту ещё простительно такие слова, но адекватный человек должен хотя бы попробовать осознать проблему.
Вы же просто зарываетесь в песок со словами: "В моей любимой программе работает, значит она правильная, а ОЛ говно".
Во-вторых, стало очевидно, что melky мало что понимает в ОЛ. Да, возможно, он на раз клепает ОЛ схемы, возможно, он на раз пуско-налаживает (или что там ещё), но именно в FBD-программировании он не разбирается.
Тут нужно заметить, заслуга ОВЕН в том, что у народа получается клепать схемы, и при этом не понимать как оно работает.
Тем не менее, "24 года деятельности" и идём на поводу у того, кто заведомо не понимает, и не подкрепляет свои слова версиями, скриншотами, видео? Крайне странное поведение.
И, да, лучше бы сообщали в ОВЕН о реальных проблемах (http://www.owen.ru/forum/showthread.php?t=25870&p=254263&viewfull=1#post254263), а не разглагольствовали о мифических проблемах с Д-триггерами.
Классический д-триггер записывает...
Вы сильно удивитесь, но в ПО Альфы действительно классический Д-триггер, работающий именно так, как меня учили в школе. Правда, УГО необычное, и перевод кривоват, ну так механизмом ведь не УГО управляет...
Владимир Ситников в ОЛ нет как в CDS указать "Порядок -> в соответствии с потоком данных", расставлять самому можно, но муторно и неграмотно со стороны разработчиков, так как заявлено что выполняется все слева направо и сверху вниз, вроде как в CDS но почему-то хромает.
Вероятно отсюда и непонятные глюки вроде при одной и той же схеме.
Опять же, я приводил схему JK-триггера - попробуйте ее в ОЛ сделать. не пользую версию 1.9, не хватало мне сейчас новых глюков....
Просто интересно, как будет ругаться версия 1.9 на такое художество...
Владимир Ситников в ОЛ нет как в CDS указать "Порядок -> в соответствии с потоком данных", расставлять самому можно, но муторно и неграмотно со стороны разработчиков, так как заявлено что выполняется все слева направо и сверху вниз, вроде как в CDS но почему-то хромает.
Вероятно отсюда и непонятные глюки вроде при одной и той же схеме.
Опять же, я приводил схему JK-триггера - попробуйте ее в ОЛ сделать. не пользую версию 1.9, не хватало мне сейчас новых глюков....
Просто интересно, как будет ругаться версия 1.9 на такое художество...
такой что ли ?
capzap ща посмотрю, может быть и он. Я в ссылке давал рисунок JK триггера, как он соответствует железячному.
немного не соответствует работе, но в целом более менее. При разных значениях J и K он должен устанавливать в 1 или сбрасывать выход по спаду, а не по фронту сигнала.
Если J и K = 1 тогда должен менять состояние по фронту (тут четко работает)
Во-первых, тупо игнорируете объяснения и примеры того, почему "нельзя просто взять и замкнуть выход на вход".
Вместо этого показываете примеры программ со словами "так вот же, работает без всяких линий задержки".
Студенту ещё простительно такие слова, но адекватный человек должен хотя бы попробовать осознать проблему.
Вы же просто зарываетесь в песок со словами: "В моей любимой программе работает, значит она правильная, а ОЛ говно".
Владимир это Вы меня удивляете
Убеждая, что если выход элемента соединить со входом, то это КАТЕГОРИЧЕСКИ не будет работать, никогда и ни где.
http://www.owen.ru/forum/attachment.php?attachmentid=32403&d=1501764156
ПО для AL2 не моя любимая программа, просто вместо пространных умозаключений о том, что связь выхода со входом элемента работать не может и D триггеры нельзя соединять без линий задержки я привожу ФАКТЫ в виде скриншотов и видио.
Лучше один раз увидеть, что это действительно может работать, чем сто раз услышать (прочитать), что это сделать нельзя, потому, что нельзя и все тут.
Короче это вся рота идет не в ногу, а не ОЛ.
Я ничего против ОЛ не имею, просто буду учитывать нестандартные реализации очевидных вещей, о которых я, при работе в другой среде разработки даже и не задумывался.
capzap ща посмотрю, может быть и он. Я в ссылке давал рисунок JK триггера, как он соответствует железячному.
и что там смотреть, можно подумать что Хьюго и сообщество понятия не имеют как работают триггеры
Так в РФ госты отменили давно:rolleyes: Рисуй, что хочешь, никакого ЕСКД!
Лафа!!!
32400
Так это... И мыть руки перед едой - это тоже "на добровольной основе".
Рисуй как хочешь, но когда обосрёшься (извиняюсь за свой французский), то потом не жалуйся. :)
Так это... И мыть руки перед едой - это тоже "на добровольной основе".
Рисуй как хочешь, но когда обосрёшься (извиняюсь за свой французский), то потом не жалуйся. :)
Это в РФ, можно и как хочешь и по французски.
В Белоруссии отступление от гостов как и положено карается по закону. У нас просто не смогли до такой глупости додуматься.
Придет Гостандарт, мало не покажется.
Владимир Ситников
03.08.2017, 16:26
Владимир это Вы меня удивляете
Убеждая, что если выход элемента соединить со входом, то это КАТЕГОРИЧЕСКИ не будет работать, никогда и ни где.
Цитату в студию.
Следите за своими словами, и не надо приписывать мне того, чего я не говорил. Не говорил я, что "самозамкнутый элемент не будет работать".
триггеры нельзя соединять без линий задержки я привожу ФАКТЫ в виде скриншотов и видио
И? Я где-то говорил, что "в КДС невозможно замкнуть выход на вход"? Я где-то говорил, что при этом ПЛК взорвётся? А? Давайте же. Вы же опытный инженер.
Теперь, предлагаю вам перевести дух, выключить эмоции, включить мозг и ещё раз перечитать вот это сообщение:
Разумеется, вся проблема именно в неопределённости того, в каком порядке должны выполняться элементы на схеме.
Как многие знают, проблема "порядка выполнения блоков" в КДС "решена" тем, что пользователю самому предлагают нумеровать блоки.
Решение? Да, какое-то решение. Кто-то даже и не задумывается, что "вообще можно указать порядок выполнения". А кто-то набивает шишки. Делает схему, а она работает косо.
Так вот: в ОЛ подход к этой проблеме простой. Блоки выполняются в порядке от входов к выходам.
Иными словами, если есть цепочка вход--AND--OR--выход, то OR выполнится только после того, как выполнится AND.
И в этом есть огромный плюс: пользователям не нужно вручную расставлять порядок выполнения. Как составил схему, так и работает. Это офигенный плюс.
Но есть и нюанс: при таком подходе нельзя делать циклы (замыкать выход на вход), и нужно делать явные линии задержки.
В явном указании линий задержки есть огромный плюс: пользователь видит в каких частях схемы используются "новые", а в каких "старые" данные. В КДС для этого нужно нужно крайне аккуратно следить за последовательностью выполнения элементов.
Лучше один раз увидеть, что это действительно может работать
Вам что, показать пример, где ваша любимая среда покажет кривой результат?
Например, покажу, что "две линии, выходящие из одного и того же места по факту принимают разный результат". Как вы это будете объяснять?
То, что в какой-то среде может работать регистр сдвига "без линий задержки" ни о чём не говорит. Есть фундаментальная проблема -- каким-то образом должно быть обговорено в каком порядке выполняются элементы. Так вот: обсуждать нужно не один конкретный пример в конкретной среде, а общий подход.
Если готовы обсуждать общий подход -- не вопрос. Я уже вопросы общего характера задавал (http://www.owen.ru/forum/showthread.php?t=26787&page=5&p=254116&viewfull=1#post254116), но вы их просто игнорируете.
Всё нормально с д-триггером в ОЛ.
Если вы "железному" д-тригеру ОДНОВРЕМЕННО измените два входа (с и д), то на выходе получите что угодно.
Второй д-тригер в ол работает именно так. К моменту его обсчёта, вход д уже изменён выходом первого д-триггера, и учесть изменение на входе с он никак не может до того, как программа его начнёт считать. Линия задержки прекрасно "придерживает" предыдущее значение на входе на 1 цикл, при этом, никаких побочных явлений (задержек сигналов на выходах) нет.
Обсуждать абсолютно нечего.
Это в РФ, можно и как хочешь и по французски.
В Белоруссии отступление от гостов как и положено карается по закону. У нас просто не смогли до такой глупости додуматься.
Придет Гостандарт, мало не покажется.
Правда чтоли? Вся белорусская продукция по ГОСТу? ТУ запрещены законодательно?
Ерунду не пишите!
Владимир Ситников
03.08.2017, 16:35
Всё нормально с д-триггером в ОЛ.
Если вы "железному" д-тригеру ОДНОВРЕМЕННО измените два входа (с и д), то на выходе получите что угодно.
Второй д-тригер в ол работает именно так. К моменту его обсчёта, вход д уже изменён выходом первого д-триггера, и учесть изменение на входе с он никак не может до того, как программа его начнёт считать. Линия задержки прекрасно "придерживает" предыдущее значение на входе на 1 цикл, при этом, никаких побочных явлений (задержек сигналов на выходах) нет.
^^^ всё так
Обсуждать абсолютно нечего.
На самом деле, есть что обсуждать.
Как оказалось, если попытаться сделать "свой макрос SUPERDTRIGGER", в котором простой ОЛ DTRIG и линия задержки на выходе (ну, чтобы эстеты могли делать "регистр сдвига на SUPERDTRIGGER'ах на простых связях"), то такое не сработает.
Это поведение ОЛ, по-моему, является багом (http://www.owen.ru/forum/showthread.php?t=25870&p=254263&viewfull=1#post254263).
Правда чтоли? Вся белорусская продукция по ГОСТу? ТУ запрещены законодательно?
Ерунду не пишите!
Причем здесь продукция по ТУ.
Я Вам про тот же ЕСКД расскажу.
По условиям деятельности приходится каждые два года подтверждать выполнение лицензионных требований. Эксперту Госпромнадзора нужно предъявлять не только наличие фонда ГОСТов на предприятии, но договор на информационное обслуживание с БелГИСС, наличие ИУС с изменениями ГОСТ, картотеку с отметками о проведенных изменениях в фонде ГОСТов.
А Вы говорите ерунда.
Так вот: в ОЛ подход к этой проблеме простой. Блоки выполняются в порядке от входов к выходам.
Иными словами, если есть цепочка вход--AND--OR--выход, то OR выполнится только после того, как выполнится AND.
И в этом есть огромный плюс: пользователям не нужно вручную расставлять порядок выполнения. Как составил схему, так и работает. Это офигенный плюс.
Но есть и нюанс: при таком подходе нельзя делать циклы (замыкать выход на вход), и нужно делать явные линии задержки.
В явном указании линий задержки есть огромный плюс: пользователь видит в каких частях схемы используются "новые", а в каких "старые" данные. В КДС для этого нужно нужно крайне аккуратно следить за последовательностью выполнения элементов.
На самом деле, никаких проблем с концепцией ОЛ нет.
И выходы на входы замыкать можно без проблем.
Проблема возникает только с элементами (ФБ) , имеющими динамические входы. Можно вообще отказаться от "линий задержки", и неявно, в самих ФБ с динамическими входами хранить предыдущее состояние статических входов, влияющих на обработку динамического входа.
Будет схема работать "как железная" без ЛЗ вообще, но это на каждый такой статический вход лишняя статичесаая переменная в цикле. Т.е., явно не оптимально с т.з. использования ресурсов ПР.
Когда-то это нужно, а когда-то нет. Вот программисту-рисовальщику схем и дали в руки "линию задержки" (по сути, такую же статическую переменную, хранящую состояние входа, к которому она подключена с прошлого цикла), чтобы он её применял там, где необходимо. Нужна - выделяется статическая переменная, жрущая память. Не нужна - не выделяется - больше свободной памяти.
Владимир Ситников
03.08.2017, 17:03
И выходы на входы замыкать можно без проблем.
Проблема возникает только с элементами (ФБ) , имеющими динамические входы
Да что же такое?
Специально приводил пример с одним-единственным AND квадратиком (http://www.owen.ru/forum/showthread.php?t=26787&p=248608&viewfull=1#post248608).
На этом простом примере уже возникает неоднозначность.
^^^ всё так
На самом деле, есть что обсуждать.
Как оказалось, если попытаться сделать "свой макрос SUPERDTRIGGER", в котором простой ОЛ DTRIG и линия задержки на выходе (ну, чтобы эстеты могли делать "регистр сдвига на SUPERDTRIGGER'ах на простых связях"), то такое не сработает.
Это поведение ОЛ, по-моему, является багом (http://www.owen.ru/forum/showthread.php?t=25870&p=254263&viewfull=1#post254263).
Только неумный человек будет ставить ЛЗ на ВЫХОД, пытаясь добиться правильной работы д-триггера.
Проблема не в выходах, а во входах, которые иногда должны помнить своё прошлое состояние, чтобы правильно посчитать выход.
Попробуйте прицепить связь на вход более чем одного ФБ. ;)
Владимир Ситников
03.08.2017, 17:08
Только неумный человек будет ставить ЛЗ на ВЫХОД, пытаясь добиться правильной работы д-триггера.
Проблема не в выходах, а во входах, которые иногда должны помнить своё прошлое состояние, чтобы правильно посчитать выход.
Попробуйте прицепить связь на вход более чем одного ФБ. ;)
Без разницы. На вход нужно цеплять или на выход -- не задумывался. Я просто пример с NOT нарисовал и понял, что в ОЛ косяк.
Как работает Д-триггер меня меньше всего волнует.
То, что ОЛ не воспринимает линию задержки в макросах -- реальная проблема.
Да что же такое?
Специально приводил пример с одним-единственным AND квадратиком (http://www.owen.ru/forum/showthread.php?t=26787&p=248608&viewfull=1#post248608).
На этом простом примере уже возникает неоднозначность.
Нет никакой неоднозначности, если соблюдать строгое правило - расчёт от входа к выходу. Всё упирается в обнаружение такой связи и назначение статической переменной для хранения её состояния с прошлого цикла. Что и было ещё до того, как ввели обязательную "обратную связь". Среда брала на себя обнаружение таких мест, и делала всё за "программиста"-рисовальщика. Теперь стало ясно, что не всегда она это может сделать сама, ввели ЛЗ. Только и всего.
Без разницы. На вход нужно цеплять или на выход -- не задумывался. Я просто пример с NOT нарисовал и понял, что в ОЛ косяк.
Как работает Д-триггер меня меньше всего волнует.
То, что ОЛ не воспринимает линию задержки в макросах -- реальная проблема.
Как это не воспринимает? Не сталкивался с такой проблемой.
Владимир Ситников
03.08.2017, 17:17
Как это не воспринимает? Не сталкивался с такой проблемой.
Посмотрите пример тут: http://www.owen.ru/forum/showthread.php?t=25870&page=31&p=254263&viewfull=1#post254263
Детально же расписано ожидаемое и фактическое поведение.
Причем здесь продукция по ТУ.
Я Вам про тот же ЕСКД расскажу.
По условиям деятельности приходится каждые два года подтверждать выполнение лицензионных требований. Эксперту Госпромнадзора нужно предъявлять не только наличие фонда ГОСТов на предприятии, но договор на информационное обслуживание с БелГИСС, наличие ИУС с изменениями ГОСТ, картотеку с отметками о проведенных изменениях в фонде ГОСТов.
А Вы говорите ерунда.
А причём тут "обязательность ГОСТов"?
Вы добровольно лицензировались? Если условия лицензии содержат требования выполнять ГОСТ, то обязаны их выполнять.
Никто никому не запрещает работать без ГОСТа. Для этого и существуют ТУ. А вот везде ли Вас пустят с ТУ вместо ГОСТа - это отдельная песня. И прилепить на своё изделие, выпущеное по ТУ, "ГОСТ...." - это преступление и в Белорусии, и в РФ.
А кроме ГОСТов есть ещё и куча ТР, чьё исполнение так же добровольное, как и сертификация/лицензирование. Но без этих лицензий/сертификатов/ТР просто не пустят на конкретный рынок.
Так что, ерунду Вы пишите про "обязательность ГОСТов". Не хотите - не соблюдайте, и не ходите за лицензиями на "табличку "сделано по ГОСТ"". Пишите свои ТУ хоть по-французки, хоть матерно и продавайте свою продукцию туда, где это купят.
Сергей0308
03.08.2017, 17:29
Посмотрите пример тут: http://www.owen.ru/forum/showthread.php?t=25870&page=31&p=254263&viewfull=1#post254263
Детально же расписано ожидаемое и фактическое поведение.
Владимир, если можно один нескромный вопрос не по теме, а мне что сделать, чтобы ссылка сразу открывалась на нужном посте и не надо было прокручивать страницу, браузер поменять или мозг?
Владимир Ситников
03.08.2017, 17:31
Владимир, если можно один нескромный вопрос не по теме, а мне что сделать, чтобы ссылка сразу открывалась на нужном посте и не надо было прокручивать страницу, браузер поменять или мозг?
Без понятия. У меня в Google Chrome работает.
Я говорю про этот пост:
Попробовал как ОЛ 1.9 реагирует на линии задержки, расположенные в макросах.
Оказалось -- никак, что огорчает.
Для теста достаточно простого макроса: "вход ==> NOT --линия-задержки--> выход"
32393
На основном холсте замыкаю выход на вход этого макроса, и ОЛ начинает паниковать, что "у вас цикл-цикл!".
Хотя, по-факту, цикла-то нет. Линия задержки-то есть (она внутри макроса), всё как положено.
32391
...
pop70 - по буквам, если на вход С Д-триггера пришел сигнал РАНЬШЕ, чем на вход Д, состояние его поменяться не должно. То есть на входе Д уже должна быть единица, чтобы фронт сигнала на С передал ее на выход. то есть работать должен ТОЛЬКО момент фронта сигнала...
Один Д триггер работает правильно, ну он один и есть. а два уже нет. Так как заявления разработчиков о том, что все элементы выполняются последовательно согласно расстановке на схеме не соответствуют действительности Оба Д триггера определяют фронт одновременно, но у второго триггера по отношению к первому должна быть задержка сигнала на входе Д, так как сперва должен отработать первый и только потом второй элемент, а они почему-то разом это делают, на железе кто-нить проверял ?
pop70 - по буквам, если на вход С Д-триггера пришел сигнал РАНЬШЕ, чем на вход Д, состояние его поменяться не должно. То есть на входе Д уже должна быть единица, чтобы фронт сигнала на С передал ее на выход. то есть работать должен ТОЛЬКО момент фронта сигнала...
Один Д триггер работает правильно, ну он один и есть. а два уже нет. Так как заявления разработчиков о том, что все элементы выполняются последовательно согласно расстановке на схеме не соответствуют действительности Оба Д триггера определяют фронт одновременно, но у второго триггера по отношению к первому должна быть задержка сигнала на входе Д, так как сперва должен отработать первый и только потом второй элемент, а они почему-то разом это делают, на железе кто-нить проверял ?
о, кажется мелкий всё же взглянул на эпюры входов/выходов триггера, жаль правда не обратил внимание на генератор импульсов, который в схемах нужно не спомощью TON-а делать(импульс на один цикл), а используя блинк с периодом больше чем цикл ПР, возможно и связка D-FF будет работать
Посмотрите пример тут: http://www.owen.ru/forum/showthread.php?t=25870&page=31&p=254263&viewfull=1#post254263
Детально же расписано ожидаемое и фактическое поведение.
Ну так, я же Вам чёрным по белому писал, что ЛЗ - это не для выхода, а для входа.
А в схеме, ОЛ понятия не имеет о линии задержки внутри макроса. Он делает "трассировку" того, что видит. Макрос для него - такой же элемент, как любой ФБ.
Забейте на предупреждение и запустите со связью вместо ЛЗ и увидите, что линия задержки в макросе прекрасно работает.
capzap не смотрел эпюры, просто знаю как он работает и читал заявления разработчиков что в ОЛ схема работает согласно расстановке на холсте (как впрочеми во многих других программах такого рода), что получается не соответствует действительности, потому что цепочка Д триггеров срабатывает одновременно, чего быть не должно, так что тут Сергей308 прав.
capzap не смотрел эпюры, просто знаю как он работает и читал заявления разработчиков что в ОЛ схема работает согласно расстановке на холсте (как впрочеми во многих других программах такого рода), что получается не соответствует действительности, потому что цепочка Д триггеров срабатывает одновременно, чего быть не должно, так что тут Сергей308 прав.
еще раз повторю, на его картике нарисован генератор на основе TON, а нужен BLINK. Просто если уж все знают так хорошо как устроен триггер, то почему все решили что он должен срабатывать за один цикл ПР, он работает от синхроимпульсов, увеличите их и вся связка триггеров успеет сформировать нужные сигналы, разве не так, только все уперлись в линию задержки
Владимир Ситников
03.08.2017, 17:52
А в схеме, ОЛ понятия не имеет о линии задержки внутри макроса. Он делает "трассировку" того, что видит. Макрос для него - такой же элемент, как любой ФБ.
В этом и есть баг. Как раз ОЛ вполне могло бы смотреть на фактический состав макроса.
pop70 - по буквам, если на вход С Д-триггера пришел сигнал РАНЬШЕ, чем на вход Д, состояние его поменяться не должно. То есть на входе Д уже должна быть единица, чтобы фронт сигнала на С передал ее на выход. то есть работать должен ТОЛЬКО момент фронта сигнала...
Один Д триггер работает правильно, ну он один и есть. а два уже нет. Так как заявления разработчиков о том, что все элементы выполняются последовательно согласно расстановке на схеме не соответствуют действительности Оба Д триггера определяют фронт одновременно, но у второго триггера по отношению к первому должна быть задержка сигнала на входе Д, так как сперва должен отработать первый и только потом второй элемент, а они почему-то разом это делают, на железе кто-нить проверял ?
Ещё раз русским по форуму объясняю. На вход с сигнал "приходит" тогда, когда ПР(ОЛ) начинает считать конкретный триггер. А считать второй, ПР (ОЛ) начинает после того, как посчитает первый! Строго в соответствии с заявлением "расчёт ведётся последовательно от входа к выходу". Т.е., к этому моменту на д УЖЕ 1 (то, что на выходе УЖЕ ПОСЧИТАННОГО ПЕРВОГО)! Отсюда такое поведение. Чтобы этого избежать, состояния входов д всех триггеров нужно "заморозить" в состоянии прошлого цикла. Именно это делает ЛЗ.
В этом и есть баг. Как раз ОЛ вполне могло бы смотреть на фактический состав макроса.
Зачем? Каждый раз перекомпилировать блок, который уже скомпилирован?
Макрос - это уже не "набор логики с паутиной связей", а готовый блок-подпрограмма/процедура/функция.
Важно, что ЛЗ в макросе никуда не потерялась. Она работает. Хоть и использована неправильно.
pop70, блин, когда первый посчитал, на входе с второго ДАВНО 1, то есть "поезд" фронт сигнала прошел. а в ОЛ они почему то выполнились одновременно.
pop70, блин, когда первый посчитал, на входе с второго ДАВНО 1, то есть "поезд" фронт сигнала прошел. а в ОЛ они почему то выполнились одновременно.
Так, потому, что никто не умеет писать программы, работающие параллельно.
Триггеры обсчитываются ОДИН ЗА ДРУГИМ.
ОЛ смотрит твою схему и составляет себе "план действий":
1. Считать состояния входов ПР.
2. Посчитать триггер1
3. Посчитать триггер2
4. Посчитать триггер3
.....
nn. Записать выходы ПР.
Попробуйте написать ему задание, чтобы все триггеры считались одновременно. :)
еще раз повторю, на его картике нарисован генератор на основе TON, а нужен BLINK. Просто если уж все знают так хорошо как устроен триггер, то почему все решили что он должен срабатывать за один цикл ПР, он работает от синхроимпульсов, увеличите их и вся связка триггеров успеет сформировать нужные сигналы, разве не так, только все уперлись в линию задержки
Потому, что вся связка д-триггеров должна отработать по одному-единственному ФРОНТУ на входах с, за один-таки цикл. Иначе, это не д-триггер!
pop70, блин, когда первый посчитал, на входе с второго ДАВНО 1
Во время расчёта одного цикла, нет "давно". От начала цикла, до его конца "времени нет". "Давно" - это прошлый цикл.
Это в "железе" время идёт непрерывно, а в программе
"Время остановилось", считались входы, посчиталась программа цикла, записались выходы, "время прыгнуло вперёд на 1 цикл". :)
Потому, что вся связка д-триггеров должна отработать по одному-единственному ФРОНТУ на входах с, за один-таки цикл. Иначе, это не д-триггер!
да ладно, в железе есть фронт, может быть он всегда упоминается с определением нарастающий, нет?
Вот эпюра (http://hyperphysics.phy-astr.gsu.edu/hbase/Electronic/ietron/dflipflop5.gif), самая первая сработка выхода, как раз случай когда генератор имеет логическую единицу, а D-вход подошел с "опозданием", выход сработает, а по Вашему должен пропустить подъем потому что фронт не "словил"
Владимир Ситников
03.08.2017, 19:00
Зачем? Каждый раз перекомпилировать блок, который уже скомпилирован?
Ну, wal79 утверждал, что ОЛ и так перекомпилирует схему на каждый чих.
Тем не менее, для анализа "наличия циклических" связей не обязательно учитывать все-все-все связи внутри макроса.
Достаточно один раз его скомпилировать и понять между какими входами и выходами есть цепочки связей, исключая линии задержки.
Т.е. процесс перекомпиляции может быть быстрым и инкрементальным.
Хоть и использована неправильно.
Это уже не вам судить. Хочу -- ставлю задержку. Говорить "неправильно" без конкретной решаемой задачи "неправильно".
да ладно, в железе есть фронт, может быть он всегда упоминается с определением нарастающий, нет?
Вот эпюра (http://hyperphysics.phy-astr.gsu.edu/hbase/Electronic/ietron/dflipflop5.gif), самая первая сработка выхода, как раз случай когда генератор имеет логическую единицу, а D-вход подошел с "опозданием", выход сработает, а по Вашему должен пропустить подъем потому что фронт не "словил"
Эта эпюра не имеет никакого отношения к д-триггеру.
И да! Вход С "настоящего" д-триггера - динамический. Т.е., активен в момент перехода сигнала с 0 на 1 (или с 1 на 0 в случае инверсного входа)
P.S.
Кстати, да. Я был не прав. Бывает д-триггер со статическим входом С.
Мы какой обсуждаем?
Судя по эпюрам из справки ОЛ - динамический.
Эта эпюра не имеет никакого отношения к д-триггеру.
а так тоже не он
Ну, wal79 утверждал, что ОЛ и так перекомпилирует схему на каждый чих.
Тем не менее, для анализа "наличия циклических" связей не обязательно учитывать все-все-все связи внутри макроса.
Достаточно один раз его скомпилировать и понять между какими входами и выходами есть цепочки связей, исключая линии задержки.
Т.е. процесс перекомпиляции может быть быстрым и инкрементальным.
Это уже не вам судить. Хочу -- ставлю задержку. Говорить "неправильно" без конкретной решаемой задачи "неправильно".
Перекомпилирует схему, а не все её составляющие.
Вас напрягает предупреждение, которое можно игнорировать, если знаешь что делаешь?
"Не правильно" с точки зрения идеи "линии задержки" как "значение входа в прошлом цикле".
В схеме больше, чем один вход на конец ЛЗ не поставишь.
Кстати, попал на один косяк в работе ЛЗ.
В макросе CTMAX.
В чём дело - хз. Повторить не могу. И в программе, и в новом макросе работает. А в том пришлось константу делать 0 и вставлять инвертор - тогда всё работает.
Владимир Ситников
03.08.2017, 19:32
Перекомпилирует схему, а не все её составляющие.
И? Я же говорил, что перекомпилировать макросы (если они не менялись) не обязательно.
Вас напрягает предупреждение, которое можно игнорировать, если знаешь что делаешь?
Меня напрягает то, что ОЛ вставляет лишнюю задержку при "самозамыкании макроса, который внутри уже содержит задержку".
По-моему, лишней задержки добавляться не должно.
"Не правильно" с точки зрения идеи "линии задержки" как "значение входа в прошлом цикле".
А вдруг я реально хочу, чтобы у меня блок выдавал "отрицание того, что было на прошлом цикле"?
Не пойму чего тут неправильного с точки зрения "линии задержки".
а так тоже не он
Тоже не он. Это всё, о чём Вы пишете - статический Д-триггер.
А на картинке вход обозначен динамическим.
Такой лажи в и-нете можно полно найти.
"Неверь глазам своим"(с). Даже если врут по-английски :)
Василий Кашуба
03.08.2017, 19:40
Перекомпилирует схему, а не все её составляющие.
Вас напрягает предупреждение, которое можно игнорировать, если знаешь что делаешь?
"Не правильно" с точки зрения идеи "линии задержки" как "значение входа в прошлом цикле".
В схеме больше, чем один вход на конец ЛЗ не поставишь.
Кстати, попал на один косяк в работе ЛЗ.
В макросе CTMAX.
В чём дело - хз. Повторить не могу. И в программе, и в новом макросе работает. А в том пришлось константу делать 0 и вставлять инвертор - тогда всё работает.
А поменяйте связи на входах местами и схема заработает.
И? Я же говорил, что перекомпилировать макросы (если они не менялись) не обязательно.
Меня напрягает то, что ОЛ вставляет лишнюю задержку при "самозамыкании макроса, который внутри уже содержит задержку".
По-моему, лишней задержки добавляться не должно.
А вдруг я реально хочу, чтобы у меня блок выдавал "отрицание того, что было на прошлом цикле"?
Не пойму чего тут неправильного с точки зрения "линии задержки".
ОЛ ничего не добавляет. Он говорит программисту, что обнаружил сомнительное место. Можешь его тупо послушаться, если плохо понимаешь что делаешь, а можешь оставить как есть.
Отрицание того, что было в прошлом цикле, это ЛЗ+NOT (NOT(вчера)), а не NOT+ЛЗ (Завтра(NOT(???))
Сравните результат при запуске
А поменяйте связи на входах местами и схема заработает.
Угу. Почему-то :)
Вот это - баг.
Владимир Ситников
03.08.2017, 20:06
ОЛ ничего не добавляет.
Вот видеозапись: http://recordit.co/EjrZEKJELy (это же видео в виде анимированного gif: http://g.recordit.co/EjrZEKJELy.gif )
Макрос NOTD это вход ==> NOT =задержка=> выход
Очевидно, что вариант "макрос" и "вне макроса" выдают разный ответ.
Отрицание того, что было в прошлом цикле, это ЛЗ+NOT (NOT(вчера)), а не NOT+ЛЗ (Завтра(NOT(???))
Ой, неужели вас так вводит в ступор линия задержки на выходе?
Да пёс с ней. Могу сделать такой же пример с задержкой по входу:
http://recordit.co/D78FxgJAtw (оно же http://g.recordit.co/D78FxgJAtw.gif )
Результат всё равно один и тот же: вариант с "макросом" требует двух циклов на переключение состояния, а точно такой же вариант (но без макроса) переключается на каждом цикле. Отсюда вывод: в варианте с макросом ОЛ добавляет лишнюю задержку. Иначе как ещё объяснить то, что период генератора меняется?
И? Я же говорил, что перекомпилировать макросы (если они не менялись) не обязательн.
Вы же хотите, чтобы, при анализе схемы, она анализировалась на наличие циклов без ЛЗ?
А для этого, придётся макрос вставлять в схему в развёрнутом виде, и заново просчитывать всё дерево связей.
У Вас полцикла в макросе, а полцикла снаружи. Как проверить на ЛЗ внутри, не развернув и не "перекомпилировав" дерево проекта с развёрнутым макросом?
Василий Кашуба
03.08.2017, 20:20
Угу. Почему-то :)
Вот это - баг.
Это не баг. Первым обрабатывается верхний вход, а нижний вторым.
Владимир Ситников
03.08.2017, 20:25
Вы же хотите, чтобы, при анализе схемы, она анализировалась на наличие циклов без ЛЗ?
А для этого, придётся макрос вставлять в схему в развёрнутом виде, и заново просчитывать всё дерево связей.
У Вас полцикла в макросе, а полцикла снаружи. Как проверить на ЛЗ внутри, не развернув и не "перекомпилировав" дерево проекта с развёрнутым макросом?
Вопрос хороший и он тесно пересекается с вопросом "а как вообще должны вычисляться значения выходов".
Как вам такой вариант?
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 бит информации, чтобы зафиксировать то, между какими входами-выходами есть прямая связь. Содержимое же макроса уже играет роли.
Или я чего-то путаю?
Владимир Ситников
03.08.2017, 20:27
Это не баг. Первым обрабатывается верхний вход, а нижний вторым.
O__O
Что значит "первым обрабатывается верхний вход"? Вы что вкладываете в понятие "обработка входа XOR"?
Вот видеозапись: http://recordit.co/EjrZEKJELy (это же видео в виде анимированного gif: http://g.recordit.co/EjrZEKJELy.gif )
Макрос NOTD это вход ==> NOT =задержка=> выход
Очевидно, что вариант "макрос" и "вне макроса" выдают разный ответ.
Ой, неужели вас так вводит в ступор линия задержки на выходе?
Да пёс с ней. Могу сделать такой же пример с задержкой по входу:
http://recordit.co/D78FxgJAtw (оно же http://g.recordit.co/D78FxgJAtw.gif )
Результат всё равно один и тот же: вариант с "макросом" требует двух циклов на переключение состояния, а точно такой же вариант (но без макроса) переключается на каждом цикле. Отсюда вывод: в варианте с макросом ОЛ добавляет лишнюю задержку. Иначе как ещё объяснить то, что период генератора меняется?
Блин, да. Вставляет. :)
Это да - косяк, однако :)
O__O
Что значит "первым обрабатывается верхний вход"? Вы что вкладываете в понятие "обработка входа XOR"?
да как в javascript: foo && bar, если первое false то второе уже не проверяется
capzap, в железе будет так, есть t фронта, если на момент перехода D=0 то и выход будет равен 0. и так далее.
Никакого опоздавшего железо не ждет, никогда...
http://digitalchip.ru/d-trigger - это железячный + его элементная схема - повторите на ПР или ПЛК...
1) Берём выход
2) Смотрим что к нему подключено
3) Если подключен ФБ / функция, то пытаемся вычислить этот самый ФБ/функцию. Что для этого нужно? Нужно знать значения входов.
4) Пытаемся вычислить значение каждого входа:
4.1) Если на вход подключена линия задержки, то просто берём её значение
4.2) Если вход подключена простая связь, то пытаемся вычислить значение того, откуда эта связь выходит (точно так же как на шаге 3)
5) Потом обновляем значения в линиях задержки (не хочу заострять внимание на том как именно)
Если же на этапе 4.2 наступает цикл, то говорим "ай-яй-яй, взрываем ПР и заканчиваем работу".
Сейчас это реализовано по-другому.
Видимо, при наступлении "цикла", входу просто назначается статическая переменная, инициализируется нулём (при компиляции), и вычисляется тот самый выход, исходя из значения этой переменной. Значение выхода пишется в переменную "зацикленного" входа.
Т.е., "автоматом" встаёт ЛЗ.
да как в javascript: foo && bar, если первое false то второе уже не проверяется
Да вот нифига. У xor-a в любом случае нужно оба входа считать.
Это же, всёже, or, а не and.
Да и в нерабочем варианте видно, что 1 на вход xor-a не пришла по "железной связи".
Тут какой-то другой косяк.
И ведь в другом макросе работает и с нижним входом.
Да вот нифига. У xor-a в любом случае нужно оба входа считать.
Это же, всёже, or, а не and.
Да и в нерабочем варианте видно, что 1 на вход xor-a не пришла по "железной связи".
Тут какой-то другой косяк.
И ведь в другом макросе работает и с нижним входом.
я про то что применяется некоторая последовательность,слева на право, сверху вниз
capzap, в железе будет так, есть t фронта, если на момент перехода D=0 то и выход будет равен 0. и так далее.
Никакого опоздавшего железо не ждет, никогда...
http://digitalchip.ru/d-trigger - это железячный + его элементная схема - повторите на ПР или ПЛК...
да уже сказали что картинка не правильная
PS раз уж картинки лажевые бывают, можно и на осциллограф посмотреть https://www.google.ru/url?sa=t&rct=j&q=&esrc=s&source=web&cd=6&cad=rja&uact=8&ved=0ahUKEwjM1sfP1rvVAhXGHxoKHetWCBkQtwIINTAF&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3Dy1 w6Nskbx8E&usg=AFQjCNFQoX3XZuTU-u-Zu2TKWAWYhIg-8A и главное ангицкий не нужен и так подсказки дают
я про то что применяется некоторая последовательность,слева на право, сверху вниз
Нет. Тут какая-то проблема с моментом инициализации константы, скорее всего. Похоже, она в том примере, почему-то, инициализируется позже нижнего входа xor-а, но до ЛЗ. Не понятно почему в других случаях такого нет. Как-то видимо связано с построением дерева вычислений и с остальной схемой. Хотя, константы, по идее, должны инициализироваться в первую очередь - раньше всего остального.
Интересно. Оно и в ПР так же будет, или это симулятор только дурит?
ну специалист по оптимизации здесь не я, но например считаю что на уровне асма легче взять значение и найти его предыдущее состояние, чем искать значение как текущего так и предыдущего значения, хранящихся независимо друг от друга
Вопрос хороший и он тесно пересекается с вопросом "а как вообще должны вычисляться значения выходов".
Как вам такой вариант?
1) Берём выход
2) Смотрим что к нему подключено
3) Если подключен ФБ / функция, то пытаемся вычислить этот самый ФБ/функцию. Что для этого нужно? Нужно знать значения входов.
4) Пытаемся вычислить значение каждого входа:
4.1) Если на вход подключена линия задержки, то просто берём её значение
4.2) Если вход подключена простая связь, то пытаемся вычислить значение того, откуда эта связь выходит (точно так же как на шаге 3)
5) Потом обновляем значения в линиях задержки (не хочу заострять внимание на том как именно)
А вообще, разбор схемы и составление последовательности операций, примерно так и идёт.
Т.е, на этапе "компиляции", создаётся "дерево" с корнем на выходе, выстраиваются ветви к узлам ФБ пока не доберёмся до входов или до констант. Циклы "обрубаются" статическими переменными.
Если макросы будут с "необязательными" входами, то от этих входов придётся ростить новые деревья, иначе, на них никогда ничего не придёт. А как от них считать "расстояние", задающее порядок расчёта (дальше от корня раньше считается, а они от главного корня отрублены)?
Вобщем, хз. Наверное, можно, но не просто.
ну специалист по оптимизации здесь не я, но например считаю что на уровне асма легче взять значение и найти его предыдущее состояние, чем искать значение как текущего так и предыдущего значения, хранящихся независимо друг от друга
А их не надо искать. И текущее состояние, впринципе не надо хранить. Вычислили, записали в стат.переменную (ЛЗ), отдали по этапу, и забыли.
сделал сейчас D-Trigger в Logo, в общем та же песня, сам по себе работает правильно, 3 последовательно ведут себя так же, пока не добавишь задержки между ними.
Василий Кашуба
03.08.2017, 22:13
O__O
Что значит "первым обрабатывается верхний вход"? Вы что вкладываете в понятие "обработка входа XOR"?
Не имеет значения XOR или нет, я говорил об этом.
32414 32415 Разницу видите? Функция одна и та же, а вычисление разное.
Причем многие знают об этом уже давно ,а некоторые только сейчас :rolleyes:
Хотя для элементов AND, OR, XOR вообще стек не должен участвовать, так как входа у них равнозначны.
Василий Кашуба
03.08.2017, 23:00
Хотя для элементов AND, OR, XOR вообще стек не должен участвовать, так как входа у них равнозначны.
Входы может и равнозначные, но на один из входов одного элемента, подаётся сигнал с выхода другого элемента, и пока этот выход не вычислится, на входе ничего не будет. Где промежуточные вычисления хранятся?
Василий Кашуба, ну давайте посмотрим на AND - на одном из входов выход другого элемента - на выходе AND 0 - вычислился выход элемента и стал 1 - попал на вход AND, на выходе стало 1
На кой там в булевой логике хранить для AND значение ?
тоже для XOR, OR и так далее...
А вот если вы что-то делаете с задержками и т.д. вот только тогда может потребоваться и то, решается флагами, правда которых в ОЛ нет.
Василий Кашуба
03.08.2017, 23:22
Василий Кашуба, ну давайте посмотрим на AND - на одном из входов выход другого элемента - на выходе AND 0 - вычислился выход элемента и стал 1 - попал на вход AND, на выходе стало 1
На кой там в булевой логике хранить для AND значение ?
тоже для XOR, OR и так далее...
А вот если вы что-то делаете с задержками и т.д. вот только тогда может потребоваться и то, решается флагами, правда которых в ОЛ нет.
По вашему все семь выходов одновременно вычисляются? И почему вы взяли для примера булеву переменную, а не ИНТ.?
А вы пример переполнения стека для INT привели ? к тому же при AND со входами int тоже булевые операции выполняются только над всеми битами числа и опять же, к чему там стек ?
Может сами операторы надо последовательно выполнять, а не биты в стек заносить, там где он 300 лет не нужен ?
Владимир Ситников
03.08.2017, 23:29
Не имеет значения XOR или нет, я говорил об этом.
32414 32415 Разницу видите? Функция одна и та же, а вычисление разное.
И? Результат вычисления разный что-ли получается?
То, что стек используется по-разному это "особенность реализации" (отсутствие оптимизации использования стека).
А если от порядка входов AND меняется результат, то это уже бага ОЛ.
Стек это внутренний механизм обработки схемы по всем выходам с обратными связями (в том числе когда одни выходы участвуют в формировании других) .Чем больше ОС тем глубже заполняется стек ..Раньше он был 6 ,потом 15 ,а потом динамическим ...
Ну так вот вопрос по оптимизации, если в участке схемы нет обратных связей, ни прямых, ни явных, зачем данный участок класть в стек ? все и так выполнится последовательно.
Выполняется последовательно ,но в одном цикле .Если поставить задержку .ТО получим в одном цикле одно значение ,а во втором другое .Например возьмите сравнение на равенство и подайте одно число(переменную) на два входа ,причем один вход сделайте задержку - получите формирователь импульса при смене числа .Не поставите задержку -будет всегда 1 . Элемент один ,переменная одна ,а линии связи разные и результат разный .
Владимир Ситников
03.08.2017, 23:45
Стек это внутренний механизм обработки схемы по всем выходам с обратными связями (в том числе когда одни выходы участвуют в формировании других) .Чем больше ОС тем глубже заполняется стек ..Раньше он был 6 ,потом 15 ,а потом динамическим ...
Ну зачем запутывать люд честной?
Стек нужен для хранения промежуточных значений.
Про "обратную польская запись (https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%80%D0%B0%D1%82%D0%BD%D0%B0%D1%8F_% D0%BF%D0%BE%D0%BB%D1%8C%D1%81%D0%BA%D0%B0%D1%8F_%D 0%B7%D0%B0%D0%BF%D0%B8%D1%81%D1%8C)" слышали?
На Wikipedia есть пример как на стековой машине вычислять выражения (https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%80%D0%B0%D1%82%D0%BD%D0%B0%D1%8F_% D0%BF%D0%BE%D0%BB%D1%8C%D1%81%D0%BA%D0%B0%D1%8F_%D 0%B7%D0%B0%D0%BF%D0%B8%D1%81%D1%8C#.D0.92.D1.8B.D1 .87.D0.B8.D1.81.D0.BB.D0.B5.D0.BD.D0.B8.D1.8F_.D0. BD.D0.B0_.D1.81.D1.82.D0.B5.D0.BA.D0.B5).
Переводя с русского на русский, стек нужен не только для "линий задержки"/"обратных связей", а вообще для всех выражений.
При этом ОЛ не оптимизирует использование стека, и получается, что в зависимости от способа записи (от схемы) получается разное использование стека.
всю жизнь считал, что стек работает иначе. Первым записали - последним считали, последним записали - первым считали. А тут в ОЛ какой-то огород получился, а не стек.
Скорее всего так обозвали, слово красивое наверное :)
Василий Кашуба
04.08.2017, 00:02
Ну так вот вопрос по оптимизации, если в участке схемы нет обратных связей, ни прямых, ни явных, зачем данный участок класть в стек ? все и так выполнится последовательно.
Вот как раз к вопросу о последовательности. Я показал, что вся схема вычисляется слева на право и сверху в низ. Для левой картинки сколько промежуточных вычислений нужно держать в памяти пока получится результат? А вот для правой схемы только одно промежуточное значение.
Василий Кашуба
04.08.2017, 00:24
Ну зачем запутывать люд честной?
Стек нужен для хранения промежуточных значений.
Про "обратную польская запись (https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%80%D0%B0%D1%82%D0%BD%D0%B0%D1%8F_% D0%BF%D0%BE%D0%BB%D1%8C%D1%81%D0%BA%D0%B0%D1%8F_%D 0%B7%D0%B0%D0%BF%D0%B8%D1%81%D1%8C)" слышали?
На Wikipedia есть пример как на стековой машине вычислять выражения (https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%80%D0%B0%D1%82%D0%BD%D0%B0%D1%8F_% D0%BF%D0%BE%D0%BB%D1%8C%D1%81%D0%BA%D0%B0%D1%8F_%D 0%B7%D0%B0%D0%BF%D0%B8%D1%81%D1%8C#.D0.92.D1.8B.D1 .87.D0.B8.D1.81.D0.BB.D0.B5.D0.BD.D0.B8.D1.8F_.D0. BD.D0.B0_.D1.81.D1.82.D0.B5.D0.BA.D0.B5).
Переводя с русского на русский, стек нужен не только для "линий задержки"/"обратных связей", а вообще для всех выражений.
При этом ОЛ не оптимизирует использование стека, и получается, что в зависимости от способа записи (от схемы) получается разное использование стека.
Вот поэтому для левой картинки в стек нужно поместить сразу все переменные, а в правой вычислять только две.
Владимир Ситников
04.08.2017, 00:58
Вот поэтому для левой картинки в стек нужно поместить сразу все переменные, а в правой вычислять только две.
И? На результате это не должно сказываться.
Моё утверждение в том, что от перестановки местами входов XOR результат не должен изменяться (само результирующее значение должно сохраняться).
То, что стек используется по-разному -- не должно играть роли.
Сергей0308
04.08.2017, 03:54
всю жизнь считал, что стек работает иначе. Первым записали - последним считали, последним записали - первым считали. А тут в ОЛ какой-то огород получился, а не стек.
Скорее всего так обозвали, слово красивое наверное :)
Может Алексея Толстого читали, помните про гиперболоид, он прекрасно понимал, что правильно назвать параболоид, но так назвал, потому что "звучит"!
Вот поэтому для левой картинки в стек нужно поместить сразу все переменные, а в правой вычислять только две.
Это если бы каждый раз считали "от выхода к входу".
А считают "от входа к выходу".
Т.е., в обоих случаях, вначале стек заполняется значениями входов, но в разном порядке (для левой 8,7,6,5,4,3,2,1, для правой наоборот) а потом идут операции and,and,and....
При and, впринципе, можно прервать вычисление такой цепочки, получив первый раз false. А при or/xor нельзя, и всёравно придётся прокрутить весь стек.
Будет оптимизация, если проверять каждый результат и пытаться прерваться? Нет. Не будет. Потому, что проверка - это лишняя команда и цикл процессора. И в среднем, при всех возможных состояниях входов может и не получиться прироста быстродействия. К тому же, при компиляции нужно уметь находить такие выражения и каждый раз вставлять для них новый код.
При одном элементе (баг, который я показывал) вообще нет смысла говорить про "порядок действий". Да и видно, что баг образовался не в коде самого лог.элемента, а ещё на входе.
Василий Кашуба
04.08.2017, 09:19
И? На результате это не должно сказываться.
Моё утверждение в том, что от перестановки местами входов XOR результат не должен изменяться (само результирующее значение должно сохраняться).
То, что стек используется по-разному -- не должно играть роли.
А где я написал что результат на выходе разный?
Владимир Ситников
04.08.2017, 09:29
Это если бы каждый раз считали "от выхода к входу".
А считают "от входа к выходу".
Тут у вас неточность, т.к. входа вообще может не быть. Иными словами, если блок подключить только к выходу, то он всё равно будет работать, а, если блок подключить только ко входу, то работать не будет.
Значит, работают "от выхода".
Т.е., в обоих случаях, вначале стек заполняется значениями входов, но в разном порядке (для левой 8,7,6,5,4,3,2,1, для правой наоборот) а потом идут операции and,and,and....
Вряд ли.
Скорее всего, в одном случае последовательность такая (стек используется на 2 элемента максимум, т.к. они сразу обрабатываются):
push in1 # Стек: in1
push in2 # Стек: in2, in1
and # берёт 2 элемента со стека, выполняет and, кладёт на стек результат
push in3 # Стек: in3, результат AND(in1, in2)
and # Стек: результат AND(in1, in2, in3)
push n4
and
push n5
and
...
А в другом -- такая (сначала всё забиваем в стек, а потом вычисляем):
push in1 # Стек: in1
push in2 # Стек: in2, in1
push in3 # Стек: in3, in2, in1
push in4 # Стек: in4, in3, in2, in1 <-- потребление стека растёт, а вычислений пока не происходит
...
and
and
and
and
..
А дальше у вас верный вывод:
Будет оптимизация, если проверять ...
Владимир Ситников
04.08.2017, 09:34
А где я написал что результат на выходе разный?
Вот тут:
А поменяйте связи на входах местами и схема заработает.
И вот тут:
Это не баг. Первым обрабатывается верхний вход, а нижний вторым.
Напомню, это всё были ответы на сообщение pop70 о том, что "константа 1 приходит на вход XOR как 0 и в итоге выход XOR'а оказывается 0"
Кстати, попал на один косяк в работе ЛЗ.
В макросе CTMAX.
В чём дело - хз. Повторить не могу. И в программе, и в новом макросе работает. А в том пришлось константу делать 0 и вставлять инвертор - тогда всё работает.
32410
Вы сначала сказали поменять связи, а потом сказали, что исходное поведение не баг.
Так вот, если убрать попытки пихать в стек все элементы, а закидывать только те части, где есть обратные связи или ЛЗ , то и получится оптимизация. Пусть лучше 10-ток AND прощелкает лишний раз без всякого стека. А ощущение, что в стек пихают все что ни попадя...
Василий Кашуба
04.08.2017, 09:41
Напомню, это всё были ответы на сообщение pop70 о том, что "константа 1 приходит на вход XOR как 0 и в итоге выход XOR'а оказывается 0"
Сигнал на вход приходит не тот. Причём здесь выход, выход как раз работает правильно.
Владимир Ситников
04.08.2017, 09:44
Сигнал на вход приходит не тот. Причём здесь выход, выход как раз работает правильно.
А почему при этом "помогает изменение порядка связей"?
Или весь ваш совет заключался не в изменении порядка, а в "переподсоединении"?
Реальная схемотехника, это, да, наука о плохих контактах. Но в ОЛ схемах-то такого не должно быть. Баг.
Василий Кашуба
04.08.2017, 09:50
А почему при этом "помогает изменение порядка связей"?
Или весь ваш совет заключался не в изменении порядка, а в "переподсоединении"?
Реальная схемотехника, это, да, наука о плохих контактах. Но в ОЛ схемах-то такого не должно быть. Баг.
Вот раньше был баг, вот это БАГ, связь могла повиснуть в воздухе,не присоединившись к другому элементу. :)
Василий Кашуба
04.08.2017, 09:53
Реальная схемотехника, это, да, наука о плохих контактах. Но в ОЛ схемах-то такого не должно быть.
Почему то все просят, чтобы было всё как в железе. :)
Тут у вас неточность, т.к. входа вообще может не быть. Иными словами, если блок подключить только к выходу, то он всё равно будет работать, а, если блок подключить только ко входу, то работать не будет.
Значит, работают "от выхода".
Вы не путайте порядок "компиляции"(разбора схемы") и порядок её вычисления.
Я же уже писал. При "компиляции" строится дерево с корнем у выхода. (Схема уже такое дерево) От выхода ко входу. А порядок расчёта узлов этого дерева обратный - вначале считаются дальние от корня узлы, потом, используя уже посчитанные данные - следующие - более близкие к выходу. Этот порядок определяется один раз при "компиляции", и тупо выполняется в каждом цикле программы, без каких бы то ни было "оптимизаций" в каждом цикле. И порядок этот не может быть от выхода к входу. Потому, что вначале нужно задать входные анные каждому элементу, а только потом получить то, что на выходе.
Так вот, если убрать попытки пихать в стек все элементы, а закидывать только те части, где есть обратные связи или ЛЗ , то и получится оптимизация. Пусть лучше 10-ток AND прощелкает лишний раз без всякого стека. А ощущение, что в стек пихают все что ни попадя...
ЛЗ никак с стеку не относится
ЛЗ - это вообще статическая переменная, живущая всё время работы ПР, как и "обратная связь".
Чё Вам стека стм-ки жалко? :)
Лишь бы на память переменных не наехал. Программа вообще прямо в ППЗУ вся сидит
Василий Кашуба
04.08.2017, 14:30
Кстати, попал на один косяк в работе ЛЗ.В макросе CTMAX.
В чём дело - хз. Повторить не могу. И в программе, и в новом макросе работает. А в том пришлось константу делать 0 и вставлять инвертор - тогда всё работает.
 Миниатюры

А в чём сакральный смысл, константу подключать к входу через ЛЗ?
Василий Кашуба
04.08.2017, 17:13
Перекомпилирует схему, а не все её составляющие.
Вас напрягает предупреждение, которое можно игнорировать, если знаешь что делаешь?
"Не правильно" с точки зрения идеи "линии задержки" как "значение входа в прошлом цикле".
В схеме больше, чем один вход на конец ЛЗ не поставишь.
Кстати, попал на один косяк в работе ЛЗ.
В макросе CTMAX.
В чём дело - хз. Повторить не могу. И в программе, и в новом макросе работает. А в том пришлось константу делать 0 и вставлять инвертор - тогда всё работает.
Я кажется понял почему программа сработала так. Так как первой обрабатывалась ЛЗ, то первый цикл для всей программы был отменён, для того чтобы получить, значение для этой ЛЗ.
Владимир Ситников
04.08.2017, 17:27
Я кажется понял почему программа сработала так. Так как первой обрабатывалась ЛЗ, то первый цикл для всей программы был отменён, для того чтобы получить, значение для этой ЛЗ.
Слушайте, это всё вилами по воде. Как "отмена цикла" поможет "получить значение ЛЗ"? Если цикл отменён, то и в ЛЗ ничего не попадёт, значит этой ЛЗ нечего будет обрабатывать.
Не должно быть никаких лишних пропусков только из-за того, что на схему добавили ЛЗ.
Гораздо более вероятен вариант с "плохим контактом". Т.е. каким-то образом сделана связь (например, в древней версии ОЛ), которая выглядит как связь, но не работает.
Легко же проверить: сейчас значение константы передаётся прямо сразу, и нет никакого "пропуска первого цикла".
А в чём сакральный смысл, константу подключать к входу через ЛЗ?
Ничего сакрального. На картинке формирователь единичного импульса по началу работы (включению ПР).
Я кажется понял почему программа сработала так. Так как первой обрабатывалась ЛЗ, то первый цикл для всей программы был отменён, для того чтобы получить, значение для этой ЛЗ.
Да нет. Там какой-то косяк на обычной связи. На одной стороне 1, на другой (у входа элемента) 0.
Василий Кашуба
04.08.2017, 18:06
Ничего сакрального. На картинке формирователь единичного импульса по началу работы (включению ПР).
Поставьте на входе инвертор без константы и всё будет работать.
32439
Поставьте на входе инвертор без константы и всё будет работать.
32439
Оно и так работает. Повторял в другом макросе - работает. Хоть к верхнему входу, хоть к нижнему.
Просто, не привык входы "в воздухе подвешивать". Отсюда и константа. Атавизм от железячника :)
Владимир Ситников
04.08.2017, 18:18
Поставьте на входе инвертор без константы и всё будет работать.
32439
Так работает же и с константой.
Чего обсуждать? Баг и есть баг.
Если бы ОВЕН хотели узнать причину, то они что-нибудь сделали бы.
Ну или наоборот: отправить в ОВЕН палёный проект (если есть возможность), и спросить в чём проблема.
Василий Кашуба
04.08.2017, 18:21
Слушайте, это всё вилами по воде. Как "отмена цикла" поможет "получить значение ЛЗ"? Если цикл отменён, то и в ЛЗ ничего не попадёт, значит этой ЛЗ нечего будет обрабатывать.
Не должно быть никаких лишних пропусков только из-за того, что на схему добавили ЛЗ.
Гораздо более вероятен вариант с "плохим контактом". Т.е. каким-то образом сделана связь (например, в древней версии ОЛ), которая выглядит как связь, но не работает.
Легко же проверить: сейчас значение константы передаётся прямо сразу, и нет никакого "пропуска первого цикла".
Я не верно выразился. Помогите с определением, как узнать то, что было, до того как всё началось. :)
Владимир Ситников
04.08.2017, 19:08
Я не верно выразился. Помогите с определением, как узнать то, что было, до того как всё началось. :)
"Здесь принято" отправлять проект в личку wal79. Он раскуривает проект и выдаёт своё мнение (или чинит ОЛ).
Если я правильно понимаю pop70, то у него остался файл с проектом, который работает неправильно. Как раз этот файл и нужно отправить программистам ОВЕН.
Было бы, конечно, хорошо, если бы ОЛ показывало p-code, который получается из пользовательской схемы (в том числе на промежуточных этапах). Но это не реализовано, и, полагаю, ждать этого можно "до пенсии".
PS Распечатка промежуточного кода встречается много где:
В МастерСкаде4 есть возможность увидеть генерируемый код. Они сделали как раз для целей отладки.
Если посмотреть на МЗТА, то у них тоже можно посмотреть генерируемый код.
И в моей среде, разумеется, видно как трансформируется код.
Василий Кашуба
04.08.2017, 19:19
А моя просьба, дать новое определение "отмене цикла"
 Сообщение от Василий Кашуба 
Я не верно выразился. Помогите с определением, как узнать то, что было, до того как всё началось. 
Владимир Ситников
04.08.2017, 19:21
А моя просьба, дать новое определение "отмене цикла"
Например, договориться, что при запуске схемы, значения всех линий задержки будут равны 0.
В чём вопрос-то?
вот приехал домой, тоже решил поиграться(выложил перевод из оскатовской бибки), может быть не первый раз звучит вопрос и ответы были, но раз уж у нас смена состояния любой переменной происходит раз в цикл, то почему линии задержки мешают, как раз с ними все получается же. Не так как в железе, ну так и триггер программный, там своя "физика".
И второй вопрос мучает, из-за чего собственно и раздулась тема на столько страниц, а зачем на d-триггерах делать регистр сдвига, почему не так http://www.owen.ru/forum/showthread.php?t=7023&p=234863&viewfull=1#post234863
По самые по...
06.08.2017, 10:01
В реальном железе для создания регистра сдвига соединяют выход Д-триггера с D входом последующего непосредственно, без всяких устройств задержки сигнала, в ОЛ Д-триггер работает не так, как в железе, об этом я и толкую, что вводит в заблуждение большинство людей и я на эти грабли наступал, зачем делать так?
Потому-шта в ОЛ организован статический Д-триггер, а нужон динимический (мастер-слейв).. Почитайте про M-S триггера (http://books.sernam.ru/book_ps.php?id=76)..
Создавайте в ОЛ M-S Д-триггер на рассыпухе, и будет вам счастье
Потому-шта в ОЛ организован статический Д-триггер, а нужон динимический (мастер-слейв).. Почитайте про M-S триггера (http://books.sernam.ru/book_ps.php?id=76)..
Создавайте в ОЛ M-S Д-триггер на рассыпухе, и будет вам счастье
Путаете тёплое с мягким. M-S на ОЛ вообще не создать. Там нужны разные уровни переключения с 0 в 1 и обратно. Можно, конечно, через ЛЗ...
Почитайте внимательно по Вашей же ссылке.
Ну и заодно справку по D-триггеру из ОЛ.
Динамический он ДИНАМИЧЕСКИЙ.
Триггеры "на рассыпухе" в ОЛ явно придётся править. Не переносит он обратных связей - задержку влупляет, логика "портрится", тайминги плывут.
Классический RS на И-НЕ элементах тупит по инверсному выходу - зачастую он совпадает с неинверсным.
Поздно увидел обсуждения... Не понял в чем баг конкретно? Просьба последовательно описать на что жалоба?
Насчет промежуточного кода... Он есть, лоджик его конечно же генерирует и выдает для отладки. Но далеко не всегда при разборе багов он нужен, я бы сказал даже в редких случаях.
Как многие тут уже говорили, стек действительно не оптимизируется, так как с появлением динамического стека никто в это не видит резона в трате времени и денег на его оптимизацию. Возможно, когда-нибудь, будут человекоресурсы для данной работы. Если работа программы с различной загрузкой стека дает разный результат - то это баг и просьба сообщить о нем.
Владимир Ситников
08.08.2017, 15:16
Поздно увидел обсуждения... Не понял в чем баг конкретно? Просьба последовательно описать на что жалоба?
Раз (подробное описание в сообщении): http://www.owen.ru/forum/showthread.php?t=25870&p=254263&viewfull=1#post254263
Два (константа 1 приходит на вход XOR как 0): http://www.owen.ru/forum/showthread.php?t=26787&page=14&p=254369#post254369
c CTMAX нужен проект или это возобновляется легко?
Я не обещал что при анализе ЛЗ будет прозрачность. Первая версия реализации алгоритма обнаружение показала, что прозрачности тут не должно быть, иначе будут ложно обнаружены связи. Но согласен, что дополнить алгоритм нужно, для идентификации подобных сценариев.
Владимир Ситников
08.08.2017, 16:28
c CTMAX нужен проект или это возобновляется легко?
Не воспроизводится. Нужен проект. Попробуйте спросить в личке у pop70.
Я не обещал что при анализе ЛЗ будет прозрачность. Первая версия реализации алгоритма обнаружение показала, что прозрачности тут не должно быть, иначе будут ложно обнаружены связи. Но согласен, что дополнить алгоритм нужно, для идентификации подобных сценариев.
Не понял. Пример с "линией задержки внутри макроса" в итоге считается багом или фичей?
c CTMAX нужен проект или это возобновляется легко?
Воспроизводится не всегда.
http://www.owen.ru/forum/showthread.php?t=12691&p=253863&viewfull=1#post253863
Файл проекта (макрос). Правда, в нём уже обошёл этот баг через константу 0 и инвертор.
Попробуйте убрать инвертор, константе задать значение 1, и подключить связью к нижнему входу xor, а лз к верхнему.
У меня тогда этот баг воспроизводится. При смене выводов xor (к верхнему напрямую, к нижнему через лз), баг пропадает.
Сегодня приложу файлик в "забагованном" виде.
Проверить бы ещё это баг только в симуляторе, или на железке тоже повторится.
Файл с багом во вложении
И ещё вопрос.
Универсальный счётчик из стандартных макросов ОЛ ограничен 16 битами. Это баг или фича? И в чём смысл этой фичи?
И ещё вопрос.
Универсальный счётчик из стандартных макросов ОЛ ограничен 16 битами. Это баг или фича? И в чём смысл этой фичи?
Этот вопрос не ко мне. Надеюсь знающие люди ответят Вам.
Сергей0308
09.08.2017, 02:18
Можно же объединить 2 счётчика, как-то так:
32520
Не всегда требуется 32 бита, если Вам требуется элемент 8И, зачем тогда нужен 2И?!
Можно же объединить 2 счётчика, как-то так:
32520
Не всегда требуется 32 бита, если Вам требуется элемент 8И, зачем тогда нужен 2И?!
Не. Не понимаю!
Проще заново нарисовать, чем объединять. Если не нужны 32 бита - можно вообще ничего не делать. Переменную один фиг 32 бита хранить. Экономии никакой. Просто, странное решение для среды, не имеющей 16 битных переменных.
По элементам, как раз, всё понятно - базовый элемент на 2 входа. По счётчикам - базовый JK на один бит для булевых, и 32 бита для интов.
Фича бессмысленная. Значит, баг.
Сергей0308
09.08.2017, 07:10
Не. Не понимаю!
Проще заново нарисовать, чем объединять. Если не нужны 32 бита - можно вообще ничего не делать. Переменную один фиг 32 бита хранить. Экономии никакой. Просто, странное решение для среды, не имеющей 16 битных переменных.
По элементам, как раз, всё понятно - базовый элемент на 2 входа. По счётчикам - базовый JK на один бит для булевых, и 32 бита для интов.
Фича бессмысленная. Значит, баг.
В сетевых целочисленных переменных 16 бит, старшие 16 бит срезаются! Допустим Вам надо по сети передать целочисленное значение 32 битного счётчика, надо разбивать на два регистра по 16 бит, а здесь уже всё разбито! Останется получить и собрать!
Не воспроизводится. Нужен проект. Попробуйте спросить в личке у pop70.
Не понял. Пример с "линией задержки внутри макроса" в итоге считается багом или фичей?
Не воспроизводится. Нужен проект. Попробуйте спросить в личке у pop70.
Не понял. Пример с "линией задержки внутри макроса" в итоге считается багом или фичей?
Я бы не назвал это багом. Но как уже сказал замечание принято. Насчет оптимизации анализа ЛЗ и не только. Естественно расматривались в свое время такие задачи и делались некие прототипы. Но игра не стоила свеч. Затраты не окупались полученным выигрышем в производительности. В 1.10 ставки сделаны на другое - асинхронность операций, что в разы увеличило отзывчивость пользовательского интерфейса. Что на мой взгляд более востребовано в ОЛ.
Я бы не назвал это багом. Но как уже сказал замечание принято. Насчет оптимизации анализа ЛЗ и не только. Естественно расматривались в свое время такие задачи и делались некие прототипы. Но игра не стоила свеч. Затраты не окупались полученным выигрышем в производительности. В 1.10 ставки сделаны на другое - асинхронность операций, что в разы увеличило отзывчивость пользовательского интерфейса. Что на мой взгляд более востребовано в ОЛ.
ИМХО, тут дело не в быстродействии, а в минимальном нарушении заданной схемой логики. Это, опять же ИМХО, приоритетнее любых остальных задач. Чтобы работало "как нариовано", а не "быстро, но как Бог на душу положит".
В сетевых целочисленных переменных 16 бит, старшие 16 бит срезаются! Допустим Вам надо по сети передать целочисленное значение 32 битного счётчика, надо разбивать на два регистра по 16 бит, а здесь уже всё разбито! Останется получить и собрать!
А кроме счётчика по сети ничего передавать не надо?
Так, может быть, вообще инты 16 битами ограничить? А где надо больше - собирать?
Или просто с "сетевыми переменными" поработать на тему одно/двух-регистровые? Тем более, что модбас вполне себе это позволяет.
Вообще, сетевые операции в ОЛ на слишком низком, по сравнению с остальным, уровне программируются. Это повод поработать над концепцией сетевого обмена уровнем выше, а не придумывать высосанных из пальца ограничений для отдельных ФБ.
Вообще говоря, ОЛ - весьма удачный продукт. Жаль сыроват.
Чего реально не хватает в интерфейсе - это "горячих клавиш". Особенно в симуляции. (Режим симуляции, пуск, стоп, пауза, шаг).
"Точек останова" "по условию".
Примитивная ctrl+A в редакторе :) - тоже не хватает.
Вобщем, управления для "клавишников".
При установке обратной связи, "петли дурацкие" вылазят, невозможность прокрутки схемы при постановке связи (на больших "холстах" доставляет) - решилось бы прокруткой в режиме "+ctrl"(масштаб), " +shift"(прокрутка влево/вправо), "+alt"(прокрутка вверх/вниз).
Стандартные для графических редакторов вещи...
Вид поля элементов не сохраняется, по умолчанию стоит огромная "плитка", на маленьких экранах, в результате имеем одну папку или один элемент в поле, при прокрутке - прыжки "через один". В "списке" удобнее гораздо....
Таких мелочей набирается воз и маленькая тележка.
Я не придираюсь - просто очевидные вещи, важные для удобства.
Сергей0308
09.08.2017, 09:35
А кроме счётчика по сети ничего передавать не надо?
Так, может быть, вообще инты 16 битами ограничить? А где надо больше - собирать?
Или просто с "сетевыми переменными" поработать на тему одно/двух-регистровые? Тем более, что модбас вполне себе это позволяет.
Вообще, сетевые операции в ОЛ на слишком низком, по сравнению с остальным, уровне программируются. Это повод поработать над концепцией сетевого обмена уровнем выше, а не придумывать высосанных из пальца ограничений для отдельных ФБ.
Это надо всё регламентировать(стандартизировать), чтобы у всех производителей одинаково было, а то с реалами(флоатами) воз и ныне там, до сих пор байты тасуют всяк по своему!
ИМХО, тут дело не в быстродействии, а в минимальном нарушении заданной схемой логики. Это, опять же ИМХО, приоритетнее любых остальных задач. Чтобы работало "как нариовано", а не "быстро, но как Бог на душу положит".
Естественное, нарушений в логике работы последовательной программы быть не должно. К этому и стремимся. Этот ответ больше предназначался Владимиру о вопросах оптимизации. Я согласен что, принуждение лоджиком вставлять у макроса дополнительную ЛЗ - это не совсем верно. Но считаю это не багом, а избыточностью. И согласился что следует это замечание учесть и скорректировать анализ обратных связей. Насчет CTMAX пока ничего не могу сказать ,баг это или фича. Но в любом случае замечание будет проанализировано и приняты необходимые меры. Или есть еще какие-то баги?
Вообще говоря, ОЛ - весьма удачный продукт. Жаль сыроват.
Чего реально не хватает в интерфейсе - это "горячих клавиш". Особенно в симуляции. (Режим симуляции, пуск, стоп, пауза, шаг).
"Точек останова" "по условию".
Примитивная ctrl+A в редакторе :) - тоже не хватает.
Вобщем, управления для "клавишников".
При установке обратной связи, "петли дурацкие" вылазят, невозможность прокрутки схемы при постановке связи (на больших "холстах" доставляет) - решилось бы прокруткой в режиме "+ctrl"(масштаб), " +shift"(прокрутка влево/вправо), "+alt"(прокрутка вверх/вниз).
Стандартные для графических редакторов вещи...
Вид поля элементов не сохраняется, по умолчанию стоит огромная "плитка", на маленьких экранах, в результате имеем одну папку или один элемент в поле, при прокрутке - прыжки "через один". В "списке" удобнее гораздо....
Таких мелочей набирается воз и маленькая тележка.
Я не придираюсь - просто очевидные вещи, важные для удобства.
При установке обратной связи, "петли дурацкие" вылазят, невозможность прокрутки схемы при постановке связи (на больших "холстах" доставляет) - решилось бы прокруткой в режиме "+ctrl"(масштаб), " +shift"(прокрутка влево/вправо), "+alt"(прокрутка вверх/вниз).
Автоскроллинг чем-то не устраивает? Или не так работает как хотелось бы?
Вообще, к сожалению на доработку существующего функционала практически не выделяется время. В 1.10 вписали парочку задач, расширяющие существующий функционал, а в остальном - это создание нового ,поддержка нового оборудования...
Василий Кашуба
09.08.2017, 09:53
Естественное, нарушений в логике работы последовательной программы быть не должно. К этому и стремимся. Этот ответ больше предназначался Владимиру о вопросах оптимизации. Я согласен что, принуждение лоджиком вставлять у макроса дополнительную ЛЗ - это не совсем верно. Но считаю это не багом, а избыточностью. И согласился что следует это замечание учесть и скорректировать анализ обратных связей. Насчет CTMAX пока ничего не могу сказать ,баг это или фича. Но в любом случае замечание будет проанализировано и приняты необходимые меры. Или есть еще какие-то баги?
В новой версии ОЛ1.9.131 есть баги. http://www.owen.ru/forum/showthread.php?t=25870&p=254798&viewfull=1#post254798
Это надо всё регламентировать(стандартизировать), чтобы у всех производителей одинаково было, а то с реалами(флоатами) воз и ныне там, до сих пор байты тасуют всяк по своему!
"Все производитпли" - это отдельный вопрос.
Вполне достаточно стандартизировать в линейке Овенов. Чтобы "по умолчанию" работало на высоком уровне с "близкими родственниками". А для "дальних" - возможность настройки протокола на более низком уровне.
При установке обратной связи, "петли дурацкие" вылазят, невозможность прокрутки схемы при постановке связи (на больших "холстах" доставляет) - решилось бы прокруткой в режиме "+ctrl"(масштаб), " +shift"(прокрутка влево/вправо), "+alt"(прокрутка вверх/вниз).
Автоскроллинг чем-то не устраивает? Или не так работает как хотелось бы?
Вообще, к сожалению на доработку существующего функционала практически не выделяется время. В 1.10 вписали парочку задач, расширяющие существующий функционал, а в остальном - это создание нового ,поддержка нового оборудования...
Автопрокрутка работает "никак" - задолбаешься мышой ловить её.
Понятно, что всё упирается в ресурсы, и "в одно лицо" законченный, высококласный продукт, с поддержкой и длинным жизненным циклом - "это фантастика, сынок" :)
Просто, многие вещи упущены ещё на стадии "идеологии", а некоторые просто недоделаны.
Ну, наверное, можно же где-то на стороне хотябы интерфейсную часть заказать "по стандарту", чтобы больше времени оставалось на функционал и поддержку продуктов.
ПР с экраном появились, а симулятор - "ёк"...
Ладно... ворчать заканчиваю.
Перекомпилирует схему, а не все её составляющие.
Вас напрягает предупреждение, которое можно игнорировать, если знаешь что делаешь?
"Не правильно" с точки зрения идеи "линии задержки" как "значение входа в прошлом цикле".
В схеме больше, чем один вход на конец ЛЗ не поставишь.
Кстати, попал на один косяк в работе ЛЗ.
В макросе CTMAX.
В чём дело - хз. Повторить не могу. И в программе, и в новом макросе работает. А в том пришлось константу делать 0 и вставлять инвертор - тогда всё работает.
дело в порядке исполнения линий задержки. В тулбаре если вы поиграетесь с порядком исполнения ЛЗ, то увидите разницу. Такие тонкости настраиваются порядком исполнения, потому что у Вас к примеру две ЛЗ участвуют в одной ветке анализа и кого из них первую обрабатывать лоджик ведь не знает. Он ориентируется в таких случаях на выставленные порядки исполнения. Понимаю, что пользователю это может быть не совсем понятно. Подумаю на досуге, может найдется средство избавить пользователя от подобного.
32564
Владимир Ситников
10.08.2017, 15:37
дело в порядке исполнения линий задержки. В тулбаре если вы поиграетесь с порядком исполнения ЛЗ, то увидите разницу. Такие тонкости настраиваются сейчас порядком исполнения, потому что у Вас к примеру две ЛЗ участвуют в одной ветке анализа и кого из них первую обрабатывать лоджик ведь не знает.
А порядок обработки обратных связей влияет на результат?
Логично же было бы обновлять состояние ЛЗ уже после вычисления всей схемы. Тогда порядок выполнения ЛЗ не должен играть роли.
Или я чего-то путаю?
А порядок обработки обратных связей влияет на результат?
Логично же было бы обновлять состояние ЛЗ уже после вычисления всей схемы. Тогда порядок выполнения ЛЗ не должен играть роли.
Или я чего-то путаю?
Задержка и обновляется в конце, это верно... Может так более понятно будет... 3256532566
Переменная 3 на первом скрине и переменная 1 на втором...
Проблема в том что чтение переменной идет до записи в нее константы.
Тут скорей всего нужно будет пересмотреть обход ЛЗ. Покумекаю...
дело в порядке исполнения линий задержки. В тулбаре если вы поиграетесь с порядком исполнения ЛЗ, то увидите разницу. Такие тонкости настраиваются порядком исполнения, потому что у Вас к примеру две ЛЗ участвуют в одной ветке анализа и кого из них первую обрабатывать лоджик ведь не знает. Он ориентируется в таких случаях на выставленные порядки исполнения. Понимаю, что пользователю это может быть не совсем понятно. Подумаю на досуге, может найдется средство избавить пользователя от подобного.
32564
Причём тут лз и порядок их выполнения?
На xor от ОБЫЧНОЙ связи (не лз) константа 1 приходит нулём.
С лз в том примере всё работает как надо. При запуске, приходит начальный 0, на след. цикле от константы прилетает 1.
Посмотрите внимательнее.
Причём тут лз и порядок их выполнения?
На xor от ОБЫЧНОЙ связи (не лз) константа 1 приходит нулём.
С лз в том примере всё работает как надо. При запуске, приходит начальный 0, на след. цикле от константы прилетает 1.
Посмотрите внимательнее.
Да я вижу о чем вы говорите. :-) Вы меня не услышали...
Проблема в том что чтение переменной идет до записи в нее константы.
Тут скорей всего нужно будет пересмотреть обход ЛЗ. Покумекаю...
Какой переменной?
У Вас каждой связи назначено 2 переменных?
Повторяю. Проблема в цепи без ЛЗ (переменной). Константа подана на вход напрямую.
Любая константа инициализируется до любых статических и динамических переменных. Это правило такое общепринятое.
Потом статические переменные (лз) нулём при первоначальном запуске. А потом уже все их чтения и записи по мере вычисления.
Если, как я предполагал, константа на входе элемента инициализируется после расчёта элемента, то это не просто баг, а баг в самом сердце программы.
Владимир Ситников
10.08.2017, 16:14
Задержка и обновляется в конце, это верно... Может так более понятно будет... 3256532566
Переменная 3 на первом скрине и переменная 1 на втором...
Проблема в том что чтение переменной идет до записи в нее константы.
Тут скорей всего нужно будет пересмотреть обход ЛЗ. Покумекаю...
Ну, да, хрень какая-то.
На всякий случай, упростил схему. Действительно воспроизводится на одном XOR элементе.
32568
Владимир Ситников
10.08.2017, 16:22
Какой переменной?
У Вас каждой связи назначено 2 переменных?
Повторяю. Проблема в цепи без ЛЗ (переменной). Константа подана на вход напрямую.
Любая константа инициализируется до любых статических и динамических переменных. Это правило такое общепринятое.
Так вам показали же лог: 32565
Переменная №3 это и есть "хранилище, которое используется для того, чтобы подать 1 на вход XOR'а".
В логе видно, что ОЛ почему-то пыталось "поместить значение константы в переменную 3" уже намного позже вычисления самого XOR'а (XOR обрабатывал переменную 4=="линия задержки" и переменную 3=="простая связь" ).
ЛЗ к этой самой "переменной 3" (надеюсь) никак не относится.
Потом статические переменные...
Это всё, конечно, красивые рассуждения про "космические карабли", но точно такой же баг может образоваться и без констант.
Поэтому баг нужно исправлять не "починкой констант", а починкой самого компилятора, который допустил use-before-def.
Вот тот же самый баг без констант:
32570
32568
Ну и как тут вычисляется?
Пошагово?
По всем канонам здравого смысла:
Начало
1. Конст1:=1* (может быть ещё при компилляции, и запись в тело программы, в пзу)
2. ЛЗ1:=0
3. ЛЗ2:=0
Инициализировали все переменные.
НЦ
4. Выход:=ЛЗ1
5. ЛЗ2- В стек
6. Константа - в стек
7. XOR
8. Результат - в ЛЗ1
9. Константа - в ЛЗ2
КЦ
3 дерева:
1.От выхода(шаг 4)
2. От ЛЗ1 (на выходе)(шаги 5-8)
3. От ЛЗ2 (на входе)(шаг 9)
Если 3е выполняется раньше второго, то на вход хоr с линии задержки прилетит 1 к моменту расчёта xor.
Но ни при каких условиях на второй вход не прилетит 0 от константы.
Владимир Ситников
10.08.2017, 16:39
Ну и как тут вычисляется?
По всем канонам здравого смысла:
Да хватит привязываться к константам и ПЗУ.
Рассмотрите лучше пример, где я воспроизвёл баг на "входе" макроса.
Значение входа-то уж никак в ПЗУ не запишешь.
Так вам показали же лог: 32565
Переменная №3 это и есть "хранилище, которое используется для того, чтобы подать 1 на вход XOR'а".
3=="простая связь" ).
ЛЗ к этой самой "переменной 3" (надеюсь) никак не относится.
Там вообще не нужны переменные.
Всё легко тусуется прямо в стеке.
(Имею в виду статические переменные).
Владимир Ситников
10.08.2017, 16:45
5. ЛЗ2- В стек
6. Константа - в стек
7. XOR
Да посмотрите же на лог.
В конкретном случае ОЛ приняло решение константу 1 сохранить в переменную. Наверное, из-за того, что используется в нескольких местах.
Поэтому и последовательности операций "константа-в стек; xor" вообще нет в логе.
Если 3е выполняется раньше второго, то на вход хоr с линии задержки прилетит 1 к моменту расчёта xor.
Но ни при каких условиях на второй вход не прилетит 0 от константы.
Здесь у вас ошибка.
Судя по логу, секция "инициализации начальных значений до цикла" отсутсвует как класс. Да, это может звучать "не по канонам", но это неважно, ведь точно такая же ошибка может возникнуть и при любых других вычислениях (обработке входов, например)
Владимир Ситников
10.08.2017, 16:48
Там вообще не нужны переменные.
Всё легко тусуется прямо в стеке.
(Имею в виду статические переменные).
Результат используется в нескольких местах (из "константы" выходят две связи), и вполне логично, что компилятор сохранил этот самый результат в промежуточную переменную.
Могла бы эта переменная соптимизироваться? Могла. Но эта оптимизация повлияла бы лишь на скорость работы.
А скорость работы сейчас всех устраивает.
Да хватит привязываться к константам и ПЗУ.
Рассмотрите лучше пример, где я воспроизвёл баг на "входе" макроса.
Значение входа-то уж никак в ПЗУ не запишешь.
Значения входа пишутся в переменные в начале цикла - до расчёта. Это тот же самый баг-багище чтения из ненужной и неинициализированной переменной.
Да посмотрите же на лог.
В конкретном случае ОЛ приняло решение константу 1 сохранить в переменную. Наверное, из-за того, что используется в нескольких местах.
Поэтому и последовательности операций "константа-в стек; xor" вообще нет в логе.
Здесь у вас ошибка.
Судя по логу, секция "инициализации начальных значений до цикла" отсутсвует как класс. Да, это может звучать "не по канонам", но это неважно, ведь точно такая же ошибка может возникнуть и при любых других вычислениях (обработке входов, например)
Не может. Входы по определению пишутся до расчёта цикла.
Отсутствие инициализации констант и статических переменных при запуске программы (до первого цикла) - это путь к непредсказуемому поведению ПР при включении.
На время первого цикла, на выходах может оказаться любой мусор, никак не связанный с запрограммированным поведением. Это БАГИЩЕ, недопустимый в промавтоматике.
Владимир Ситников
10.08.2017, 17:06
Не может. Входы по определению пишутся до расчёта цикла.
Похоже, вы не поняли сущность бага: значение, к которому подключено несколько связей, сохраняется во вспомогательную переменную.
Поэтому не так важно что находится на входе, а будет использовано именно значение из вспомогательной переменной.
То же самое будет и в любом другом вычислении. Надо просто результат вычисления подключить двумя связями (простой и ЛЗ) и можно получить баг (в зависимости от указанного приоритета ЛЗ).
Результат используется в нескольких местах (из "константы" выходят две связи), и вполне логично, что компилятор сохранил этот самый результат в промежуточную переменную.
Могла бы эта переменная соптимизироваться? Могла. Но эта оптимизация повлияла бы лишь на скорость работы.
А скорость работы сейчас всех устраивает.
Согласен насчёт промежуточной переменной, но в любом случае, она должна была посчитаться до того, как использоваться в расчёте. Т.е., любое дерево должно дойти до самого дальнего узла - до константы, если она не "обрублена" уже посчитанной промежуточной переменной.
Похоже, вы не поняли сущность бага: значение, к которому подключено несколько связей, сохраняется во вспомогательную переменную.
Поэтому не так важно что находится на входе, а будет использовано именно значение из вспомогательной переменной.
То же самое будет и в любом другом вычислении. Надо просто результат вычисления подключить двумя связями (простой и ЛЗ) и можно получить баг (в зависимости от указанного приоритета ЛЗ).
Приоритет ЛЗ тут никаким боком вообще.
Эдак и приоритет выходов может привести к тому, что в расчёте будет использована "промежуточная переменная", которую ещё никто не посчитал.
А эта "промежуточная переменная" должна быть посчитана при первом же проходе через неё, не важно с какой стороны разветвления расчёт к ней пришёл.
Так вам показали же лог: 32565
Переменная №3 это и есть "хранилище, которое используется для того, чтобы подать 1 на вход XOR'а".
В логе видно, что ОЛ почему-то пыталось "поместить значение константы в переменную 3" уже намного позже вычисления самого XOR'а (XOR обрабатывал переменную 4=="линия задержки" и переменную 3=="простая связь" ).
ЛЗ к этой самой "переменной 3" (надеюсь) никак не относится.
Это всё, конечно, красивые рассуждения про "космические карабли", но точно такой же баг может образоваться и без констант.
Поэтому баг нужно исправлять не "починкой констант", а починкой самого компилятора, который допустил use-before-def.
Вот тот же самый баг без констант:
32570
Вы все верно уловили. Понял в чем проблема. Когда- то ЛЗ (тогда еще обратная связь) была выделена в особую группу анализа.Вот тут и кроется проблема.компилятор уже давно был усовершенствован, а анализ лз - нет. Пишу с мобилы не очень удобно расписывать.
Ну и ладно. Вам Ваша логика виднее. Почему она вдруг завязалась на ЛЗ и их приоритеты, мне не понять. :)
Как и назначение переменной какой-либо связи. Главное - исправить.
Ну и ладно. Вам Ваша логика виднее. Почему она вдруг завязалась на ЛЗ и их приоритеты, мне не понять. :)
Как и назначение переменной какой-либо связи. Главное - исправить.
Да конечно, будет исправлено. В этот хотфикс она уже не попадет, будет в следующем.
Powered by vBulletin® Version 4.2.3 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot