[rezident 0]

при скорости 57600 выжидаю 70мс (3.5/57.6 = 60.8мс, но я решил для верности немножко с запасом) после приема очередного байта, если время прошло считаю как новый фрэйм, также сделал что если приходит больше 8ми байт в одном фрэйме, то каждый 9тый воспринимается как начало нового 8ми байтого фрэйма, короче радости полные штаны))

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

MODBUS Protocol Specification и Modbus Serial Line Protocol and Implementation Guide V1.02. Если бы вы прочитали вторую, то могли заметить ремарку про паузы. Да и про формат ответа вопросов не возникало.

[vazz 0]

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

MODBUS Protocol Specification и Modbus Serial Line Protocol and Implementation Guide V1.02. Если бы вы прочитали вторую, то могли заметить ремарку про паузы. Да и про формат ответа вопросов не возникало.

 

Справедливо с точки зрения человека который постоянно этим протоколом пользуется. Для меня же задача эта одноразовая и в самом простом ее "формате". Я не ленив, но врядли мне потребуется изучать этот протокол глубже чем "Компьютер - мастер, прибор - slave, 1 запрос - 1 ответ раз в 2-5 секунд". Из рациональных побуждений в плане затрат своего времени, которое дороже денег, я решил спросить у умудренных опытом людей совета в своей простейшей задаче. Мне не трудно изучить всю документацию по этому вопросу, но смысла в досканальном изучении совсем нет и не придвидится. Сегодня почитаю указанные вами документы. Большое спасибо всем за помощь, извините если кого напряг.

[demiurg_spb 0]

Так вот, значит посылаю я прибору

 

01 04 00 00 00 01 31 CA

 

а он мне в ответ

 

01 04 08 00 00 00 00 00 00 FF FF 25 BD

 

Возникает у меня как минимум 2 вопроса

 

1. Что за 08 и откуда оно берется? Эт явно что-то с модбасом связано

request: slave_address[1byte] func[1byte] address[2bytes] reg_qty[2bytes] crc[2bytes]

response: slave_address[1byte] func[1byte] bytes_qty[1byte] data[1-250bytes] crc[2bytes]

2. Почему так много данных выдает (пускай они даже 00 00), судя по всему он выдает четыре 2хбайтных параметра 00 00 00 00 00 00 FF FF, хотя я в исходящей посылке даю прибору инструкцию на передачу всего одного слова данных начиная с 00 00 адреса. Я предполагал, что ответ будет примерно таким:

01 04 xx xx CRC16

Предположения тут неуместны.

Что за прибор-то? Вероятно бага в приборе...

[vazz 0]

request: slave_address[1byte] func[1byte] address[2bytes] reg_qty[2bytes] crc[2bytes]

response: slave_address[1byte] func[1byte] bytes_qty[1byte] data[1-250bytes] crc[2bytes]

 

bytes_qty - как я понимаю ответ прибора типа "данные приняты без проблем, вот вам ответ", другими словами в случае если ошибок при приеме посылки нет и адрес с функцией совпадают я тупо втыкаю в ответную посылку байт 08 после адреса и функции..

 

Предположения тут неуместны.

Что за прибор-то? Вероятно бага в приборе...

 

Вероятно, но дело в том, что прежде чем мне передавать в ответ какие-либо данные мне нужно знать их последовательность, в данном случае какая понимаю ответная посылка имеет фиксированную длину независимо от кол-ва запрошенных данных, но указываемое кол-во данных влияет на заполнение этих фиксированных "вакантных" 4 слов данных... Хотя эт тож догадки.. Связи с программистом этим нет, молчит как рыба, обидно

[xvr 12]

bytes_qty - как я понимаю ответ прибора типа "данные приняты без проблем, вот вам ответ"

Неверно понимаете - это количество байтов в блоке данных ответа (поле data)

[demiurg_spb 0]

в данном случае какая понимаю ответная посылка имеет фиксированную длину независимо от кол-ва запрошенных данных, но указываемое кол-во данных влияет на заполнение этих фиксированных "вакантных" 4 слов данных...

Такого быть не должно. Сколько запросили регистров (N) столько байт (N*2) и получить должны.

