Баг и состоит в том, что "неправильно обнаруживается проблемная связь".Цитата:
Сообщение от Эдуард_Н
Вид для печати
Баг и состоит в том, что "неправильно обнаруживается проблемная связь".Цитата:
Сообщение от Эдуард_Н
Ага, есть... тонкий момент, но важный. Спасибо, внес коррективы в анализ. В следующем релизе.Цитата:
Сообщение от Эдуард_Н
ОЛ ее обнаружил, но подсветил не то, что надо. Лоджик обнаруживает последнюю замыкающую связь. И если она глубоко в макросе, то согласно разработанному алгоритму должен был подсветить последнюю внешнюю связь. Вот тут то и была несогласованность задуманного алгоритма и реализации. Помарка исправлена. В данном случае лоджик последнюю замыкающую внешнюю связь определил "PWM1 - fMUL".Цитата:
Сообщение от Владимир Ситников
Но прошу не забывать одного, что лоджик может только предложить "проблемную" связь, он не телепат. А в реальности Вы можете заменить на линию задержки другую связь в этом цикле. Ту, которую Вы считаете наиболее верной согласно Вашему алгоритму.
По-моему, в конкретном случае "самая сомнительная связь" это "чтение из переменной result --> fLIMIT2" и именно её ОЛ должно подкрашивать / предлагать заменить на задержку.Цитата:
Сообщение от wal79
Объяснение следующее:
"для того, чтобы вычислить результат, который нужно записать в result" нужно выполнить fADD, а для вычисления fADD нужен результат "ЛЗ от чтения current" (тут дальнейший анализ "как вычисляется current" не нужен, т.к. значение приходит с прошлого цикла) и результат "fMUL".
Так мы разворачиваем цепочку и в итоге доходим до "для того, чтобы вычислить fLIMIT2 нужно знать результат чтения current", но ведь current ещё не вычислено, значит цикл, и как раз эту связь и объявляем как "циклообразующую".
Что по-вашему называется "последней" связью?
Последняя для лоджика связь в цикле. Та связь, которая является для лоджика повторюсь замыкающей. Насчет какая связь должна быть ЛЗ должен решать сам разработчик программы.Цитата:
Сообщение от Владимир Ситников
Здравствуйте!
Давно хочу обратить ваше внимание на следующий бачог.
Вложение 32774
повторяемость одних и тех же переменных.
И было бы крайне удобно ввести служебную переменную idScreen, содержащую id отображаемого в данный момент экрана.
Так, как получилось так? Можете описать действия, чтобы мне возобновить. Насчет Id экрана - да, да, давнешняя тема. В оперативном плане к 1.10 есть такая задача. Пока еще не приступали.Цитата:
Сообщение от Project M
Да, увидел на более полной картинке, что цикл по факту состоит из "Q3 <- fLIMIT3 <- fADD <-...<- Q+ <- PWM1 <- fLIMIT2 <- fLIMIT1 <- result <- fADD <- fMUL <- PWM1" и поэтому связь PWM1-fMUL и объявляется как причина всех бед.Цитата:
Сообщение от wal79
М... Так ничего не делал. Как перешёл с OL 1.8 на OL 1.9, так всё и стало :) Даже по необходимости делал полное удаление OL и .NET с использованием сторонних процедур.Цитата:
Сообщение от wal79
Устанавливал с нуля и то и другое, всё тоже самое.
Уже три глюка: 1. При попытке отладки макроса в первый раз наблюдается такое сообщение (см. приложение) со второго раза отладка запускается. 2. Переменные, которые передавались вложенным макросам через параметр после открытия в новой версии сбросили свое состояние на значение по умолчанию. 3. Изменил макрос (уменьшилось количество входов) компилятор не выделил красным ранее установленные как подлежащие замене (Kn_Ttr7 новый и ост. Kn_Ttr старые). Все относится к последней версии 11503.
И финальный глюк: основная программа - не работает отладка!!! Сообщение тоже. Предыдущая версия этот файл не принимает. Что делать?!!!
По 1 и последнему пункту нужен проект.Цитата:
Сообщение от RomX
2. Подтверждаю. Сохраняет почему-то значения не с первого сохранения.
3. Не подтверждаю. Проверил на новом проекте - не возобновляется, все подсвечивается. Нужна тогда последовательность действий.
Высылаю...
Почти все заработало после того как удалил глючные элементы указанные в п.3. предыдущего сообщения. На отладке сейчас не работает только вход I1. Пишет чтото про индексы.
И это решено. Глюк исчез после того как нормально сделал блок 7или. до того последний ввод в макросе не был подцеплен.
Я рад что все заработало, но проблема имеет место быть, значит ее нужно устранить. Просьба оставаться все равно здесь, в ветке, боюсь что у меня возникнут уточняющие вопросы.Цитата:
Сообщение от RomX
В симуляторе ОЛ1.9.139, после выключения не сбрасываются ранее заданные параметры, и при повторном включении симулятора все старые задания остаются.
Это фича по желанию наших пользователей.Цитата:
Сообщение от Василий Кашуба
Она Вам мешает или вносит путаницу?
Просто привык к прежнему поведению симулятора и решил что это баг.Цитата:
Сообщение от wal79
Что нового в ОЛ1.9.139?
А этот проект был создан в 139 билде лоджика или в более ранней версии?Цитата:
Сообщение от RomX
Некоторые наши пользователи изъявили желание, что бы значения входов в симуляторе сохранялось, чтобы не перенастраивать каждый раз.Цитата:
Сообщение от Василий Кашуба
там только одно исправление, связанное с обнаружением необходимости линий задержек.Цитата:
Сообщение от Эдуард_Н
У Вас макрос KnTtr был с 4 входами, а стал с 3. Так? Вы его заменяли на схеме в итоге?Цитата:
Сообщение от RomX
Такая вот ерунда: выход с одного макроса не попадает на другой.
Вложение 32812
Сам проект
Вложение 32813
И сам макрос работает неадекватно (на симуляции точно, на железе еще не проверял). Понаблюдайте, у него скочат выходы то в ту то в обратную сторону. Если зайти в сам макрос и там просимулировать, введя те-же входящие параметры, то такого поведения нет.
Да. Интересненько. Кстати, если убрать линию задержки, всё работает. Либо заменить линию задержки на простую, тоже работает.Цитата:
Сообщение от anthrwpos
Да, работаю в данный момент над этим. Здесь злосчастная "прозрачность" макроса сыграла роль. Мои тесты пока не все многообразие проектов пока покрывает. Вот еще на один пополнится.Цитата:
Сообщение от Project M
неа, не работает.Цитата:
Сообщение от Project M
-1 вместо 0,1 не пишет, но сам макрос делает какую-то ерунду. (вчера он открывался-закрывался по несколько раз, сегодня открывается на 1 секунду раз в 3 минуты вместо того, чтобы за 3 подхода спозиционировать в заданное положение). Заходишь в сам макрос, выставляешь на входы те-же параметры - работает как положено.
Так что это вероятно более глобальный баг, чем ошибка подачи выхода на вход.
Принятие решения по поводу "прозрачности" макросов было крайней ошибкой. После более глубокого изучения этого вопроса прозрачность будет убрана. Для анализатора схемы никакой прозрачности быть не может. Тогда Ваша схема работает исправно. Постараюсь в ближайшее время выложить.Цитата:
Сообщение от anthrwpos
И ещё один баг внутри ФБ VLV1, в режиме симуляции. Вложение 32832Цитата:
Сообщение от anthrwpos
А что такое эта самая прозрачность макроса?Цитата:
Сообщение от wal79
Угу.Цитата:
Сообщение от wal79
Я Вас сразу предупреждал.
Тупиковый путь.
Либо при анализе неявно "разворачивать" макрос, и анализировать схему с "подставленными" макросами, т.е. без макросов как таковых, либо никакой "прозрачности".
Вот бы ещё как-то победить необходимость переподставлять макрос в схему после редактирования макроса... :)
Ну тут можно долго разглагольствовать о том кто о чем говорил и предупреждал. Владимиром тогда было высказано как замечание, я глубоко тогда не копнул. Я рассматриваю любое ваше пожелание или замечание. Либо соглашаюсь с ним либо отвергаю. Тогда мне показалось заманчивой затеей, хотя повторюсь что никогда не говорил что макрос абсолютно прозрачен. Видимо меня не так поняли. Анализатор (транслятор) конечно же должен учитывать макрос . Макрос для него как inline функция. И представленное Владимиром предложение о "прозрачности" макроса в итоге концептуально неверно. Сейчас, посовещавшись со специалистами в предметной области, я удостоверился что мои сомнения оправданы. Схемы в том варианте и должны работать по разному.Цитата:
Сообщение от pop70
Изначально отредактировал макрос. Убрал вход. При этом обычно другие экземпляры макросов подсвечиваются красным и их надо перевставлять. Тут этого не произошло. В дальнейшем я их перевставил и баг прошел.Цитата:
Сообщение от wal79
Да не. Я ж не в укор.Цитата:
Сообщение от wal79
Меня как раз по тому предложению и напрягло то, что макрос в общем случае НЕ ФУНКЦИЯ, а, как минимум, ПРОЦЕДУРА (а ещё точнее - объект, имеющий "собственное состояние"). А анализ схемы ведётся как для функции. Поэтому устранить неоднозначность поведения с обратными связями "вокруг макроса", пытаясь учитывать обратные связи внутри него ("прозрачность" без развёртывания), как минимум, очень сложно, как максимум невозможно.
Ну да ладно....
А вот можно ли как-то проработать вопрос с тем, чтобы редактирование макроса не требовало его перевставки в основную схему?
Просто, решение с перевставкой противоречит принципу структурированности программ.
Ну, т.е., если есть программа, использующая компоненты, то редактирование компонента не должно требовать его переопределения в программе.
Иначе получается ерунда.
Пишешь программу, используя десяток экземпляров одного компонента, и при небольшом изменении самого компонента - заново перерисовывать всю программу?
Не логично и не удобно. Даже если количество входов/выходов изменится - это не повод для требования перевставки.
А в окне просмотра переменных что показывают переменные inc и saw?Цитата:
Сообщение от Василий Кашуба
Вы не правы. Изменив количество входов Вы меняете сигнатуру функции. Здесь должны быть вмешательство со стороны пользователя. А если Вы меняете только тело функции, то переустановка макроса на схеме и не требуется. Единственно, есть баг, к сожалению существующий уже на протяжении не одного релиза, если редактируете макрос со вложенностью более 1, то в том макросе, где используется редактирующийся макрос обновление сразу не наступит. Нужно будет заново переоткрыть макрос. Об этом я знаю, и надеюсь будет время в ближайшие сроки исправить.Цитата:
Сообщение от pop70
Конечно, можно сделать то, что Вы хотите, но это уже будет в качестве дополнительного функционала.
Мда... Чудеса. Видимо есть какой-то сценарий, когда макрос не отметился как критически измененный. Не могли бы Вы воспроизвести и описать последовательность действий прямо по-шагово.Цитата:
Сообщение от RomX
Не обязательно. В ОЛ неиспользуемые входы инициализируются 0. Ошибки не будет, если новый вход будет никуда не подключен.Цитата:
Сообщение от wal79
Если входов уменьшится, то просто связь к удалённому входу "повиснет в воздухе". Т.е., просто удалится.
Т.е., на языке .net все макросы имеют на входах значения "по умолчанию". Добавляется входная переменная, инициализированная по умолчанию 0 - и никаких ошибок, и от пользователя ничего не требуется.
Перерисовать в схему новый фб вместо старого - тоже никаких проблем быть не должно.
Ну так мне кажется. Хотя, Вам "изнутри" виднее, конечно.
Вообще по общепринятой терминологии, макрос - это идентификатор, который транслируется в некий неизменный участок кода.Цитата:
Сообщение от wal79
Сколько раз его транслятор встретит - столько раз вместо него вставит этот участок.
Функция - это идентификатор, который компилируется в адрес вызова, по которому начинается сама функция.
У нас в ОЛ таки макросы или функции?=)
upd: Ура, сами макросы работают адекватно. Но появился новый бажок - не отслеживается состояние флоат переменных.Вложение 32860
Проект тот-же, на картинке внутренности макроса VLV
Если внимательно прочитаете, то я сказал inline функция. Компилятор встречая ее каждый раз встраивает тело функции в код.Цитата:
Сообщение от anthrwpos
С выделенным не соглашусь. Я вмешаюсь в программу пользователя, причем он может и не помнить что там была связь и откуда и куда она шла. В данном сценарии я должен подсветить макрос как невалидный. И все это, это и есть то что я назвал дополнительным инструментарием.Цитата:
Сообщение от pop70
А разве раньше было по другому?Цитата:
Сообщение от anthrwpos
Ладно, не буду дожидаться ответа. Видимо не все знакомы с watch list-ом переменнных. На скрине я вижу, что Вы добавили в список несуществующие переменные для прибора (я их называю виртаульными). В просмотрщике мы видим реальные переменные. Допустимые на запись можно редактировать, в противном случае только на чтение.