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

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

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 слов данных... Хотя эт тож догадки.. Связи с программистом этим нет, молчит как рыба, обидно

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

Такого быть не должно. Сколько запросили регистров (N) столько байт (N*2) и получить должны.
Не нужно гадать. Ещё раз Вам настоятельно рекомендую читать стандарт.

я снова тут! вобщем делюсь своими успехами, изучил особенности модбаса касательно своей задачи основательно и вобщем сделал всем моим приборам поддержку этого протокола, всего одной функции (чтения), но больше и не надо было, зато качественно, выдают ответы как положено, в т.ч. выдают ошибки типа функция не поддерживается, ошибка поля данных и т.д. и т.п. (с модификацией старшего бита функции в случае ошибок, усё как положено). Вобщем сейчас задача встала передо мной, никак не могу сообразить как это решить. Создал я ужо почти некую систему измерения температуры с 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 БАЙТ? :-) извините если вопрос неуместен и глуп.. ПОМОЖИТЕ, а то кроме этого мне ничо не мешает эту систему довести до конца

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

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

Добрый день , 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, но оно не совпадает к примеру со значеним которое выдает программка для работы с портами при досчете для того же самого пакета



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

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

"засекреченный" эт не всмысле что он супер крутой какой-то и принципиально новый и "тока за отдельные деньги", сам по себе он не представляет никакой ценности)) он только для этой системы, например сейчас если сказать обычному пользователю что для мышки тож дрова нужны он на тя как на дурачка посмотрит, тож самое и тут, у всего есть свои заморочки с сопряжением, но конечному пользователю собсно это даж знать не нужно, тем более система полностью самостоятельна и не предполагает быть интегрированна в некую другую систему сбора данных. Я эту процедуру подсчета 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

Сообщение отредактировал vazz - Apr 1 2011, 17:22

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

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



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

Сообщение отредактировал vazz - Apr 3 2011, 09:05

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