Есть прибор МТР 8-15 фирмы "МИКРОЛ" Необходимо отобразить отрицательное значение на экране. Связь построена в таком порядке: "Источники/приемники->ModBus->RoutWord(3)---->канал Float---->Аргумент экрана (тип даных INT)----> ГЭ "Текст" формат отображения даных Generic. Вместо отрицательных значений - 65357, 65356 и т.д. В руководстве написано "INT (short) – целое со знаком размерностью 2 байта (-32768 ... 32767)"
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
В Modbus не отрицательных чисел. Их интепретация - функция пользователя. Канал Float превращает 16-битовое число в ЦЕЛОЕ_БЕЗ_ЗНАКА. Надо, видимо, использовать канал HEX16, который оба байта в чистом виде передаст в аргумент INT экрана.
Posted by orisil (Участник № / Member № 1377) on :
Использовал HEX16. Ничего не меняется вместо -1 значение 65536. Может еще какие варианты кто подскажет? Контроллер выдает при положительных значениях измеряемой величины числа от 0000Н до 7FFFH, а при отрицательных значениях от FFFFH до 8000H (как повсеместно принято). Но, к сожалению, Trace Mode не может перевести это отрицательное значение в 16-ричной форме в соответствующее десятичное число. К примеру, при считывании с контроллера числа FFFBH (что соответствует -5), на экран выводится значение 65531. Как быть?
Posted by Romсheg (Участник № / Member № 3792) on :
AdAstra Technical Support: "В Modbus нет отрицательных чисел." А вы в курсе, что вообще в цифровой технике, коей являются все вычислительные устройства, вообще понятие отрицательного числа нет? И именно поэтому во всем мире принят единый стандарт представления таких чисел, который ТМ6 почему-то упорно отрицает, утверждая что так не бывает, не бывает, потому что мы так захотели. Может все же перестанем отрицать очевидное и примем это как проблему, а не как частный случай? Ведь он не единичен.
2orisil: Я сам в недавнем проекте с таким столкнулся. Вывернуться пришлось так: написал алгоритм, который анализирует диапазон входного значения канала, и если он зашкаливает за пределы 32768 - делаю простое вычитание из этого значения 65536, получается вполне приемлемый отрицательный результат. Вешаете этот алгоритм на Трансляцию всех каналов, которые у вас по Модбасу могут отрицательные значения считывать. По сути придется сделать руками аналог того, что ТМ6 должен делать при преобразовании типов.
Posted by orisil (Участник № / Member № 1377) on :
2Romcheg: Дело в том, что над алгоритмом я тоже думал. В самом алгоритме ничего сложного, но... Количество каналов ключа исполнительного модуля на пределе, а в ситуации с алгоритмом количество каналов удваивается, то-есть для программы нужен канал связанный с источником-приемником и канал с уже обработаным выходным значением
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Самое простое средство - считать значение канала HEX16 на экран через аргумент INT и в ГЭ "Текст" задать формат представления %hd.
Posted by A40 (Участник № / Member № 3999) on :
quote:Отправитель / Originally posted by orisil: то-есть для программы нужен канал связанный с источником-приемником и канал с уже обработаным выходным значением
Не нужен. Используйте свойство "вызов" числового канала, связанного с источником данных.
Posted by Romсheg (Участник № / Member № 3792) on :
2orisil: Дело как раз в том, что не надо канала дополнительного под алгоритм - алгоритм вешаете на Трансляцию того канала, что с источником/приемником связан. Посмотрите хэлп на предмет, что такое "Трансляция" - тогда станет понятно о чем я.
2AdAstra Technical Support: Это решение - "костыль" ТОЛЬКО для отображения на экране. Но вообще-то системы АСУ не только циферки на экране показывают, они еще и в алгоритмах их используют. Posted by orisil (Участник № / Member № 1377) on :
Спасибо AdAdstra за "считать значение канала HEX16 на экран через аргумент INT и в ГЭ "Текст" задать формат представления %hd." Как быть с ГЭ "Тренд", ведь там HEX16 отображается не совсем корректно и формат представления %hd не работает. Почему в "СПРАВКЕ" нет такого формата отбражения?
2Romcheg: в моем случае значения не нуждаются в програмной обработке. Только отбражение и архивирование в трендах. За "Трансляцию" отдельное СПАСИБО!!! удастся сильно сэкономить на каналах в других алгоритмах обработки.
Posted by Romсheg (Участник № / Member № 3792) on :
2orisil: только учтите, что Трансляция "рвет" канал пополам, то есть - если у вас алгоритм не обеспечивает прямую или логическую связь атрибута Реальное и Аппаратное, то значение в канале с Трансляцией дальше Аппаратное (для канала Input и Реальное для Output) никуда не уйдет. Учитывайте это, если будете использовать Трансляцию канала для программ, которые к этому каналу отношения не имеют. Posted by orisil (Участник № / Member № 1377) on :
Создал алгоритм по рекомендации Romcheg. В профайлере меню "компоненты" - все как положено (к примеру [001] 65493 A соответствует [000] -43 R. Реальное значение канала привязано через аргумент INT к ГЭ "Текст" и к ГЭ "Тренд". "Тренд" отобржает "65493" всегда. "Текст" отображает "-43" только если задать формат отображения %hd. Вовсех остальных случаях ничего не поменялось - "65493..."
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Предложенный алгоритм будет адекватен только в канале FLOAT.
Posted by Romсheg (Участник № / Member № 3792) on :
2AdAstra Technical Support: А вот такое надо в базу ошибок заносить, если аргументу указан явный тип данных со знаком (INT - это знаковый тип), то там хоть HEX16 канал будь на входе с отрицательным значением в виде 0xFFFF на экране это должно быть везде отрицательным значением. Иначе преобразование типов в системе, откровенно говоря - глючит. Иначе какой тогда смысл в типах аргументах: INT, UINT, DINT, UDINT и прочих? Это во-первых. А во-вторых - системе давно уже нужны улучшения по каналам типа HEX - нужен флаг является ли значение отрицательным или беззнаковым. Если целочисленные НЕХ16 еще можно FLOAT-каналом заменить, то для HEX32 - это уже не пройдет никак.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Мы учтем Ваше замечание.
Posted by Технолог Петухов (Участник № / Member № 4283) on :
..можно я тут близко к теме спрошу..
Вот запрашиваю RinWord(4) подряд 6 штук. Уходит запрос типа "прислать с 0-го адреса 6 регистров". Если ответ от девайса приходит , то всё нормально.
Если устройство НЕ отвечает, кроме вышеописанного запроса начинают уходить последовательно: "прислать с 1-го адреса 5 регистров" "прислать с 2-го адреса 4 регистров" ... и т.д. до "прислать с 5-го адреса 1 регистр"
Спрашивается- это нормально ? Как-то можно управлять этим размножением запросов?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
От темы топика это очень далеко. Да, такая ситуация является типичной для драйверов, формирующих групповые запросы через числовые каналы. Чтобы этого избежать, формируйте групповы запросы Modbus с помощью каналов CALL.ChGroupReq, привязанных к переменной Modbus с начальным адресом группы.
![[Усмешка / Big Grin]](biggrin.gif)
И именно поэтому во всем мире принят единый стандарт представления таких чисел, который ТМ6 почему-то упорно отрицает, утверждая что так не бывает, не бывает, потому что мы так захотели. Может все же перестанем отрицать очевидное и примем это как проблему, а не как частный случай? Ведь он не единичен. ![[Пдмигивание / Wink]](wink.gif)
![[Улыбка / Smile]](smile.gif)