Хотя эт тож догадки..

Не нужно гадать. Ещё раз Вам настоятельно рекомендую читать стандарт.

[vazz 0]

я снова тут! вобщем делюсь своими успехами, изучил особенности модбаса касательно своей задачи основательно и вобщем сделал всем моим приборам поддержку этого протокола, всего одной функции (чтения), но больше и не надо было, зато качественно, выдают ответы как положено, в т.ч. выдают ошибки типа функция не поддерживается, ошибка поля данных и т.д. и т.п. (с модификацией старшего бита функции в случае ошибок, усё как положено). Вобщем сейчас задача встала передо мной, никак не могу сообразить как это решить. Создал я ужо почти некую систему измерения температуры с 16разрядным АЦП, ИОНом крутым, вобщем все оч качественно, с компенсацией цифровых шумов и т.д. и т.п. Так вот система эта состоит из 4 компонентов: 1. комп 2.радиомодуль с usb (к компу) 3. радиомодуль с rs485 (к измерительным блокам) 4.измерительные модули (до 256 на одной шине, подключаются к п.3), все это уже собрано и отлажено многочисленным испытаниями, как точности измерения тк и дальностью взаимодействия, осталось ток дописать под винду программулину, которая всем этим ворочает. Так вот каждый измерительный модуль имеет 72 измерительных входа для датчиков (ну и дополнительные входы для измерения напряжения на проводах компенсации, 3хпроводная схема). Каждый модуль измерительный способен хранить в своей EEPROM 1 полное измерение (с датой и временем). В этом полном измерении (т.е. измерено 72 датчика), для каждого там сохранено 4 байта информации для последующей обработки на компе. Структура записи измерения в EEPROM: [5 байт на дату и время] + [1 байт кол-ва датчиков в отчете] + [5 байт на датчик, 1 на номер датчика, 4 на результаты измерения]x72. В итоге получается массив размером 5+1+5х72 = 366 байт, плюс к этому прибавляется 4 байта служебно информации для передачи по интерфейсу. Итого: 370 байт. Моя процедура подсчета CRC16 корректно считает сумму для пакета длиной не более 256 байт. КАК ПОСЧИТАТЬ CRC16 ДЛЯ ПАКЕТА БОЛЬШЕ 256 БАЙТ? :-) извините если вопрос неуместен и глуп.. ПОМОЖИТЕ, а то кроме этого мне ничо не мешает эту систему довести до конца

[Ruslan1 17]

КАК ПОСЧИТАТЬ CRC16 ДЛЯ ПАКЕТА БОЛЬШЕ 256 БАЙТ? :-)

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

Если еще что-то смущает, то код функции подсчета crc приведите, тогда проще будет советы давать :)

 

[rezident 0]

В итоге получается массив размером 5+1+5х72 = 366 байт, плюс к этому прибавляется 4 байта служебно информации для передачи по интерфейсу. Итого: 370 байт. Моя процедура подсчета CRC16 корректно считает сумму для пакета длиной не более 256 байт. КАК ПОСЧИТАТЬ CRC16 ДЛЯ ПАКЕТА БОЛЬШЕ 256 БАЙТ? :-) извините если вопрос неуместен и глуп.. ПОМОЖИТЕ, а то кроме этого мне ничо не мешает эту систему довести до конца

Ну если проблема только в подсчете CRC16, то нужно видимо изменить тип переменной которая задает размер пакета. Вместо unsigned char использовать unsigned int. Если вы используете функцию пример которой приведен в приложении к спецификации MODBUS over Serial Line, то там используется типа unsigned short, который нужно заменить на unsigned int.

Но я хотел бы задать встречный вопрос: как вы посредством протокола ModBus собираетесь передавать данные больше, чем 252 байта? Стандартными командами ModBus это не получится сделать. Ведь длина пакета не может быть больше, чем 256 байт, а у вас запись 370 байт.

 

[vazz 0]

Вероятно Вы уперлись в разрядность счетчика, который байты считает

 

