Помогите с протоколом ОВЕН

Пишу в LabVIEW 8.6 программку для снятия инфы с МВА8, для связи выбрал протокол ОВЕН, стал разбираться в сути протокола, возникли проблемы:( :

1. в описании протокола в структурной схеме есть квадратик "Размер блока данных в байтах -2", поясните его, пожалуйста, непонятки в куске "-2" :confused: и как его посчитать - просто сумма байтов данных?

2. есть затруднения в понимании расчёта hash-функции и CRC-функции, строковое описание алгоритма, которое приводится не понял, т.к. не работал со строковыми языками программирования
x16+x15+x11+x10+x9+x8+x6+x4+x2+x1+x0:confused: а почему там нет x13,x12,x7,x5,x3 ?

3. допустим у меня в МВА8 на 5-ом входе висит "Датчик 4...20мА"
3.1 напишите, пожалуйста, как будет выглядеть команда в HЕX коде на посылку запроса значения даных с этого датчика и чем будет отличаться если ещё и время снятия данных запросить?
3.2 как должен выглядеть ответ от МВА8? (тоже в HEX коде)
3.3 и можно подробный пример расчёта HASH и CRC хотя бы для запросной команды? (подробный - т.е. если вручную считать "на бумаже", проверить правильно ли считается в программе)


Заранее спасибо :)

