Показано с 1 по 7 из 7

Тема: Вопрос по протоколу OWEN (разбор ASCII текста на PRESENTATION LAYER)

  1. #1

    По умолчанию Вопрос по протоколу OWEN (разбор ASCII текста на APPLICATION LAYER)

    Я реализую OWEN стек по документации "ОПИСАНИЕ протокола обмена между ПЭВМ и приборами ОВЕН", застрял на пункте 5.1.5 "Строковый тип"

    Конкретно, я отправляю пакет на получение "dev":
    0000 23 47 4b 48 47 54 4d 4f 48 53 51 54 55 0d #GKHGTMOHSQTU.

    Addres : 4
    + : 0
    Remote : 1
    Size : 0
    Hash : 81d6 (LE: d681) (dev)

    получаю ответ:
    0000 23 47 4b 53 47 54 4d 4f 48 4a 47 4a 47 4a 49 53 #GKSGTMOHJGJGJIS
    0010 53 54 47 54 49 4b 4a 54 4b 0d STGTIKJTK.

    Где данные:
    0000 30 30 32 cc d0 d2 002...

    По описанию я должен получить что-то типа:

    0000 30 30 32 50 4d 54 002PMT


    Видно, что числа я получаю правильно, но вот буквы требуют какого-то
    дополнительного преобразования.
    Я не могу понять какого.

    Прошу помочь.

    В качестве бонуса указываю на ошибку в вашей документации "ОПИСАНИЕ
    протокола обмена между ПЭВМ и приборами ОВЕН".
    В разделе 6.2 "Команды смены сетевых настроек прибора" указан параметр
    "rS.dL" с hash 0x1e25, это не соответствует действительности.
    Параметр "rSdL" даёт hash 0x1e25.
    Последний раз редактировалось ASM; 01.12.2012 в 20:35. Причина: Ошибка в тексте

  2. #2

    По умолчанию

    Ответили: это кодировка CP1251.
    Тему можно закрывать

  3. #3

    По умолчанию

    Цитата Сообщение от ASM Посмотреть сообщение
    В качестве бонуса указываю на ошибку в вашей документации "ОПИСАНИЕ
    протокола обмена между ПЭВМ и приборами ОВЕН".
    В разделе 6.2 "Команды смены сетевых настроек прибора" указан параметр
    "rS.dL" с hash 0x1e25, это не соответствует действительности.
    Параметр "rSdL" даёт hash 0x1e25.
    Точка тоже учитывается при расчёте хэша, т.е. длина строки, по которой считается хэш будет 5 символов, а не 4. В документации скорее всего указан хэш 0xcbf5, а без точки действительно получается 0x1e25, но по нему нельзя будет получить значение параметра.
    Последний раз редактировалось vitug; 06.12.2012 в 22:09.

  4. #4

    По умолчанию

    В документации скорее всего указан хэш 0xcbf5,
    Нет, это не так. Об этом я и говорю.
    Более того, параметр 0xcbf5 девайс не ест, нужно указывать 0x1e25.

    Точка тоже учитывается при расчёте хэша
    Спасибо, КЭП. Но длина строки для расчёта HASH как была 4 буквы, так и останится.

    Пожалуйста, не нужно вставлять бессмысленных комментариев с Вашими догадками о том, что написано в документации. Более того выдавать за истину Ваши догадки (это про расчёт HASH по 5 символам).

    Прочитайте, пожалуйста, документацию если Вам интересна тема, и Вы хотите в ней поучавствовать.

  5. #5

    По умолчанию

    Цитата Сообщение от ASM Посмотреть сообщение
    Нет, это не так. Об этом я и говорю.
    Более того, параметр 0xcbf5 девайс не ест, нужно указывать 0x1e25.
    Тогда я действительно не понял, просто было бы лучше если бы вы написали, что в документации вместо имени параметра с точкой должно быть имя параметра без точки.

    Цитата Сообщение от ASM Посмотреть сообщение
    Спасибо, КЭП. Но длина строки для расчёта HASH как была 4 буквы, так и останится.
    А тут уже возможно вы ошибаетесь. Я читал документации и изучал исходники протокола, более того я использую эти исходники в работе. Дело в том, что вычисление хэша параметра происходит как бы в два этапа, сначала строковое имя параметра преобразуется в бинарное 4-х байтовое представление (а не четырех буквенное!) функцией:
    /* преобразование локального идентификатора в двоичный вид
    name - локальный идентификатор
    length - длина идентификатора
    id - идентификатор в двоичном виде
    */
    void name2id(char* name, size_t length, unsigned char id[4])
    Как видите во входном параметре нет ограничения на длину. Но реально длина не может быть больше 5 символов (цифры, буквы английского алфавита и '-','_','/'), причём допускаются только 4 символа, точка обрабатвается отдельно, увеличивая на единицу значение предыдушего байта, но может быть произвольное количество пробелов в конце. В общем в исходниках всё видно.

    А потом уже четырех-байтовое представление преобразуется в двух-байтовое.
    /* свертка локального идентификатора */
    unsigned short id2hash(unsigned char id[4])

    Поэтому символьное имя параметра может иметь длину больше 4-х символов, я с этим уже сталкивался и у меня как раз был обратный случай, когда я пытался посчитать хэш по 4-м символам, выбросив точку, но прибор его не "съел".
    Последний раз редактировалось vitug; 08.12.2012 в 09:54.

  6. #6

    По умолчанию

    Говорим об одно и том же разной терминологией.

  7. #7

    По умолчанию

    Вопросы терминологии всегда были самые сложные, ведь термины это хэши в которые мы пакуем наши мысли, но они не всегда правильно интерпретируются другой стороной Получается, что если разработчики ОВЕН захотят, они могут сделать 8-символьный параметр, скажем, "r.E.A.d." и его хэш будет 0x2db6
    Последний раз редактировалось vitug; 08.12.2012 в 12:42.

Похожие темы

  1. Разбор текстового сообщения
    от vasylye в разделе Помощь Разработчикам
    Ответов: 4
    Последнее сообщение: 09.11.2012, 18:02
  2. Разбор даты
    от VanoKing в разделе Master SCADA 3
    Ответов: 7
    Последнее сообщение: 06.09.2011, 11:08
  3. Проблема с выводом текста
    от CLPE в разделе ПЛК1хх
    Ответов: 3
    Последнее сообщение: 17.01.2011, 12:51
  4. OPC-server для работы по протоколу Owen
    от gefan в разделе Сервисное ПО
    Ответов: 7
    Последнее сообщение: 10.12.2010, 13:16
  5. Ошибка 2816 по протоколу Owen
    от RV9WFJ в разделе ПЛК1хх
    Ответов: 2
    Последнее сообщение: 30.06.2008, 18:07

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •