Вход Наше всё Теги codebook 无线电组件 Поиск Опросы Закон Пятница
22 ноября

О смысле всего сущего 0xFF Средства и методы разработки Мобильная и беспроводная связь Блошиный рынок Объявления

Микроконтроллеры PLD, FPGA, DSP AVR PIC ARM, RISC-V Технологии Кибернетика, автоматика, протоколы Схемы, платы, компоненты

Кибернетика, автоматика, протоколы

Ljutik1 (14.11.2012 16:00, просмотров: 33304)

Подскажите по MODBUS RTU Внимательно почитал документацию и возник следующий вопрос. Допустим, мастер передает запрос слейву. Слейв его понял, все ок. Вопрос в том, когда отвечать слейву - через 3.5 char после окончания пакета мастера или сразу? Если через 3.5char, то этот ответ могут воспринимать другие устройства в сети, что ни есть гут.

Ответить

- Сразу. Требование паузы 3.5 char устарело сразу после появления интерфейсов USB/Ethernet/Bluetooth-RS485, где такие точные паузы не выдерживаются, и могут быть разрывы в середине пакетов. Конец пакета определяетя по правильной CRC, ошибки - по zeleny(11 знак., 15.11.2012 13:26)
  - это да, я влетал с некоторыим клиентами в их нарушение пауз, но koyodza прав, никакого другого критерия завершения пакета, как появления ОПРЕДЕЛЕННОЙ паузы применять нельзя. Иначе тут можно таких эффектов нахватать! Не нравится величина паузы? Лагунов(72 знак., 15.11.2012 13:56)
  - это очень распространённое, но крайне глупое заблуждение - определять конец пакета по совпадению CRC Не делайте так никогда - koyodza(15.11.2012 13:51)
    - почему ? даже если адрес и CRC правильные ? - zeleny(15.11.2012 13:53)
- слейв вообще не имеет права разбирать "сразу". В MODBUS RTU признаком конца пакета является только пауза на линии не менее 3,5Т и ни что другое koyodza(308 знак., 14.11.2012 16:05)
  - а 1.5 интервала разве не является признаком окончания пакета? abivan(504 знак., 14.11.2012 16:35)
    - откуда цитата? 1,5Т вроде как должен считаться ошибочным разрывом, но чаще он вообще не отслеживается - koyodza(14.11.2012 16:58)
      - вот с оригинала abivan(805 знак., 14.11.2012 17:13)
        
        отсюда следует, что при паузе 1,5Т всё что принято бросить нах и не разбирать, а начать принимать следующий пакет. Т.е. 1,5Т это признак бракованного пакета, а не признак завершения пакета koyodza(176 знак., 14.11.2012 17:20)
        
        Небольшая поправка. Не "начать принимать следующий пакет", а ожидать окончания текущего пакета/начало следующего. То бишь отслеживать паузу 3,5Т. Хотя лично я в RTU-ных протоколах про 1,5Т обычно не заморачиваюсь, ориентируясь на rezident(31 знак., 14.11.2012 18:19)
        
        Пытаюсь разобраться. Читаем оригинал abivan(553 знак., 15.11.2012 10:14)
        
        Вы читаете давно устаревшее описание протокола. Откройте текущую версию стандарта по ссылке, там довольно наглядные диаграммы состояний и никаких упоминаний про "next byte will be the address field of a new message". Интервал 1.5 сделан, видимо, AlexG(174 знак., 15.11.2012 11:07, ссылка)
        
        RTU через модем? Мсье знает толк в извращениях. - ASDFS(15.11.2012 13:32)
        
        Не отрицаю :) Но сильно не хотелось тратить в два раза больше времени на передачу Modbus-ASCII. Некоторым модемам то что RTU пакет помещается в буфер целиком совершенно не мешает его рвать, причем это может выясниться на последнем модеме из AlexG(116 знак., 15.11.2012 19:17)
        
        Пурква па? Если в буфер модема помещается весь пакет целиком. - rezident(15.11.2012 19:05)
        
        Да хоть три пакета. Нет гарантий что дойдет без временнЫх разрывов. ASDFS(56 знак., 15.11.2012 19:25)
        
        Все зависит от конктретного модема, многие модемы обещают выдавать принятый пакет в порт только после того как он был принят целиком, даже если часть данных принять с первого раза не удалось и пришлось перезапрашивать то что недошло. AlexG(201 знак., 16.11.2012 08:39)
        
        У нас видимо именно такие модемы используют :) Они передают через RS485 пакет целиком, без разрывов. При том, что в эфире могут быть перезапросы или использоваться ретрансляторы. - rezident(16.11.2012 14:05)
        
        сенкс, теперь ясна причина разночтения. - abivan(15.11.2012 12:40)
        
        да, верно - koyodza(14.11.2012 18:45)
  - и еще вопрос. Ljutik1(108 знак., 14.11.2012 16:06)koyodza
    - Следует всегда предусматривать настраиваемые таймауты для как минимум двух событий: а) ожидание ответа ведомого, б) задержка передачи ответа после приема запроса. Первая нужна для тайм-слота, в котором адресуемому слейву разрешено отвечать. rezident(368 знак., 14.11.2012 16:14)
      - Вы где нибудь видели в природе репитеры RS485? Вопрос без всякого подвоха и претензий, просто не понятен алгоритм определения направления передачи в данном девайсе, универсальный и работающий при любом протоколе (не только для MODBUS RTU). Я sin(55 знак., 14.11.2012 16:28, )
        
        Конечно. Я сам там такой разрабатывал 6+ лет назад. Мы производим их мелкой серией. Устройство выполняет функции конвертера RS232<->2*RS485 и репитера RS485<->RS485. rezident(1174 знак., 14.11.2012 17:57 - 18:02)
        
        А вы гарантируете работу при любых протоколах и скоростях? А если вдруг нестандартная скорость (бывает попадается в древних изделиях). А как насчет допустимого максимума 1 мбод? Вообще по RS485 не возбраняется гонять даже дифференциально sin(21 знак., 15.11.2012 16:03, )
        
        Нет, не гарантируем. Скорости из стандартного ряда. Таймауты привязаны к этим скоростям. Конфигурация задается с помощью DIP-switch. Была идея реализовать возможность задания пользовательской конфигурации таймаутов (и соответственно высокой rezident(219 знак., 15.11.2012 18:46 - 18:49)
        
        да, есть такие. Простейший вариант использует одновибраторы, более сложные попадались на ПЛИС - koyodza(14.11.2012 16:59)
        
        Они наверное все таки имеют какие нибудь ограничения на протокол и на скорость передачи. К примеру, не возбраняется же на RS485 организовать мультимастерную сеть, хотя наверное это и экзотика. Здесь мне кажется возможны нюансы: сложно будет sin(225 знак., 14.11.2012 17:10, )
        
        Я и сам разрабатывал, с конфигурацией микроконтроллером. Если протокол позволяет производить разворот на весь пакет, то потери помехоустойчивости не происходит. - Vladimir Ljaschko(14.11.2012 17:26)
        
        Что значит разворот на весь пакет? Я имел ввиду ухудшение помеоустойчивости, вследствии нахождения линии в высокоимпедансе в часть времени передачи одного символа (бита) в преобразователях ICPDAS. - sin(15.11.2012 15:53, )
        
        те, что мне попадались, настраивались на нужную скорость джамперами - koyodza(14.11.2012 17:17)
    - обычно это время настраивается пользователем (вернее, "администратором")в пределах от десятков-сотни мсек до единиц сек, зависит от физической скорости передачи, структуры системы и т.д. - koyodza(14.11.2012 16:09)