Баг и состоит в том, что "неправильно обнаруживается проблемная связь".Цитата:
Сообщение от Эдуард_Н
Вид для печати
Баг и состоит в том, что "неправильно обнаруживается проблемная связь".Цитата:
Сообщение от Эдуард_Н
Ага, есть... тонкий момент, но важный. Спасибо, внес коррективы в анализ. В следующем релизе.Цитата:
Сообщение от Эдуард_Н
ОЛ ее обнаружил, но подсветил не то, что надо. Лоджик обнаруживает последнюю замыкающую связь. И если она глубоко в макросе, то согласно разработанному алгоритму должен был подсветить последнюю внешнюю связь. Вот тут то и была несогласованность задуманного алгоритма и реализации. Помарка исправлена. В данном случае лоджик последнюю замыкающую внешнюю связь определил "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.
И финальный глюк: основная программа - не работает отладка!!! Сообщение тоже. Предыдущая версия этот файл не принимает. Что делать?!!!