Ничто не мешает, у меня так и сделано(меняется в свойствах макроса), не понятно как они хотят проще сделать, вроде проще некуда?Сообщение от AI!
Ничто не мешает, у меня так и сделано(меняется в свойствах макроса), не понятно как они хотят проще сделать, вроде проще некуда?
Последний раз редактировалось Сергей0308; 04.10.2016 в 15:55.
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
нет не пользовался, но в этой ситуации я исходил из концовки диалогакак Вы заметили взять несколько экземпляров одного макроса и изменить в каждом экземпляре значения константтут они каким то образом поменялись местами, ведь именно Сергей держит базу макросов, чем то напоминающую среды разработки с контролем версийполучается макрос однотипный, но вы хотите чтобы в нем переменные были разные. Тогда и надо идти по поти создания нового макроса, в нем назначать для каждого свои переменные и макросы называть новыми именами
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Может Вы мой проект не смотрели, терпения не хватило, так вот там я и использую экземпляры одного макроса, а в свойствах ставлю нужное значение констант для каждого экземпляра, а как Вы говорите вместо 16 экземпляров одного макроса использовать один с оперативно изменяемыми константами(получаются переменные) боюсь так невозможно, по крайней мере в данном случае, если пойти чуть дальше в вашей логике не имеет смысла иметь более одной ячейки памяти, меняй ей номер и все дела, может в армии подобные методы военной хитростью называются, а здесь боюсь это не прокатит, это так к слову!
Последний раз редактировалось Сергей0308; 04.10.2016 в 23:23.
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
Сергей, но, согласитесь, это пример дичь-программирования?
Поразвлекаться и сделать "эдакое" -- вполне.
А просить доработки среды из-за того, что "дичь-программированием неудобно заниматься", на мой взгляд, странно.
Есть какой-нибудь более жизненный пример, в котором нужны предлагаемые доработки/улучшения макросов? Если будете показывать на живом примере, то будет доходчивее: "вот проект", "вот приходится делать так-то", "если бы можно было улучшить это, то стало бы тут проще".
Очень не удобно, не 16 экземпляров одного макроса нарисовать, а менять значения констант из свойств макросов, не то что их много(512), а программа сильно тормозит, долго думает, перед тем как я могу следующую константу изменить и не известно будут они работать в железе, поэтому наверно лучше подобное обходить или может на ПЛК мастерить, короче удобств мало, но мне нравится!
Лично для меня наивысшая дичь программирования, это когда программу буквами и знаками разными непонятными пишут, кажется язык ST называется, и говорят посмотрите здесь все проще и понятней чем на CFC(язык такой для программирования), это меня просто шокирует, дурдом, мягко выражаясь!
Последний раз редактировалось Сергей0308; 04.10.2016 в 23:34.
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
Смотрите: на мой взгляд, "правильное" решение конкретной задачи заключается не в применении 16 макросов внутри 16 макросов (ну или сколько там у вас).
На мой взгляд, решению конкретной задачи и кучи других задач поможет простой блок: "линия задержки на N тактов".
Т.е. мы в неё подаём входные значения и тактовый вход, а она на выходе выдаёт числа с задержкой на указанное количество тактов (это количество должно указываться, например, как указывается задержка у TON блока).
Тогда задача "скользящее среднее" на "500" или сколько там нужно будет решаться просто:
1) Сумматор, на который подаются входные числа
2) Сумматор, на который подаётся выход "линии задержки"
3) Разница между этими сумматорами и будет "суммой в окне".
Всего 3-4 блока, на которых ОЛ будет просто летать.
Да, гусары заметят, что при подобном подходе и использовании float'ов может возникнуть погрешность, но оставим эту лирику.
С точки зрения среды (ОЛ) это будет всего один блок -- т.е. не будет тормозов при попытках редактирования 500 блоков и связей.
Сам же блок задержки на аппаратном уровне тоже просто реализовать. Нужно просто выделить массив на нужное количество ячеек и использовать их по кругу.
И реализация простая, и в железе будет быстро работать (всего 5-10 команд процессора на одно срабатывание очереди), и программировать легко, и, немаловажно, блок линии задержки может много где пригодиться.
Ещё вариант решения подобных проблем -- "функциональный блок массива".
Ну, объявляем блок "массив, указываем количество элементов". И потом с помощью каких-нибудь спец блоков записываем значения в ячейки или читаем оттуда.
На мой взгляд, пытаться оптимизировать ОЛ, чтобы конкретно этот проект стал окрываться быстрее это пустая трата времени разработчиков ОЛ.
Зачем пытаться оптимизировать среду так, что бы она "быстро рисовала 500+ блоков", когда нет абсолютно никакого разумного объяснения в таком количестве блоков?
Лучше это же самое время потратить на блок "очередь", который и выглядит просто/понятно, и не потребляет лишних ресурсов ПР.
Поэтому я и спрашиваю какой _реальный_ случай, когда вам нужно 500 (или сколько там у вас) блоков в проекте. Если 500 блоков, и все отличаются только одним параметром, то это намекает на то, что в 428-ом будет опечатка или что-то типа того. Иными словами, это говорит о том, что должен быть какой-то более адекватный механизм выразить "полёт мысли".
Спасибо! Посмотрю!
Типа того?
Среднее скользящим окном.PNG
Здесь ещё проще, сумматор один, сначала суммирует количество значений, равное длине стека, затем разницу между текущим и последним в стеке и делит на количество разрядов стека, это вроде уже обсуждали для упрощения расчёта среднего скользящим окном?!
http://www.owen.ru/forum/showthread.php?t=23201&page=9
Как бы спорить бессмысленно, алгоритм упростится!
Практически не знаю кому это может понадобиться, только Алексей Геннадьевич вроде писал, что надо подобное при ПНР, лично мне в ближайшие 700 лет не понадобится(более 2 лет прошу 10м провода ПВС 3х0,75мм2), так зарядка для мозгов и может чем другим людям поможет, люди же разные бывают!
Последний раз редактировалось Сергей0308; 05.10.2016 в 01:51.
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
Спасибо конечно, теперь пытаюсь осознать в чём вся революционность идеи, признаюсь пока плохо получается!
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
А вот с обратными связями беда бедовая...
Если макрос AI! - SelChange вставить внутри первого CRab1w как есть, то все линии 1-го входа начнут работать по обратной связи.
Даже если использовать в макросе алгоритм будет тоже самое.
А вот 2-ная обратная связь ставит все на свои места....
Может разработчики объяснят как это происходит ?
Последний раз редактировалось melky; 08.10.2016 в 18:15.
как то реально перевести ол на шестнадцатеричную систему???
Ваши права