Немного разобрался сам:), но ещё есть проблемы:( .

все значения в HEX
Ст. часть адреса 0008 - взял из конфигуратора МВА8
Мл. часть адреса 101 - т.к. датчик на пятом входе висит
Бит запроса 1 - т.к. производим запрос данных
Размер блока данных в байтах -2 - НЕ ЗНАЮ ЧТО ПИСАТЬ:confused:
Локальный идентиф. (HASH) 8784 - команда rEAd (ВЗЯЛ ИЗ описания прграммруемых параметров МВА-8)
Поле данных уровня представления ???000??? - ЗНАЮ ЧТО НУЛИ:D , но СКОЛЬКО ИМЕННО НУЖНО - один или пятнадцать:confused:
Контрольная сумма CRC - так и не понял как считать:(

Чтобы не заморачиваться, гораздо проще использовать Owen OPC сервер и DataSocket в LabView. Настраиваете ОРС, создаете нумерик контрол или индикатор и в его свойствах во вкладке Data Binding -> Data Binding selection выбираете DataSocket и выбираете нужную переменную в Data Binding -> Browse -> DSTP Server. Данные прекрасно записываются и считываются с большинства наших приборов и не надо заморачиваться =)

как вариант для тестирования - отлично, но ведь наверно до запуска программы лабвью ещё надо будет запускать ОПЦ, а ведь юзеры бывают с очень кривыми руками, особенно если они ещё студенты.
поэтому прошу помощи в том, чтобы разобраться с протоколом ОВЕН

ps: просто уже есть опыт работы с чужими протоколами (ellab, awd10),
овен очень похож, но есть трудности.

насчет CRC вот программка на LabView для расчета контрольной суммы

а мож объяснишь заодно про....

Цитата:

---

Сообщение от Коротенко

Размер блока данных в байтах -2 - НЕ ЗНАЮ ЧТО ПИСАТЬ:confused:
Поле данных уровня представления ???000??? - ЗНАЮ ЧТО НУЛИ:D , но СКОЛЬКО ИМЕННО НУЖНО - один или пятнадцать:confused:

---

..плииииииизззз:D , а то проект стоит, а начальство скоро из отпуска вернётся

Допустим рассмотрим пакет посылаемый с ПК на МВА8 записывающий значение 1 в параметр LEN в ASCII символах (не забываем, что байты представляются по принципе тетрада-в-ascii-символ)

#HGGHLIJVGHSJQS.

# - начало пакета, «.» (она же 0D) – символ конца посылки
Преобразуем строку в последовательность байт по таблице

0000 -> 'G' = 0x47
0001 -> 'H' = 0x48
0010 -> 'I' = 0x49
0011 -> 'J' = 0x4a
0100 -> 'K' = 0x4b
0101 -> 'L' = 0x4c
0110 -> 'M' = 0x4d
0111 -> 'N' = 0x4e
1000 -> 'O' = 0x4f
1001 -> 'P' = 0x50
1010 -> 'Q' = 0x51
1011 -> 'R' = 0x52
1100 -> 'S' = 0x53
1101 -> 'T' = 0x54
1110 -> 'U' = 0x55

Получаем 10 01 52 3F 01 С3 AC

Разберем побитно слева направо согласно структурной схеме протокола ОВЕН:

00010000+000 – старшая+младшая часть адреса сети (16)
0 – бит запроса
0001 – размер блока данных 1 (то есть в пакете блок данных состоит из 1 байта поля данных и 2 байт хэш-кода, именно это и имеется ввиду, где написано про «-2»)
523F – hash-код параметра Len
01 – записываемое значение параметра
C3AC – контрольная сумма CRC

Могу также предложить программку для расчета хэш-кода параметра

почему бы вам не использовать owen_io.dll (http://www.owen.ru/device/64305906)? и все проблемы с протоколом будут сняты.

вот здесь и пример использования есть - http://www.owen.ru/forum/showthread.php?t=460

Цитата:

---

Сообщение от Дмитрий Егоренков

почему бы вам не использовать owen_io.dll и пример использования есть [/url]

---

пока что не занимался подключением dll к LabVIEW:( , в дальнейшем рассмотрю и применение owen_io.dll, спасибо:)

Цитата:

---

Сообщение от PC_DOS

пакет посылаемый с ПК на МВА8 #HGGHLIJVGHSJQS.

---

символы # и . , которые 0х23 и 0х0D, тоже посылать в LabVIEW? или VISA сама их допишет в начало и конец?

Цитата:

---

Сообщение от PC_DOS

в пакете блок данных состоит из 1 байта поля данных и 2 байт хэш-кода, именно это и имеется ввиду, где написано про «-2»

---

теперь вроде понял "-2" значит "вычесть число два", верно?

но ведь HASH всегда имеет размер два байта! зачем тогда о них говорить, написали бы уж "Размер поля данных в байтах" вместо "Размер блока данных в байтах -2" :D

привожу картинку как я понял всё изложенное

ps: раньше я посылал естественный код "10 01 52 3F 01 С3 AC" теперь нужно смещённый "HGGHLIJVGHSJQS".

зачем, в принципе, разработчикам кода потребовалось сделать СМЕЩЕНИЕ кода? посылали бы "10 01 52 3F 01 С3 AC":confused: :confused: :confused:

Цитата:

---

Сообщение от PC_DOS

вот программка на LabView для расчета контрольной суммы

---

она требует ASC_ToCod.vi:( , выложи его, а то нет могу проверить:(

и есть ещё просьба: может всё-таки словами объяснишь как рассчитать crc хотя бы на твоём же примере HGGHLIJVGH:D

хочу попытаться сделать свой расчётник CRC:)

чето не могу найти файлик, но советую сходить вот по этим ссылкам - там все достаточно подробно про CRC рассказано

http://www.owen.ru/forum/showthread....F1%F3%EC%EC%F3

http://www.owen.ru/forum/showthread....F1%F3%EC%EC%E0

http://www.owen.ru/forum/showthread....F1%F3%EC%EC%F3

ЗЫ символы обрамления пакетов посылать тоже следует из лабвью

Цитата:

---

Сообщение от Коротенко

пока что не занимался подключением dll к LabVIEW:( , в дальнейшем рассмотрю и применение owen_io.dll, спасибо:)

---

это будет быстрее и проще, чем реализовывать протокол. тем более имея в руках рабочий пример.

за

Цитата:

---

Сообщение от PC_DOS

ЗЫ символы обрамления пакетов посылать тоже следует из лабвью

---

БОЛЬШТЕ СПАСИБО, учту:)
а теперь...->
по ссылке
http://www.owen.ru/forum/showthread....F1%F3%EC%EC%E0
нашёл пост
http://www.owen.ru/forum/showpost.ph...39&postcount=8

Цитата:

---

Сообщение от Дмитрий Егоренков

если коротко, число состоящее из всех битов пакета делится на выбранный полином. crc - остаток от деления.

---

1. как именно число "состоит из всех битов пакета"? сложить байты? сложить полубайты? или что-то ещё?

2. полином (из описания протокола ОВЕН) вот такой х16+х15+х11+х10+х9+х8+х6+х4+х2+х1+х0
рядом спросить не у кого:( , поэтому спрашиваюю у вас:) - что КОНКРЕТНО означает x16 и т.д.

3. вопрос по "вот программка CRC на LabView" - первое действие со строкой символов - это разложение в 1D массив с символами из этой строки.
затем идёт неизвествный виай - судя по входу, выходу и названию массив с символами преобразуется в число (с преджставлением I32) - в чём суть преобразования ? может я сам допишу не достающее?

ps: по-моему 1 и 3 вопросы как-то связаны

:)

Цитата:

---

Сообщение от PC_DOS

насчет CRC вот программка на LabView для расчета контрольной суммы

---

недостающий кусок дописал:D
как оказалось нужно было просто кастовать ASCII символ его численное значение :D у меня версия 8.6 но CAST, на сколько мне известно, есть и в 8.5:D
если у тебя вас там навороченные вычисления :confused: :confused: :confused: то советую переделать как на картинке:)

