Не удивительно что он замедляется, так как время периода растет, что бы он разгонялся нужно в CTN значение N задать например 1000, а импульсы от BLINK подавать на вход D. как то так11.png
Не удивительно что он замедляется, так как время периода растет, что бы он разгонялся нужно в CTN значение N задать например 1000, а импульсы от BLINK подавать на вход D. как то так11.png
Relaymen....
Это неудавшееся идея генератора.
Идея была в том чтобы: допустим от нуля вверх 0-536... и вниз 0-0.00000001,
Но из-за отсутствия write to fb для чисел с запятой это провалилось
жаль что в ол есть только fbd
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Всё равно Должен быть такой write.!!!
Relaymen .......
Ещё остались добавить к вводам ctu
u и d переключатель из and,
Допустим прогресс доходит: от 0 до 100 (U), переключается на (D) от 100 до 0!
Как-то так, но это очень мелкий диапазон
Последний раз редактировалось ParuSnow; 29.08.2017 в 14:19.
Думаю, для обсуждения работы над ОЛ 1,9 эта более подходящая тема
Мне лично представляется, что ЛЗ внутренне есть разрыв между итерациями цикла.
То есть конец ЛЗ - это значение предыдущей итерации, оно проходит программу и попадает в начало ЛЗ.
На основании такого понимания я проектирую свои схемы.
Можно сказать, что оно так работает? А если нет, то какие можно привести примеры, когда оно не будет так работать?Тоже хочется знать примеры того, когда некая схема обернутая в макрос, начинает выполняться по-другому, чтобы научиться их проектировать с учетом этих особенностей.Так вот, если вы задумали какой-то алгоритм обернуть в макрос, то нужно понимать, что это "закрытый" будет алгоритм, что он будет вычисляться как отдельная схема. Надеюсь, понятно разъяснил.
Таких примеров будет полностью достаточно для понимания работы ОЛ пользователями безо всяких "спецификаций".
PS в обновлении касающегося отмены "прозрачности макросов" есть некая иллюстрация очень маленького размера.
Выложите её где нибудь в нормальном размере посмотреть, пожалуйста. Там может быть что нибудь полезное для понимания.
Последний раз редактировалось anthrwpos; 31.08.2017 в 12:05.
- ά ν θ ρ ω π ο ς -
Мои универсальные макросы https://github.com/anthrwpos1/macros
Не будет достаточно.
Вот Вам один из таких примеров.
Оберните в макрос просто ЛЗ.
И попробуйте в схеме соединить выход этого макроса со входом.
ОЛ поставит ещё одну ЛЗ.
Нужна она? Нет. Никакой необходимости с точки зрения "развёрнутой" схемы в ЛЗ здесь не будет.
Но ОЛ мерещится в данном случае, что для вычисления значения на выходе такого макроса, необходимо точно знать значение на его входе.
Т.е., схема с макросом, в котором только лз, и схема с лз, не "обёрнутой" макросом, абсолютно по-разному анализируется и считается.
И эта ситуация не всегда очевидна так, как в этом примере. И в какой именно схеме, и какая из лз внутри макроса даст "артефакты" "неразворачивания" макроса при анализе и вычислении, зависит от многих факторов.
Т.е., необходим анализ КАЖДОЙ КОНКРЕТНОЙ СХЕМЫ, содержащей КОНКРЕТНЫЙ МАКРОС, чтобы понять как она себя поведёт.
Похоже проблема следующая.
Программа в ОЛ есть цикл. У цикла есть начало и конец. Конец цикла находится либо в выходе, либо в начале ЛЗ, начало цикла - во входе, либо в конце ЛЗ.
Макрос вставляется в цикл между элементами так, что сначала входы передаются первым элементам макроса. Затем мы доходим до конца ЛЗ и записываем туда полученное значение. Предыдущее значение считываем из буфера и вычисляем макрос до выходов.
Именно так получается лишняя задержка.
Как сделать так, чтобы она не появлялась и всё работало корректно пока не понятно. Банальное решение вычислять элементы от концов ЛЗ первыми до выходов макроса явно приведет к ошибкам.
- ά ν θ ρ ω π ο ς -
Мои универсальные макросы https://github.com/anthrwpos1/macros
Нет здесь особых проблем.
Просто, при анализе схемы, нужно учитывать макрос не как "функцию" (значение на выходе которой зависит только от того, что на входе), а как конкретный набор элементов, и анализировать и считать схему с "развёрнутым" макросом.
Когда макрос - это исключительно созданная этим же инструментом схема, проблем никаких. А написание ФБ другими инструментами, как я понял, никто не собирается реализовывать.
Т.е., неявно вместо графического представления макроса подставляются его "внутренности" столько раз, сколько встречается в схеме макрос, и анализируется и расчитывается полная развёрнутая схема.
Хочется, чтобы можно было сохранять и загружать значения энергонезависимых переменных по умолчанию в текстовых конфигурационных файлах.
У меня каждый проект используется в нескольких разных объектах с разными заданными там калибровками, заданиями и прочими вещами.
После смены программы приходится вбивать списки значений перед заливкой программы на каждый объект руками. Часто можно запутаться или что-то пропустить.
- ά ν θ ρ ω π ο ς -
Мои универсальные макросы https://github.com/anthrwpos1/macros