caxapa.ru :: ответ "функция не поддерживается" нужно отправлять не только на 16, но и на любые другие неподдерживаемые функции

koyodza (30.03.2012 21:05, просмотров: 820) ответил Юра на По второму вопросу. Да мне бы легче ответ о неподдержке отправить, но проблема в том, что устройство маленькое, входной буферок 8 байт( заточен под функции 03 и 06), и поддержать проходящую по линии функцию 16 с неизвестной длиной не

ответ "функция не поддерживается" нужно отправлять не только на 16, но и на любые другие неподдерживаемые функции

Ответить

- Ну в требованиях указан"класс совместимости 0" ( и перечислены возможные функции 03, 06, 16 ). Поэтому хоть ответ на 16 вставить. - Юра(30.03.2012 21:41, )
  - на все остальные тоже обязательно должен быть ответ "функция не поддерживается". А вот на 16 в этом случае нужно отвечать "недопустимый адрес регистра" (или "недопустимые данные" в зависимости от ситуации) - koyodza(30.03.2012 22:02 - 01.04.2012 15:54)
    - А как узнать сколько их всего включая пользовательские, и как мне знать формат всех чтобы посчитать CRC? - Юра(30.03.2012 22:36, )
      - CRC от формата не зависит. Функций может быть максимум 126 (от 01 до 7F), если не ошибаюсь - koyodza(30.03.2012 22:45)
        
        Большое спасибо всем. Сделано. До 8 первых пришедших от мастера байт кладет в буфер, а дальнейшие до 255 пропускает мимо ушей, считая ихнюю CRC на лету. На функцию 16 отвечает "не тот адрес регистра", на все остальные кроме 03 и 06 - Юра(28 знак., 31.03.2012 10:26, )
        
        А для чего вы считаете CRC сообщения, которое явно не для вашего устройства? zlogic(125 знак., 01.04.2012 02:50 - 06:13)
        
        не годится: если запрос с правильным адресом, но с неподдерживаемым кодом функции, то правильно будет убедиться, что пакет не битый. И если CRC сошлась, ответить на него "неподдерживаемая функция" koyodza(141 знак., 01.04.2012 11:09)
        
        Если пакет имеет правильный адрес, но левый код функции, то это пакет или битый, или ошибочный (из-за ошибки верхнего ПО). В любом случае нет разницы, проигнорируем его, или ответим, что функция не поддерживается. Разве что для отладки может Леонид Иванович(13 знак., 01.04.2012 11:37)
        
        ничего подобного, разница есть. Положено на пакеты с правильным адресом отвечать "функция не поддерживается". Иначе из-за таймаутов при неответах тормозится работа всей системы koyodza(201 знак., 01.04.2012 11:40)
        
        Ешё раз... Если функция не поддерживается, то посылается мастеру exception, который не содержит CRC... то есть не надо CRC считать... - zlogic(01.04.2012 14:16)
        
        чего-чего? Каие ещё посылки без CRC ? Что, 1 апреля давит? - koyodza(01.04.2012 15:13)
        
        Еще раз... Если CRC не посчитана, нельзя с уверенностью сказать, это неподдерживаемая функция или битый пакет. - Леонид Иванович(01.04.2012 14:25)
        
        Верно... Но я с чего начинал разговор? если пакет больше ожидаемой длины, то это не ваш пакет... и на него вообще отвечать не стоит... просто разговор немного ушёл в сторону... - zlogic(01.04.2012 14:33)
        
        нельзя. Если адрес наш - нужно отвечать. Даже если функция не поддерживается. Иначе мастером это будет расценено как сбой связи, а не как недопустимость для слейва такого запроса - koyodza(01.04.2012 15:19)
        
        Ну и? мастер не идиёт... сформирует правильный запрос... адрес, количество байт в сообщении и т.п. хню... если мастер такой тупой, то и не получит в ответ ничего, что ожидал... программист на стороне мастера подумает и сформирует сообщение zlogic(14 знак., 01.04.2012 15:33)
        
        ничего он не "подумает". Обычная реакция мастера на отсутствие ответа - это повторение запроса. Дальше подумайте сами, что будет - koyodza(01.04.2012 15:41)
        
        совсем не отвечать (при совпадении адреса) можно только на пакеты длиной больше 256 байт - koyodza(01.04.2012 15:32)
        
        Формально любой пакет с нашим адресом - наш пакет. И если он с правильной CRC, то положено на него отвечать. Хотя я тоже в своей реализации это игнорирую, Леонид Иванович(69 знак., 01.04.2012 14:41)
        
        С одной стороны так, но с другой... анализ пакета происходит после паузы от мастера в 3.5 символа... если в процессе приёма пакета количество байт превышает ожидаемое, то это не ваш пакет... в топку его и CRC туда же... то есть я в самом начале zlogic(177 знак., 01.04.2012 14:53)
        
        Я именно так и делаю, но уважаемый koyodza привел аргументированные возражения. - Леонид Иванович(01.04.2012 15:01)
        
        Давайте вернёмся к его аргументам... Ссылку, плиз... Хотя, мы сейчас ведём разговор о пакете с количеством байт больше ожидаемого... а уважаемый koyodza на эту тему вроде бы ничего не говорил... - zlogic(01.04.2012 15:04 - 15:09)
        
        Аргументы просты - устройство формально не будет Modbus-совместимым. Насчет пакетов, не умещающихся в буфер, тоже было сказано. На них нужно отвечать ILLEGAL_DATA_VALUE. А вот ожидаемое количество байт - это другое, мы узнаем его только при Леонид Иванович(34 знак., 01.04.2012 16:29)
        
        Нечего посылать неподдерживаемые функции. Тогда и буфер нужен 256 байт, а это в большинстве случаев непозволительная роскошь, в мелких контроллерах ОЗУ кот наплакал. - Леонид Иванович(01.04.2012 11:46)
        
        буфер не обязательно 256 байт, CRC в экстремальных случаях считается "на лету". Тем более что считать CRC нужно только для своих пакетов. Для пакетов, которые подлежат обработке, но длиннее буфера, есть ошибка ILLEGAL_DATA_VALUE koyodza(186 знак., 01.04.2012 11:53 - 12:04)
        
        Я разве не об этом писал? "Тем более что считать CRC нужно только для своих пакетов." Пакет длиной более 8 байт есть не пакет для Юра... Ответ с exception вообще не содержит CRC... - zlogic(01.04.2012 13:49)
        
        с какой это радости "Ответ с exception вообще не содержит CRC"? Любой небитый пакет в ModBus RTU должен содержать CRC - koyodza(01.04.2012 16:36)
        
        Для Юра чисто прикладно легче единообразно считать CRC от начала до конца пакета, первые 8 складывать в буфер остальные нет. А уж потом анализировать и адрес количество пришедших и совпадение CRC, благо оно уже посчитано. Хотя конечно, можно, не Юра(101 знак., 01.04.2012 13:56, )
        
        если ресурсов мало, то удобнее именно дропать не складывая и не считая CRC все пакеты, которые адресованы не нам и не широковещательные. Всё равно на них отвечать не положено, и действий никаких производить тоже - koyodza(01.04.2012 15:15)
        
        Сам сейчас делаю устройство, в котором МК C8051F301 (всегда его использую в модулях, типа ADAM и ICPCON (протокол DCON), а тут заказчик захотел MODBUS)... В этом МК всего-то ОЗУ 256 байт, буфер разместить на 256 байт фрейма MODBUS нет никакой zlogic(114 знак., 01.04.2012 14:07 - 14:29)
        
        Вы можете хоть на голове стоять в своём девайсе, только он не будет от этого более полно соответствовать стандарту - koyodza(01.04.2012 15:17 - 15:20)
        
        Вы сами-то читаете то, что пишете? - zlogic(01.04.2012 15:37, ссылка)
        
        перечитал. Именно так - можно дропать все пакеты, адрес в которых не наш. Дропать наши пакеты только потому, что функция не поддерживается, или потому, что пакет не помещается в буфере (но при этом не превышает максимальной разрешенной стандартом koyodza(14 знак., 01.04.2012 15:49)

Микроконтроллеры