С полиномом разобрался:) х16+х15+х11+х10+х9+х8+х6+х4+х2+х1+х0 - это бинарное число 11000111101010111:D

по прежнему остаётся воспрос...:(

Цитата:

---

Сообщение от Коротенко

как именно ЧИСЛО "состоит из всех битов пакета"? сложить байты? сложить полубайты? или что-то ещё?

---

:confused: :confused: :confused:

если ЧИСЛО состоит из битов по принципу "все биты поставить в один ряд" , т.е. для GVHGRILNMOQK этим ЧИСЛОМ является последовательность (0000 1111 0001 0000 1011 0010 0101 0111 0110 1000 1010 0100)? так ли это?

деление на полином - неопсредственное? по байтово? или как-то по другому?

И все е я не понимаю, почему Вы не хотите воспользоваться ОРС-сервером. Там все просто до умопомрочения. Что касается дополнительного запуска программы. То Labview сам запустит ОРС-сервер.

Цитата:

---

Сообщение от Ельцов Андрей

И все е я не понимаю, почему Вы не хотите воспользоваться ОРС-сервером.

---

ок, LabVIEW запустит сервер, и будет юзать COM порт, НО, моя прога в LabVIEW через который я буду запускать ОРС-сервер, УЖЕ имеет модуль с юзанием COM порта, я не проверял, но скорее всего будут конфликты при такой работе с COM портом, поэтому мне кажется что более НАДЁЖНЫМ решением является самостостельное ФОРМИРОВАНИЕ запроса и его РАСКОДИРОВАНИЕ.
пока что для меня есть только один вопрос не решён - КАК ЧИСЛО, КОТОРОЕ ДЕЛИТСЯ НА ПОЛИНОМ, СФОРМИРОВАНО ИЗ ПОСЫЛКИ?

почему в описании протокола ОВЕН, написано что применяется полином "х16+х15+х11+х10+х9+х8+х6+х4+х2+х1+х0", который равен 18F57,
когда НА САМОМ ДЕЛЕ "х15+х11+х10+х9+х8+х6+х4+х2+х1+х0", который равен 8F57 ?

Тему закрываю :)
Всем спасибо за ответы :)

PS: С повторением расчёта CRC больше не заморачиваюсь, :)просто "выдрал" нужный кусок из LabVIEW-шной проги и сконвертил его в подпрограмму :)
PPS: а дотошно расспрашивал, т.к. люблю заниматься оптимизацией порграмм :-), мои проги меньше аналогов, а выполняют то же самое:)

судя по тому, что вам доступен интернет, спросить про crc и полиномы можно хоть у яндекса, хоть у википедии.

http://ru.wikipedia.org/wiki/CRC

с лабвью я вам не помощник, но алгоритм вычисления crc на c есть на форуме. поищите.