Добрый день , Ruslan1! Вобщем считаю я по таблицам, которые приведены в начале темы, а алгоритм следующий (он слегка кривенький в плане написания, но до 256 байт работает):

 

; +-------------------------------------------------------------------------+

; | подпрограмма проверки контрольной суммы CRC16 |

; | |

; |temp1,temp10 - кол-во байт для подсчета, temp8,temp6 - начальный адрес 1го байта|

; | выход: temp3 - младший байт CRC16, temp2 - старший байт CRC16 |

; +-------------------------------------------------------------------------+

checkCRC16:

ldi temp2,0xFF ;загружаем начальное значение CRCLo

ldi temp3,0xFF ;загружаем начальное значение CRCLh

ldi temp4,0x00 ;загружаем начальное значение CRCindex

add temp6,temp1

adc temp8,temp10

mov temp5,temp6

mov temp9,temp8

loopXORbyte:

mov temp6,temp5

mov temp8,temp9

sub temp6,temp1 ;в temp6,temp8 остается адрес текущего байта принятого фрэйма

sbc temp8,temp10

mov ZH,temp8

mov ZL,temp6

ld temp6,Z ;в temp6 остается значение байта

eor temp2,temp6

mov temp4,temp2 ;получаем новое значение CRCIndex (CRCLo при этом теряется)

ldi ZH,0x02 ;выбираем старший массив

mov ZL,temp4 ;выбираем элемент массива (по CRCIndex)

lpm temp6,Z ;в temp6 получаем значение элемента массива

eor temp3,temp6 ;получаем новое значение CRCLo (CRCHi при этом теряется)

mov temp2,temp3

ldi ZH,0x01 ;выбираем младший массив

mov ZL,temp4 ;выбираем элемент массива (по CRCIndex)

lpm temp3,Z ;в temp3 получаем значение элемента массива (что и есть новое CRCHi)

subi temp1,1

sbci temp10,0

cpi temp1,0

brne loopXORbyte

cpi temp10,0

brne loopXORbyte

ret

 

Не клюйте за ассемблер, пока до Си руки не дошли (но скоро дойдут, т.к. скоро приедтся с arm работать и 7дюймовым tft)

 

кстати это алгоритм считает и после 256 байт, я пробовал добавить просто 2ой байт для счетчика, но видимо шо-то не то или с таблицами такой метод не работает. Свыше 256 байт этот алгорит выдает некое значение CRC16, но оно не совпадает к примеру со значеним которое выдает программка для работы с портами при досчете для того же самого пакета

 

Но я хотел бы задать встречный вопрос: как вы посредством протокола ModBus собираетесь передавать данные больше, чем 252 байта? Стандартными командами ModBus это не получится сделать. Ведь длина пакета не может быть больше, чем 256 байт, а у вас запись 370 байт.

 

Извините что сразу не уточнил, я после своего поста ток понял что этот вопрос последует неминуемо) в этой системе было решено создать свой протокол "засекреченный" типа, он оч похож на модбас, но не совсем, этот протокол позволяет мне значительно сократить время общения главного с подчиненными (вдаваться в подробности думаю нет смысла, хотя если это интересно я могу и рассказать). Сейчас проблема только с подсчетом црц для пакета больше 256 длиной. Система имеет свой собственный радиоканал + локальный физ.интерфейс RS485, к которому больше никакое оборудование никогда не будет цепляться, ну есть еще кое какие маркетинговые причины почему свой протокол.

[rezident 0]

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

Ну меня не особенно интересует этот ваш "засекреченный" протокол У нас тоже есть свой протокол (правда он нисколько не секретный), который был создан на базе протоколов ModBus и PiNet. Общая длина пакета ограничена 65536 (2^16) байт. Но с помощью него можно адресовать 2^32 байт. Делается это очень просто. Есть отдельная команда "чтение со смещением". При исполнении этой команды первые четыре байта поля Data интерпретируются как смещение от адреса, задаваемого полем Starting Address. Если Starting Address будет указывать на начало вашей записи EEPROM, то с помощью смещения вы сможете почитать всю вашу запись (370 байт) за два запроса. Но для этого нужно использовать код "нестандартной" (пользовательской) функции в ModBus. Соответственно поддержать в приборе ответ на запрос с таким кодом функции.

