Цитата Сообщение от Сергей0308 Посмотреть сообщение
Очень не удобно, не 16 экземпляров одного макроса нарисовать, а менять значения констант из свойств макросов, не то что их много(512), а программа сильно тормозит, долго думает, перед тем как я могу следующую константу изменить и не известно будут они работать в железе, поэтому наверно лучше подобное обходить или может на ПЛК мастерить, короче удобств мало, но мне нравится!
Смотрите: на мой взгляд, "правильное" решение конкретной задачи заключается не в применении 16 макросов внутри 16 макросов (ну или сколько там у вас).
На мой взгляд, решению конкретной задачи и кучи других задач поможет простой блок: "линия задержки на N тактов".
Т.е. мы в неё подаём входные значения и тактовый вход, а она на выходе выдаёт числа с задержкой на указанное количество тактов (это количество должно указываться, например, как указывается задержка у TON блока).

Тогда задача "скользящее среднее" на "500" или сколько там нужно будет решаться просто:
1) Сумматор, на который подаются входные числа
2) Сумматор, на который подаётся выход "линии задержки"
3) Разница между этими сумматорами и будет "суммой в окне".

Всего 3-4 блока, на которых ОЛ будет просто летать.

Да, гусары заметят, что при подобном подходе и использовании float'ов может возникнуть погрешность, но оставим эту лирику.

С точки зрения среды (ОЛ) это будет всего один блок -- т.е. не будет тормозов при попытках редактирования 500 блоков и связей.
Сам же блок задержки на аппаратном уровне тоже просто реализовать. Нужно просто выделить массив на нужное количество ячеек и использовать их по кругу.
И реализация простая, и в железе будет быстро работать (всего 5-10 команд процессора на одно срабатывание очереди), и программировать легко, и, немаловажно, блок линии задержки может много где пригодиться.

Ещё вариант решения подобных проблем -- "функциональный блок массива".
Ну, объявляем блок "массив, указываем количество элементов". И потом с помощью каких-нибудь спец блоков записываем значения в ячейки или читаем оттуда.

На мой взгляд, пытаться оптимизировать ОЛ, чтобы конкретно этот проект стал окрываться быстрее это пустая трата времени разработчиков ОЛ.
Зачем пытаться оптимизировать среду так, что бы она "быстро рисовала 500+ блоков", когда нет абсолютно никакого разумного объяснения в таком количестве блоков?
Лучше это же самое время потратить на блок "очередь", который и выглядит просто/понятно, и не потребляет лишних ресурсов ПР.


Поэтому я и спрашиваю какой _реальный_ случай, когда вам нужно 500 (или сколько там у вас) блоков в проекте. Если 500 блоков, и все отличаются только одним параметром, то это намекает на то, что в 428-ом будет опечатка или что-то типа того. Иными словами, это говорит о том, что должен быть какой-то более адекватный механизм выразить "полёт мысли".