Будет очень мило с вашей стороны отразить это в РЭ к Owen Logic следующей версии.
А если с примерами - вообще изумительно.
Вид для печати
это будет полная ерунда, найдутся те кто будет ссылаться что ОВЕН таким образом запрещает пользоваться обратными связями.
Это задача самой среды разработки заставить пользователя отказаться от идей неправильно "строить" схему проекта, не зря же в КДС все блоки пронумерованы согласно очереди выполнения
По результатам анализа, возможно, будет добавлен функционал, когда будут выделены на схеме связи, которые компилятор определил как обратные. И пользователь должен сам подумать - вставить явную обратную связь и задать ей порядок или оставить на усмотрение компилятору. Пока не могу обещать что это появится, но идея такая возникла.
Я выше писал, что независимо от наличия, количества обратных связей компилятор ПРОСТО обязан выполнять задержку на один цикл у обратной связи по отношению к прямой, если они исходят из одного источника
Да сдался вам тот RTRIG (полагаю вы про тот, который с выхода RS макроса), вы его можете убрать к черту а проблема останется.
И прошу заметить, что даже в том примере, когда макрос начинает лажать, если открыть макрос на редактирование и запустить эмуляцию то макрос будет работать ИСПРАВНО.
Разрабы как-то узко смотрят на проблему, имхо, без обид....
Вот еще для разрабов, не поленился и сделал 4 версии одного макроса. Обращаю внимание на последний CRabw_v4, в котором применено тело макроса AI! (SelChange) в оригинале. В остальных использованы частично или как в v1 во всех стоит двойное ИЛИ с обратными связями.
И пожалуйста, не надо рассказывать сказок про RTRIG. Все наглядно и понятно, последний вариант просто перестает считать, хотя де факто не отличается практически ничем от других трех макросов...
Так же держите модификацию, которая глючит. Убрал обратную связь внутри макроса, запуск только по импульсу на входе С.
Убрал внешний RTRIG.
Я уже не знаю в который раз повторяю свой вопрос - ПОЧЕМУ элементы после макроса, в данном случае SEL, которые по логике никак не должны влиять на работу самого макроса ломают его работу ?
Макрос имеет собственные переменные, для каждого экземпляра они свои и никак не должны затрагивать переменные основной программы и должны быть изолированы от основной программы кроме входов и выходов. С этим же вы спорить не будете ?
Вот проблема:
Вложение 27176
Вы сделали цикл из не-обратных связей. Попросту говоря, от AND'а (слева вверху от зелёного поля) идёт на SEL не-обратная связь, из него выходит на другой SEL, и возвращается опять в AND.
Как оно по-вашему, должно работать?
Оно само должно догадаться какую из связей вы хотели сделать обратной?
Не уверен, что вообще существует алгоритм, который во всех случаях правильно определяет какая из простых связей подразумевалась автором программы как "обратная".
Приведу более простой пример, чтобы мой вопрос понятнее был:
Вложение 27177
Должен ли вход на 2-ом входе ADD'а всегда быть равен выходу этого самого ADD'а?
А, если подать 1 на первый вход?
Блок ADD же должен складывать свои входы, но в то же время, результат должен тут же подаваться на второй вход.
В симуляторе, разумеется, значения на 2-ом входе и на выходе ADD различаются, не смотря на то, что они соединены "простой связью".
Владимир, спасибо большое за проделанную работу :)
Все циклы абсолютно рабочие в макросе. На данный момент у меня этот макрос вообще реализован БЕЗ единой обратной связи только требует жесткого наличия переменных на входе и выходе. Например если я им считаю время и мне не нужны секунды, я все равно обязан создать переменную для секунд.
Это точно не является проблемой в падении работы макроса, когда в него добавляется все 4 оригинала SelChange.
А второй пример смотрели с SEL после макроса ? там вообще НИ ЕДИНОЙ обратной связи нет.
БЛИН. ПОВТОРЯЮ ВОПРОС ЕЩЕ РАЗ.
независимо как компилятор вычисляет шаги для блоков, связей и так далее. ПОЧЕМУ НАРУШАЮТСЯ ШАГИ прямой и обратной линии связи, идущие от ОДНОГО ВЫХОДА ???? Забудьте, что программа для каждого блока назначает свой шаг цикла, речь идет, что происходит нарушение в одной конкретной точке.
з.ы. я уже не знаю, как русским языком написать вопрос, чтобы его поняли программисты :)
И главное, что такого в SEL, если при 1 на входе он передает данные с одного входа, а при нуле с другого ?
http://www.owen.ru/forum/attachment....1&d=1477055611
Проблема в красном кружке, когда на выходе ADD появляется 1, то на входе EQ сразу фиксируется 1 на обоих входах, хотя должно быть на одном шаге 1, 0, на следующем 1, 1
То, что в синем кружке работает при этом корректно.
И прошу заметить, что проблема начинается если в макросе вставлено все 4 блока оригинала макроса SelChange, когда вставлено 2 и 3 блока нарушений в работе нет.
Вы приводите слишком много примеров. Это и хорошо и плохо одновременно.
Плохо то, что когда говорите "второй пример", то можете говорить конкретнее?
Там два многомегабайтных ОЛ проекта. Вы что понимаете под вторым примером?
Если честно, я, увидев кольцо из не-обратных связей, прекратил исследования, т.к. "правильно" работать оно вряд ли может.
Владислав как-то говорил, что в ОЛ прошло много лет, прежде чем победили все проблемы с обратными связями.
Мне не верилось, и, похоже, действительно, все "проблемы" вызваны не самими обратными, а тем, что часть "не обратных" неявно превращается в обратные. Т.е. ОЛ-то работает как и заявлено, но просто оно не предупреждает пользователей, что "нельзя делать кольца из необратных связей".
Передам палочку Максиму =)