Opened 3 months ago

Closed 3 months ago

Last modified 3 months ago

#669 closed баг (fixed)

Не корректно отображается отрицательный ток утечки плат RP-400 и RP-650

Reported by: AlexLir Owned by: alx
Priority: средний Milestone: 1 очередь
Component: web-интерфейс (sw) Keywords:
Cc:

Description

Согласно ТЗ #627, переменная 18.0 должна интерпретироваться как знаковая, однако в r2345 отрицательное значение отображаются не корректно(как положительное)

Change History (14)

comment:1 by alx, 3 months ago

Прошу сообщить способ кодирования отрицательных значений, используемый в переменной .18.0 плат RP-400 и RP-650.

comment:2 by AlexLir, 3 months ago

Способ кодирования отрицательных значений переменной .18.0 - дополнительный код

comment:3 by alx, 3 months ago

Resolution: fixed
Status: newclosed

In 2350/sw:

Исправлена ошибка в веб-интерфейсе: отрицательные значения
тока утечки плат RP-400 и RP-650 отображались как положительные.
Closes #669.

comment:4 by alx, 3 months ago

Уже не первый раз возникает необходимость запрашивать из плат знаковые значения, и каждый раз для этого приходится добавлять всякий хитрый код, как в данном случае. А все потому, что в протоколе обмена с платами при указании типов переменных не подумали о знаке (не предусмотрели знаковых типов).

Как думаешь, имеет смысл дополнить протокол знаковыми типами целых чисел?

comment:5 by san, 3 months ago

Уже не первый раз

Да вроде бы не так и много таких значений в платах, температуры и токи в платах питания, да и всё.

Гораздо чаще встречаются числа с фиксированной точкой, которых тоже нет в протоколе.

in reply to:  5 comment:6 by alx, 3 months ago

Replying to san:

Гораздо чаще встречаются числа с фиксированной точкой, которых тоже нет в протоколе.

Как это нет? Все имеющиеся числовые типы - как раз с фиксированной точкой. Вот как раз чисел с плавающей точкой у нас нет. Но вроде бы и потребности в них пока не встречалось...

comment:7 by san, 3 months ago

Ну я в том смысле что сама позиция точки не передаётся вместе со значением.

in reply to:  7 comment:8 by alx, 3 months ago

Replying to san:

позиция точки не передаётся вместе со значением.

Она потому и не передается, что позиция фиксирована.

Числа с фиксированной точкой хранят только мантиссу. Числа с плавающей точкой хранят и мантиссу, и порядок (положение точки). Чисел с плавающей точкой у нас не предусмотрено.

comment:9 by san, 3 months ago

Ну чтобы корректно вывести число с фиксированной точкой, нужно знать её положение. Мы могли бы добавить в протокол тип данных который хранит и мантису и порядок в представлении с фиксированной точкой.

in reply to:  9 comment:10 by alx, 3 months ago

Replying to san:

Мы могли бы добавить в протокол тип данных который хранит и мантису и порядок

Это называется число с плавающей точкой. Добавить?

comment:11 by san, 3 months ago

Нет, я именно о числах с фиксированной точкой. Например, значение 12.44 В. сейчас мы передаём как двухбайтное значение 1244, и в веб интерфейсе гвоздями забито, что последние 2 разряда этого значения нужно отделить в дробную часть. А могли бы передавать как байт целой части (12) и байт дробной части (44), тогда бы значение сразу отображалось правильно.
Но я тут вспомнил что мы те-же значения передаём ещё и в SNMP, где подобного типа нет, так что предлагаю оставить как есть.

in reply to:  11 comment:12 by alx, 3 months ago

Replying to san:

Нет, я именно о числах с фиксированной точкой.

Числа с фиксированной точкой у нас заложены в протокол с самого начала, еще ~11 лет назад. Единственное упущение - там ничего не говорится о наличии или отсутствии знака. Де-факто существующая реализация трактует их как беззнаковые (то есть представляющие лишь числа от нуля и больше).

Например, значение 12.44 В. сейчас мы передаём как двухбайтное значение 1244, и в веб интерфейсе гвоздями забито, что последние 2 разряда этого значения нужно отделить в дробную часть. А могли бы передавать как байт целой части (12) и байт дробной части (44), тогда бы значение сразу отображалось правильно.

??? Так оно и сейчас сразу отображается правильно...

Ты сейчас, насколько я понял, говоришь о другом - о разных вариантах представления одного и того же числа (двоичный, двоично-десятичный и т.п.). Я не вижу никакого практического смысла в использовании представлений, отличных от двоичного. Только лишняя работа по перекодированию...

Но я тут вспомнил что мы те-же значения передаём ещё и в SNMP, где подобного типа нет,

Подобного чему? Двоично-десятичному? Наверное нет. А чисто двоичные числа с фиксированной точной там есть.

так что предлагаю оставить как есть.

Так мой-то вопрос был не о новом формате представления существующего типа, а о новом типе (знаковом)!. А в SNMP как раз есть знаковые и беззнаковые типы...

comment:13 by san, 3 months ago

??? Так оно и сейчас сразу отображается правильно...

Нет, если разработчик платы не сообщит где стоит точка, то отображаться число будет как 1244, а не как 12.44. По нашему протоколу передаётся только мантисса и без дополнительного уточнения от разработчика невозможно узнать положение точки.

in reply to:  13 comment:14 by alx, 3 months ago

Replying to san:

??? Так оно и сейчас сразу отображается правильно...

Нет, если разработчик платы не сообщит где стоит точка, то отображаться число будет как 1244, а не как 12.44.

Почему 1244? Почему не 1244000? Почему не 1.244? Почему на 0.00001244? Разработчик платы же не сообщил, где точка! На самом деле отображаться может как угодно. :)

Ты здесь опять говоришь не о том. Формат фиксированной точки предполагает, что положение точки (ну или порядок) заранее известно, поэтому его и не требуется указывать в представлении значения. В данном же примере ты говоришь, что позиция точки неизвестна (разработчик не сообщил). В этом случае числа с фиксированной точкой использоваться не могут, в каком бы формате значение не было представлено. В подобном случае правильно отображено может быть только число с плавающей точкой, так как положение точки указано в его представлении.

Но, ты уже высказал мнение, что типы с плавающей точкой нам не нужны...

Note: See TracTickets for help on using tickets.