Вид для печати
Мне нужно перевести 4 байта (16#40 00 00 00) в формат REAL
Так как порядок следования байт в REAL для СПК перепутан, пробую так:
dword_to_real(16#4000)
По идее это должно мне дать значение real равное 2.0 , но это не так.
Получается что dword это такой же числовой тип как и uint!
Спрашивается, зачем нужны два одинаковых типа?
И существует ли в ST оператор, который может нормально перевести 16#4000 в real = 2.0 ?
По сути, мне нужно решить задачу: корректно перевести переменную типа dword в real не используя память данных М в языке ST.
Это вообще реально?
На форуме уже не раз выкладывался пример получения переменной типа REAL в СПК. Просто оператора нет, нужно написать функцию перестановки байт.
Байты уже переставлены. Мне реал получить надо.Цитата:
Сообщение от _Mikhail
Разве возможно написать такую функцию на ST?Цитата:
Сообщение от capzap
Где она будет хранить значения при перекидывании байт? (М память не предлагать)
Функциональный блок тут конечно справится. Но это как из пушки по воробьям.
Почему в других системах dword_to_real нормально работает, а в КДС так убого?
Даже документации по dword_to_real нет.
По стандарту он не числовой ни разу, но ощущение, что на это забили вообще все.Цитата:
Получается что dword это такой же числовой тип как и uint!
DWORD_TO_REAL делает как раз числовое преобразование. Вам нужно реинтерпретировать байты через указатель:
d: DWORD;
ptrReal: POINTER TO REAL;
r: REAL;
ptrReal := ADR(d);
r := ptrReal^;
Будь у меня свой кодесис, я бы запретил на фиг арифметику и неявные преобразования в число для типов, которые имеют в своём названии WORD, чтобы вот этой путаницы не возникало. И сделал бы операторы вроде DWORD_AS_REAL, чтобы обходиться без указателей.
1. Конечно написать можно. Она очень простаяЦитата:
Сообщение от @ND
Вложение 19415
2. Функция не хранит данные, она пересчитывает и выдает результат
3. Хотите ФБ пожалуйста, только для этой задачи достаточно функции
Siemens step7
DWORD_TO_REAL(W#16#40000000) даст 2.0
Тогда у Сименса логичнее. В кодесисе бред, с которым придётся смириться через указатели.
Пометка на полях: из Кодесиса в Степ7 код не копипастить.
Спасибо за своевременную помощь. Недооценил я указатели.
А на счёт DWORD_TO_REAL , разработчикам КДС минус.
Это уголовно наказуемо? :)Цитата:
Сообщение от Yegor
Да и зачем. Там эта плюшка из коробки работает.
Ну вообще то это логично подавать на вход число, характеризующую величину переменной процесса.Цитата:
Сообщение от capzap
Как раз не логичнее там было бы видеть ворд.
Тут немчура конечно отчудила. Ставя по умолчанию на физ вход ворд. Но его ни кто не запрещает поменять на инт, прямо там же в настройках модуля ввода.Цитата:
Сообщение от capzap
Я пользуюсь.Цитата:
так если DWORD-ами никто не пользуется Вам то это зачем
Особенно когда много приходится работать с коммуникациями.
Удобно биты выделять, байты переворачивать и прочее.
Тут например я хотел сначала воспользоваться такой конструкцией:
DWORD_TO_REAL(ROL(%ID0, 16)) чтоб получить местный реал.
А приходится писать костыль на указателях.
Не люблю начинать знакомство с костылей. :)
Я имел в виду разбор телеграмм от различных устройств. (много приходится работать с протоколом модбас рту).
1. Ну и что, что в документации есть Union. Dword_to_real то нет. То бишь документация не полная.
2. Разницу между преобразованием и интерпретацией прекрасно понимаю, разве с самого начала не было понятно что мне нужно интерпретировать набор 4х байт в реал?
3. String_to_real в Step7 вообще нет. Так же не понял на счёт убожества: интерпретировать реал из 4х байт предварительно поменяв два ворда в них коротенькой строкой - что тут плохого или убогого?
4. UINT - числовой тип, DWORD - это не числовой тип. И я всегда привык работать с DWORD, как c не числовым типом. Потому то меня и выбило из колеи, когда DWORD_TO_REAL(16#1) дал мне 1.0
5. В MODBUS RTU телеграммы - это набор байт. Если мне удобно для работы с этими байтами пользоваться различными бинарными операторами и интерпретировать с помощью DWORD_TO_REAL в случае STEP7, то почему бы и нет?
В данном случае костылём является как раз UNION. ("Многабукв" за вместо одной строки)Цитата:
Ничего. Вы сами себе выбрали "костыли" (C)
Поиск по "DWORD_TO_REAL" никто не отменял. Результат 0 topic(s) found.Цитата:
Т.е. Вы утверждаете что прочитали весь хелп ?
Ну остальные участники форума то поняли, зачем так цепляться?Цитата:
Нет, непонятно что Вам нужно. Мелофон поломался
На счёт понимания:
Валенку не понравилось что я за вместо слова "интерпретировать" слово "перевести" использовал. Согласен, не точно выразился. Но ведь по смыслу то, меня ведь правильно поняли, что мне нужна интерпретация 4х байт в реале, и правильно предложили написать функцию с использованием указателей.
Ну REAL занимает 4 байта, значение REAL можно интерпретировать, указав на на DWORD, или на два WORDа, или четыре байта, или 32 бита. Просто я выбрал одновесные типы вот и всё.Цитата:
всё хотел узнать зачем Вам дворд
Пример из использования в Step7
Когда телеграммам прилетает на порт, она ложится в определенный DBxxx, по определенному адресу.
И если мне нужно интерпретировать REAL c 4х байт начиная с 200 адреса я пользовался следующей конструкцией:
real_var := DWORD_TO_REAL(DBxxx.DBD200);
int_var := WORD_TO_INT(DBxxx.DBW200); для интерпретации инта соотвтетственно.
Коротко и удобно.
Ну в один момент времени там реал лежит, а в другой там может вообще какие нибудь дискретные сигналы лежат. Особенно если устройств опроса несколько или когда количество и качество запросов может меняться со временем.Цитата:
почему сразу не реал?
Или может быть я не правильно понял. Как это сразу REAL ?
Предложите пример.
А если мне нужно будет порядок байт для REALа поменять или на коэффициент умножить?Цитата:
Сообщение от capzap
А считывать мне нужно одной большой телеграммой, в которой есть как использующиеся данные так и нет и лежать они могут там с разрывами.
Так же производители устройств с поддержкой MODBUS протокола могут разместить realы таким образом, что они будут отстоять друг от друга скажем на один байт, тогда у вас вообще не получится их прописать как реалы.
Вот к примеру программа для одного соединения в STEP7
Дело еще в том, что этот код у меня пишет скрипт на VBA, и мне гораздо удобнее не заморачиваться со структурами, тем более еще с преобразованиями к этим структурам.
Мне гораздо удобнее, когда одна строка соответствует записи в один тег.
Да нет конечно.Цитата:
и во всем виноват S3 software
Ну просто получается в STEP7 есть интерпретаторы типа DWORD_TO_REAL, WORD_TO_INT, ... и.т.д. так сказать из коробки,
а в КДС их нет. А ведь это хороший, достаточно нужный инструмент.
А где прослеживается логика, когда 16#1 переводится как 1.0 ? Учитывая, что DWORD это вообще не числовой тип.Цитата:
в КДС есть чтоТоТам_TO_чтоТоЕще, как оказалось с разницей, что степ DWORD переводит в REAL согласно IEEE745 только ради удобства а не логики
А кто сказал что DWORD не целочисленный тип ?
В Help КДС :
"
Integer Data Types
BYTE, WORD, DWORD, SINT, USINT, INT, UINT, DINT, and UDINT are all integer data types
Each of the different number types covers a different range of values. The following range limitations apply to the integer data types:
И чего полемику устраивать ?
А вот для ПЛК известных брэндов , работающих под языком LD есть мощнейший оператор MOV , который безусловно и безоглядно перенесет откуда нужно куда нужно , заменяя указатели Кодесис . Но никому в голову не приходит пенять кодесис за отсутствие "MOV" .
Организация памяти не та .
Стандарт сказал:Цитата:
А кто сказал что DWORD не целочисленный тип ?
Вложение 19423 Вложение 19424
Арифметические операции не определены для битовых строк:
Вложение 19425
Битовые операции не определены для числовых типов:
Вложение 19426
Добавлю терминов.
То, что требовалось ТС - typecast (приведение типов). Из целей безопасности кода typecast напрямую запрещён в CoDeSys. Искать лень, но это прописано где-то в начале изучения CoDeSys. Поэтому такие сложности - чтобы не случайно, а осмысленно выполнялось.
Не соглашусь. Приведение типов разное бывает. Кодесисовские X_TO_Y это вполне себе явные приведения. Если с Си++ аналогию проводить, то это static_cast. А автору надо reinterpret_cast. Вот по-русски очень кратко: http://habrahabr.ru/post/106294/
Приветствую форумчане, все заставил работать связь между СПК 107 и Lеctus OPC есть работает, но может кто сталкивался с таким, что данные с СПК выходят одни а уже Lectus....Application, Real_WORD_29, прописан код: TYPE REAL_WORD_29 :
UNION//
awModbusReal :ARRAY [0..1] OF WORD;
rRealValue :REAL;
END_UNION
END_TYPE
Кроме вас наверное никто не поймет, где тут вопрос.Цитата:
Сообщение от VladimirZHTEC
можете подсказать как разбить REAL на WORD? проблема такая.... данные на СПК 107 формируются в типе REAL, Modbus_TCP_Slave формируется в данные WORD.... но значения одинаковые Lectus показывает вообще какие-то левые цифры, пробовал перебрать разные регистры и байты в Lectus, картина не как не меняется по советовали разбить REAL на 2 word.... но как это сделать пробывал так и не понял... подскажите
Добрый день, рассмотрите в качестве примера файл во вложении.Цитата:
Сообщение от VladimirZHTEC
Тут скрины, как передавать в том числе REAL, как собрать и разобрать REAL на 2 WORD.Цитата:
Сообщение от VladimirZHTEC
3 скрин
https://owen.ru/forum/showthread.php...445#post455445