[vazz 0]

Ну меня не особенно интересует этот ваш "засекреченный" протокол

 

"засекреченный" эт не всмысле что он супер крутой какой-то и принципиально новый и "тока за отдельные деньги", сам по себе он не представляет никакой ценности)) он только для этой системы, например сейчас если сказать обычному пользователю что для мышки тож дрова нужны он на тя как на дурачка посмотрит, тож самое и тут, у всего есть свои заморочки с сопряжением, но конечному пользователю собсно это даж знать не нужно, тем более система полностью самостоятельна и не предполагает быть интегрированна в некую другую систему сбора данных. Я эту процедуру подсчета crc как тогда еще написал так больше и не трогал, а тут понадобилось больше 256 байт передавать.. и чо делать хз. Я даж не понимаю как наращивание счетчика еще одним байтом помогает, если значений в массивах таблиц всего по 256 в каждой. Т.е. при переполнении счетчика что с чем должно ксориться если массив таблицы закончился. Вот этот бы момент уточнить. Мож другие таблицы нужны и принцип несколько иной..

 

Вот например я прям ща запрашиваю полное измерение из модуля, получаю от него:

 

3E 01 01 01 0B 00 00 48 01 00 53 FF FF 02 00 63 FF FF 03 00 68 FF FF 04 00 78 FF FF 05 00 55 FF FF 06 00 73 FF FF 07 00 81 FF FF 08 00 88 FF FF 09 00 68 FF FF 0A 00 7C FF FF 0B 00 7A FF FF 0C 00 84 FF FF 0D 00 64 FF FF 0E 00 77 FF FF 0F 00 75 FF FF 10 00 87 FF FF 11 00 55 FF FF 12 00 67 FF FF 13 00 61 FF FF 14 00 6A FF FF 15 00 63 FF FF 16 00 66 FF FF 17 00 6D FF FF 18 00 7C FF FF 19 00 47 FF FF 1A 00 57 FF FF 1B 00 55 FF FF 1C 00 67 FF FF 1D 00 47 FF FF 1E 00 5E FF FF 1F 00 52 FF FF 20 00 68 FF FF 21 00 44 FF FF 22 00 4B FF FF 23 00 4B FF FF 24 00 57 FF FF 25 00 5B FF FF 26 00 58 FF FF 27 00 50 FF FF 28 00 4B FF FF 29 00 43 FF FF 2A 00 3F FF FF 2B 00 28 FF FF 2C 00 38 FF FF 2D 00 3A FF FF 2E 00 41 FF FF 2F 00 3A FF FF 30 00 42 FF FF 31 00 28 FF FF 32 00 36 FF FF 33 00 2D FF FF 34 00 3D FF FF 35 00 2B FF FF 36 00 38 FF FF 37 00 1A FF FF 38 00 1E FF FF 39 00 1D FF FF 3A 00 1D FF FF 3B 00 1D FF FF 3C 00 1F FF FF 3D 00 37 FF FF 3E 00 2C FF FF 3F 00 2C FF FF 40 00 25 FF FF 41 00 2D FF FF 42 00 23 FF FF 43 00 44 FF FF 44 00 41 FF FF 45 00 46 FF FF 46 00 39 FF FF 47 00 30 FF FF 48 00 29 FF FF DC FB

 

DC FB - эт по его мнению CRC16

 

