Нет проект полностью рабочий, простой состоит из двух макросов, каждый в отдельности, открытый в редакторе, работает, а в общем окне нет.Сообщение от wal79
Нет проект полностью рабочий, простой состоит из двух макросов, каждый в отдельности, открытый в редакторе, работает, а в общем окне нет.
Последний раз редактировалось Василий Кашуба; 16.01.2017 в 10:22.
Не совсем понимаю почему в этой ветке написали... :-) Этот проект и в 1.8 не симулируется. Переменной ведь фактически не существует, она является виртуальной. Вот если Вы соедините блок чтения этой переменной с выходом (или сделаете, к примеру, энергонезависимой в приборах, поддерживающих эту память), то она сразу будет задействована. Это же так сказать аксиома нашего продукта, начало ее идет еще с самых первых релизов.
программер
Поставил 1.9.250.8649 -- попробовал.
1) Само сообщение "требуется явно установить линию задержки" это, конечно, шаг вперёд, но нужно объяснять что пошло не так. Иначе люди не будут понимать что именно случилось.
Т.е. должно быть в духе "Ошибка ОЛ94523: в программе оказался цикл из связей. Нужно либо разорвать цикл, либо заменить какую-то связь на линию задержки"
По слову "ОЛ94523" хорошо будет срабатывать поиск. Можно добавить и ссылку на страницу / справку с описанием "простейшего примера где такое может возникать", и описанием "почему нельзя делать циклы" (на примере вечного двигателя из блока MUL или чего-нибудь такого).
2) Можно добавить кнопку, ссылку или ещё что-то, чтобы ОЛ показало где именно находится цикл/проблемная связь?
3) Похоже, само сообщение об ошибке пропадает после запуска симуляции
Снимок экрана 2017-01-16 в 10.41.43.png (мигает, но сообщения внизу нет)
4) Если связь выделена, то её "мигание красным" не видно
5) Явный цикл не мешает запуску симуляции. В описании к 1.9 написано, что будет мешать. Или я не так читаю?
Снимок экрана 2017-01-16 в 10.41.06.png
6) Помощь, история версий ведёт в никуда.
Последний раз редактировалось Владимир Ситников; 16.01.2017 в 13:41.
В последнем выложенном релизе 208 пункт 3 исправлен.
По поводу пункта 5. Компилятор считает критической ошибкой линию задержки, обнаруженную внутри используемого в проекте макроса.
Последний раз редактировалось wal79; 16.01.2017 в 13:40.
программер
^^^ тут точно нет ошибок в словах? Звучит так, как будто в макросах вообще нельзя использовать линии задержки, а это было бы крайне странно.
Полагаю, речь была не про пользовательскую, а про неявную.
А снаружи? Цикл в основной программе не считается ошибкой?
Почему он тогда подкрашивается красным?
Есть ли смысл делать разные поведения для случая "в макросе" и "в основной программе"?
По-моему, циклы нужно везде запрещать. Кому надо -- пусть ставят линии задержки.
Циклы из простых связей лишь вселяют ложную надежду, что "программа правильная, это ОЛ-ПР чудит".
Последний раз редактировалось Владимир Ситников; 16.01.2017 в 13:45.
Макрос критичен ведь к этому. Если там будет цикл, то поведение его не однозначно. В проекте допускается применение циклических связей для того, чтобы сильно не "ломать" программу пользователя. Мы предупреждаем пользователя о цикле, но исправлять в проекте или нет - дело его. И старые проекты (исключая макросы) будут работать как раньше. Мы не принуждаем, мы предупреждаем. :-)
программер
1) Можно различать старые проекты и новые? Ну, если проект создан в ОЛ 1.9, то можно запрещать циклы на всех уровнях.
В старых проектах можно либо сразу ругаться, либо предупреждать. Можно галочку сделать "я_хочу_циклы_из_связей__понимаю_что_программа_мож ет_не_работать__клянусь_не_обращаться_в_поддержку_ при_этом"
Но лучше вообще везде запретить циклы.
2) Так ли важно "не ломать"? Реально был случай на форуме, когда товарищ утверждал, что "программа рабочая", а по факту в ней цикл.
Проблема даже не в том, что от цикла программа становится "вообще нерабочей". А в том, что от цикла неявная задержка может возникнуть в самом неожиданном месте.
3) Утверждалось, что макросы раскрываются при компиляции (т.е. full inline). Полагаю, неявная задержка расставляется после этого. Из этого делаю вывод, что по факту неявная задержка может возникнуть "как бы в макросе" (т.е. в том месте программы, который находился в макросе). В итоге будет старое "макрос сам по себе рабочий, а вставляем его в общую программу и беда-печаль".
Всё так? Или там супер-алгоритм, который запрещает возникновение неявной связи в том месте, которое "возникло из макроса"?
Хорошо, обдумаем вновь вариант запрещать везде циклы более основательно...
программер
Да, я имел в виду циклическую связь, поправлюсь.
программер
мало того, макросы сами по себе работали нормально, но связи после макросов, даже без явных связей ломали работу макросов.
Или наоборот, при добавлении рабочего макроса с обратной связью в программу с неявными происходил сбой программы
з.ы. я у себя уже поправил поведение, но на 1.9 еще не проверял...
Ваши права
