Юра (30.03.2012 20:25, просмотров: 1) ответил koyodza на по второму вопросу: да, должен отвечать "функция не поддерживается"-
- ответ "функция не поддерживается" нужно отправлять не только на 16, но и на любые другие неподдерживаемые функции - koyodza(30.03.2012 21:05)
- Ну в требованиях указан"класс совместимости 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)
- совсем не отвечать (при совпадении адреса) можно только на пакеты длиной больше 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)
- С одной стороны так, но с другой... анализ пакета происходит после паузы от мастера в 3.5 символа... если в процессе приёма пакета количество байт превышает ожидаемое, то это не ваш пакет... в топку его и CRC туда же... то есть я в самом начале zlogic(177 знак., 01.04.2012 14:53)
- нельзя. Если адрес наш - нужно отвечать. Даже если функция не поддерживается. Иначе мастером это будет расценено как сбой связи, а не как недопустимость для слейва такого запроса - koyodza(01.04.2012 15:19)
- Верно... Но я с чего начинал разговор? если пакет больше ожидаемой длины, то это не ваш пакет... и на него вообще отвечать не стоит... просто разговор немного ушёл в сторону... - zlogic(01.04.2012 14:33)
- Нечего посылать неподдерживаемые функции. Тогда и буфер нужен 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(01.04.2012 15:17 - 15:20)
- Я разве не об этом писал? "Тем более что считать CRC нужно только для своих пакетов." Пакет длиной более 8 байт есть не пакет для Юра... Ответ с exception вообще не содержит CRC... - zlogic(01.04.2012 13:49)
- буфер не обязательно 256 байт, CRC в экстремальных случаях считается "на лету". Тем более что считать CRC нужно только для своих пакетов. Для пакетов, которые подлежат обработке, но длиннее буфера, есть ошибка ILLEGAL_DATA_VALUE koyodza(186 знак., 01.04.2012 11:53 - 12:04)
- Ешё раз... Если функция не поддерживается, то посылается мастеру exception, который не содержит CRC... то есть не надо CRC считать... - zlogic(01.04.2012 14:16)
- ничего подобного, разница есть. Положено на пакеты с правильным адресом отвечать "функция не поддерживается". Иначе из-за таймаутов при неответах тормозится работа всей системы koyodza(201 знак., 01.04.2012 11:40)
- Если пакет имеет правильный адрес, но левый код функции, то это пакет или битый, или ошибочный (из-за ошибки верхнего ПО). В любом случае нет разницы, проигнорируем его, или ответим, что функция не поддерживается. Разве что для отладки может Леонид Иванович(13 знак., 01.04.2012 11:37)
- не годится: если запрос с правильным адресом, но с неподдерживаемым кодом функции, то правильно будет убедиться, что пакет не битый. И если CRC сошлась, ответить на него "неподдерживаемая функция" koyodza(141 знак., 01.04.2012 11:09)
- А для чего вы считаете CRC сообщения, которое явно не для вашего устройства? zlogic(125 знак., 01.04.2012 02:50 - 06:13)
- Большое спасибо всем. Сделано. До 8 первых пришедших от мастера байт кладет в буфер, а дальнейшие до 255 пропускает мимо ушей, считая ихнюю CRC на лету. На функцию 16 отвечает "не тот адрес регистра", на все остальные кроме 03 и 06 - Юра(28 знак., 31.03.2012 10:26,
- CRC от формата не зависит. Функций может быть максимум 126 (от 01 до 7F), если не ошибаюсь - koyodza(30.03.2012 22:45)
- А как узнать сколько их всего включая пользовательские, и как мне знать формат всех чтобы посчитать CRC? - Юра(30.03.2012 22:36,
- на все остальные тоже обязательно должен быть ответ "функция не поддерживается". А вот на 16 в этом случае нужно отвечать "недопустимый адрес регистра" (или "недопустимые данные" в зависимости от ситуации) - koyodza(30.03.2012 22:02 - 01.04.2012 15:54)
- Ну в требованиях указан"класс совместимости 0" ( и перечислены возможные функции 03, 06, 16 ). Поэтому хоть ответ на 16 вставить. - Юра(30.03.2012 21:41,
- это уже будет не модбас, если Вы не можете принимать более длинные пакеты. Выбирайте другой протокол или используйте свой - koyodza(30.03.2012 20:32)
- Дык что мешает определив "проходящую по линии функцию 16 ", считать CRC на лету, не кладя в буфер? - Гудвин(30.03.2012 20:31)
- ответ "функция не поддерживается" нужно отправлять не только на 16, но и на любые другие неподдерживаемые функции - koyodza(30.03.2012 21:05)