Для этой же последовательности (кроме DC FB) программка для работы с портами выдает crc16 = 4A C3. Модуль не прав, т.к. даж если всю последовательность прогнать через программку (вместе с crc), то нулей не получается((

 

 

 

блин, я решил попробовать прогнать через программку эту последовательность с ее же мыданной crc16 с полной уверенносью, что она мне ща в конце нули напишет и о ужас:

 

3E 01 01 01 0B 00 00 48 01 00 53 FF FF 02 00 63 FF FF 03 00 68 FF FF 04 00 78 FF FF 05 00 55 FF FF 06 00 73 FF FF 07 00 81 FF FF 08 00 88 FF FF 09 00 68 FF FF 0A 00 7C FF FF 0B 00 7A FF FF 0C 00 84 FF FF 0D 00 64 FF FF 0E 00 77 FF FF 0F 00 75 FF FF 10 00 87 FF FF 11 00 55 FF FF 12 00 67 FF FF 13 00 61 FF FF 14 00 6A FF FF 15 00 63 FF FF 16 00 66 FF FF 17 00 6D FF FF 18 00 7C FF FF 19 00 47 FF FF 1A 00 57 FF FF 1B 00 55 FF FF 1C 00 67 FF FF 1D 00 47 FF FF 1E 00 5E FF FF 1F 00 52 FF FF 20 00 68 FF FF 21 00 44 FF FF 22 00 4B FF FF 23 00 4B FF FF 24 00 57 FF FF 25 00 5B FF FF 26 00 58 FF FF 27 00 50 FF FF 28 00 4B FF FF 29 00 43 FF FF 2A 00 3F FF FF 2B 00 28 FF FF 2C 00 38 FF FF 2D 00 3A FF FF 2E 00 41 FF FF 2F 00 3A FF FF 30 00 42 FF FF 31 00 28 FF FF 32 00 36 FF FF 33 00 2D FF FF 34 00 3D FF FF 35 00 2B FF FF 36 00 38 FF FF 37 00 1A FF FF 38 00 1E FF FF 39 00 1D FF FF 3A 00 1D FF FF 3B 00 1D FF FF 3C 00 1F FF FF 3D 00 37 FF FF 3E 00 2C FF FF 3F 00 2C FF FF 40 00 25 FF FF 41 00 2D FF FF 42 00 23 FF FF 43 00 44 FF FF 44 00 41 FF FF 45 00 46 FF FF 46 00 39 FF FF 47 00 30 FF FF 48 00 29 FF FF 4A C3 B7 0F

 

в конце B7 0F!(( эт получается что моя процедура мож и арбайтен?) блин посчитайте кто нить для этой последовательности crc16, а то чо-то я уже ничо не понимаю.. вот для этого же пакета что последнирислал тока без 4 последних байт (это суммы crc две подряд)

 

посчитал тут http://webnet77.com/cgi-bin/helpers/crc.pl вообще 3 результат) во хрень

 

в экспериментах пошел дальше взял эту же последовательность с црц который посчитан самим модулем и прогнал через прогрммку, в и тоге тоже получил не 00 00, а B7 0F, как и в случае с предыдущим примером. шо то в этом есть.. или совпадение?

 

3E 01 01 01 0B 00 00 48 01 00 53 FF FF 02 00 63 FF FF 03 00 68 FF FF 04 00 78 FF FF 05 00 55 FF FF 06 00 73 FF FF 07 00 81 FF FF 08 00 88 FF FF 09 00 68 FF FF 0A 00 7C FF FF 0B 00 7A FF FF 0C 00 84 FF FF 0D 00 64 FF FF 0E 00 77 FF FF 0F 00 75 FF FF 10 00 87 FF FF 11 00 55 FF FF 12 00 67 FF FF 13 00 61 FF FF 14 00 6A FF FF 15 00 63 FF FF 16 00 66 FF FF 17 00 6D FF FF 18 00 7C FF FF 19 00 47 FF FF 1A 00 57 FF FF 1B 00 55 FF FF 1C 00 67 FF FF 1D 00 47 FF FF 1E 00 5E FF FF 1F 00 52 FF FF 20 00 68 FF FF 21 00 44 FF FF 22 00 4B FF FF 23 00 4B FF FF 24 00 57 FF FF 25 00 5B FF FF 26 00 58 FF FF 27 00 50 FF FF 28 00 4B FF FF 29 00 43 FF FF 2A 00 3F FF FF 2B 00 28 FF FF 2C 00 38 FF FF 2D 00 3A FF FF 2E 00 41 FF FF 2F 00 3A FF FF 30 00 42 FF FF 31 00 28 FF FF 32 00 36 FF FF 33 00 2D FF FF 34 00 3D FF FF 35 00 2B FF FF 36 00 38 FF FF 37 00 1A FF FF 38 00 1E FF FF 39 00 1D FF FF 3A 00 1D FF FF 3B 00 1D FF FF 3C 00 1F FF FF 3D 00 37 FF FF 3E 00 2C FF FF 3F 00 2C FF FF 40 00 25 FF FF 41 00 2D FF FF 42 00 23 FF FF 43 00 44 FF FF 44 00 41 FF FF 45 00 46 FF FF 46 00 39 FF FF 47 00 30 FF FF 48 00 29 FF FF DC FB B7 0F

Изменено 1 апреля, 2011 пользователем vazz

[rezident 0]

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

Вот этот он-лайн калькулятор правильно считает CRC16 для ModBus RTU (проверял на коротких пакетах). Но к сожалению, он не может обработать слишком длинную (нестандартную) строку данных.

[vazz 0]

к сожалению ничего не могу найти в сети по моему вопросу... может опыта не хватает.. поэтому могу ток с бубном прыгать пока, и это кое что дает, но я не понял пока о чем это говорит, попробую объяснить, к примеру есть массив данных:

 

3E 01 01 01 0B 00 00 48 01 00 50 FF FF 02 00 65 FF FF 03 00 61 FF FF 04 00 77 FF FF 05 00 57 FF FF 06 00 6E FF FF 07 00 84 FF FF 08 00 87 FF FF 09 00 66 FF FF 0A 00 7A FF FF 0B 00 73 FF FF 0C 00 84 FF FF 0D 00 65 FF FF 0E 00 71 FF FF 0F 00 76 FF FF 10 00 84 FF FF 11 00 56 FF FF 12 00 68 FF FF 13 00 61 FF FF 14 00 6B FF FF 15 00 5D FF FF 16 00 6C FF FF 17 00 65 FF FF 18 00 78 FF FF 19 00 49 FF FF 1A 00 57 FF FF 1B 00 53 FF FF 1C 00 64 FF FF 1D 00 4F FF FF 1E 00 5C FF FF 1F 00 55 FF FF 20 00 65 FF FF 21 00 46 FF FF 22 00 45 FF FF 23 00 49 FF FF 24 00 56 FF FF 25 00 5A FF FF 26 00 50 FF FF 27 00 4D FF FF 28 00 47 FF FF 29 00 40 FF FF 2A 00 3C FF FF 2B 00 2B FF FF 2C 00 32 FF FF 2D 00 39 FF FF 2E 00 40 FF FF 2F 00 36 FF FF 30 00 40 FF FF 31 00 27 FF FF 32 00 34 FF FF 33 00 2A FF FF 34 00 3A FF FF 35 00 2A FF FF 36 00 32 FF FF 37 00 1D FF FF 38 00 1D FF FF 39 00 15 FF FF 3A 00 20 FF FF 3B 00 1B FF FF 3C 00 20 FF FF 3D 00 37 FF FF 3E 00 2D FF FF 3F 00 2D FF FF 40 00 20 FF FF 41 00 28 FF FF 42 00 1E FF FF 43 00 3C FF FF 44 00 41 FF FF 45 00 41 FF FF 46 00 34 FF FF 47 00 39 FF FF 48 00 2A FF FF

 

мой модуль по приведенному выше алгоритму (на асме) считает для него crc16 = F4 17. Программка для работы с портами (IODump называется) считает для этого же массива crc16 = 84 8D. Это разные результаты, НО... Если взять этот массив и в конце добавить к нему F4 17 и прогнать через программку IODump в надежде получить 00 00, то я получу результат crc16 = 63 5B. Также если взять этот массив и в конце добавить к нему 84 8D и прогнать через программку IODump в надежде получить 00 00, то я опять же получаю результат crc16 = 63 5B. И это не совпадение, можно и еще несколько разных пакетов аналогично проверить и значения будут одинаковыми. Я немного в замешательстве, мож все таки у кого нить есть правильный алгоритм вычисления, для эталона, чтоб понять как дальше жить то..)

Изменено 3 апреля, 2011 пользователем vazz

[rezident 0]

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

Правильный алгоритм в спецификации ModBus привден. И даже функция на языке Си имеется.