Собственно так и сделал, еще вчера, спустя пару минут после сообщения на форуме. Умные мысли приходят после :-)
Screenshot_2.png
Собственно так и сделал, еще вчера, спустя пару минут после сообщения на форуме. Умные мысли приходят после :-)
Screenshot_2.png
Так у Вас всего семь аварий, а макрос для большого количества аварий я придумывал(для подсчёта количества бит в состоянии "1" в целочисленной переменной), впрочем это не помешает его использовать для семи аварий, вот добавил в проект макрос вставки бит, до восьми бит, вам должно хватить, ранее был на 16 бит и все эти макросы с расширением, для этого у них верхний целочисленный вход "Х" и настройки в свойствах макроса:
Сумматор бит_3.PNG
Сумматор бит_2.owle
Последний раз редактировалось Сергей0308; 19.02.2023 в 20:11.
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
Этот вариант тоже интересен (если бы ST в ПР мог делать AND)
изображение_2023-01-27_084750763.png
Валенок по идее все штатные функции в ST коде должны работать так же, как и FBD на холсте, и если AND и остальное не может работать с целочисленными так же, то это косяк реализации.
melky, то что хотелось бы - и я не против (о чем сказал ранее) - п#2837
Учитывая реальность (нет битовой логики, надеюсь - пока) и применительно к заявленной задаче (посчитать биты), то какой смысл в сложных алгоритмах и тем более на FBD. Чего там выгадывается ? Якобы производительность ? Это в п#2836-то, который на FBD т.к. нет битовых в ST ? )))
2й алгоритм статьи (и в #2843) - стандартный и кошерный, и быстрее лобового цикла в отдельных случаях (типа 8000_0001h). Но :
1. Только для какой задачи для ПР это "быстрее" будет иметь значение ? (говорил в п#2837)
2. Опять же требует битовую логику которой нет
Поэтому я предложил шаг назад - лобовой цикл. как легко реализуемый, понятный и я бы посоревновался по скорости с п#2836.
Смысл вопроса п#2844
Если же в каких-то специфических алгоритмах требуется именно битовая логика и именно в ST, то (как временная мера) несложно организовать соотв. ST-функции (and/or/xor/not) для udint. Что бы дождавшись версии 783 просто выкинуть эти эрзацы и поставить чистые битовые логики.
Хотеть не вредно, но зачем же организм насиловать ожиданием, в моём макросе как раз по второму варианту подсчитываются единичные биты, единственное различие - подсчёт начинается не с младшего единичного бита, а со старшего, но это же не принципиально(не имеет значения), с какой стороны начинать подсчёт единичных бит!
Короче, к ПР эти методы, с целью ускорения подсчёта не относятся, здесь уже писали как максимально быстро, в смысле, за один цикл ПР можно все единичные биты пересчитать!
Последний раз редактировалось Сергей0308; 27.01.2023 в 22:41.
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
вопрос не в хотелках, тут другое, что хотели Овен сделал, но как всегда не до конца. Еще раз для понимания, FBD в приборе давно, AND, OR, NOT, XOR в нем может работать с целочисленными переменными. Запилили ST - эти же блоки не умеют работать с целочисленными.
Для мозгов ПР все равно на чем ему говорят выполнить AND и далее, соответственно проверка уровнем выше, которая хромает.
Согласен, надо закруглятся с этим, в смысле, попробовали - не получилось, может это не их сильная сторона, в смысле, таланта нет, можно попробовать себя в другом деле, вдруг всё на ура пойдёт, в смысле, тогда это направление и развивать будете, а все вокруг любоваться и завидовать вашим успехам и достижениям!
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.