Подсветка переменных записываемых в конце цикла

[Сергей0308]

!?


Угу. Делать разные функции для 16 и 32, настраивать для 32 бит, для 16 бит - это же не извращение.
А через real делать базовые машиные операции - так это вообще нормуль нормулёв.

Ну, это "плата" за универсальность, в смысле никто не запрещает создать отдельные макросы для каждого диапазона!

В моём варианте это минимальная плата, всего один SEL:

Плата за универсальность.PNG

Что сводит к минимуму необходимость в отдельных макросах!

Мне кажется один из самых универсальных вариантов для расчёта отрицательной части диапазона Пётр из Минска предлагал, в смысле, инверсия(кода числа) + 1, получается значение отрицательного числа по модулю, я свой вариант предложил, мне он проще показался!

[kondor3000]

Ну, это "плата" за универсальность, в смысле никто не запрещает создать отдельные макросы для каждого диапазона!
Что сводит к минимуму необходимость в отдельных макросах!

Мне кажется один из самых универсальных варианта Пётр из Минска предлагал, в смысле, инверсия + 1, получается значение отрицательного числа по модулю, я свой вариант предложил, мне он проще показался!

Если есть функции для 32 битных, типа DINT, то как сказал Валенок, для 16 битных они не нужны. Скрин 1 Передача через 1 регистр.jpg
Вы передаёте 1 регистр если число меньше 65535 и через 2 регистра если больше и 32 битными функциями работаете с любыми переменными.
На скрине передан 1 регистр, а функции 32 битные. На ST функции универсальные, выложил выше. Переключатель делать не стал, хотя это возможно.

[Сергей0308]

Если есть функции для 32 битных, типа DINT, то как сказал Валенок, для 16 битных они не нужны. Скрин 1 Передача через 1 регистр.jpg
Вы передаёте 1 регистр если число меньше 65535 и через 2 регистра если больше и 32 битными функциями работаете с любыми переменными.
На скрине передан 1 регистр, а функции 32 битные. На ST функции универсальные, выложил выше. Переключатель делать не стал, хотя это возможно.

И Вы считаете что эти преобразования проще чем один SEL?

[Dimensy]

Легко.
(откудато - извне) Т.е. заполнить биты 16..31й 15тым. И всё.
Обратно - не требуется

То же непонятно. В любом случае либо приемная часть должна знать разрядность передающей части, либо передающая часть знать разрядность приемной части и подстраиваться под нее. Так почему сразу не указать, что у нас 16 бит или 32.

[Сергей0308]

Если взять из слейва нужно int16, то int16_to_int32 и работаете c int32
Если отправлять в слейв нужно int16 - то работаете и кладете int32 и всё (уже сказали же)
Если взять из слейва нужно int32 - то склеиваете. Во всех вариантах. Включая Ваш. Но т.к там лежало int32 то и работаете c int32 как и выше.
Если отправлять в слейв нужно int32 - то кладете части. Во всех вариантах. Включая Ваш. Но т.к нужно отправлять int32, то и работаете c int32 как и выше.

Т.е. int32 подойдет во всех случаях, а int16 - в некоторых. (Дальше про стиральный порошок который лучше)

Вроде понял, что Вы хотите! В смысле всегда использовать один макрос DINT(INT32)_TO_FLOAT. Если надо преобразовать INT(INT16), то предварительно преобразовываете его в DINT(INT32).
Короче, мне кажется это не очень логичным, в смысле, чаще всё-таки INT(INT16) встречается, а DINT(INT32) намного реже. Вам надо всё равно знать, что это INT(INT16), иначе правильное преобразование невозможно, уже писал об этом, даже пример приводил! И, мне кажется в FBD проще значение INT(INT16) сразу преобразовать во FLOAT, чем ваше промежуточное преобразование в DINT(INT32). Если Вы говорите в ST это проще, поверю Вам на слово(я в ST не шарю), но это получается частный случай, не более!

[Сергей0308]

В обратно особой надобности нету.


.. то при любых* вычислениях с int32, младшее слово всегда содержит int16 (а биты 16..31 (int32-ого) всегда повторяют 15-й)
*Даже если какие-то промежуточные выходили за рамки int16 (но были в рамках int32)

a : int16 = 1000;
b : int16 = -1000
c : int16 = 10000

x := (a * b) / c
//(1000 * -1000) / 10000 = -100 (int16)

В рамках int16
1000 * -1000 => -16960
-16960 / 10000 => -1

В рамках int32
1000 * -1000 => -1000000
-1000000 / 10000 => -100 (FFFFFF9C) int32 => (FF9C) int16 => -100

На форуме много раз говорили, что математические действия с переполнением будут верными, рискнул так сделать, тогда функция упростится, станет одной для разных действий, короче, вроде правильно считает(сильно не проверял), заодно и "причесал":

INT-DECOD_1.png

INT-DECOD_2.png

INT-DECOD_1.owle