caxapa.ru :: Насчет времени прихода ответа - какой-то безбашенный оптимизм. На практике может встретится устройство, начинающее посылать ответ через 0,5сек.

Cкpипaч, пророк (05.01.2024 15:42 - 06.01.2024 00:46, просмотров: 222) ответил Argon на Спецы по модбасу, подскажите, а? У меня на модбасе (RTU) мастер, к-рый общается с несколькими частотниками/сервоприводами.

Насчет времени прихода ответа - какой-то безбашенный оптимизм. На практике может встретится устройство, начинающее посылать ответ через 0,5сек.

И вообще, чем меньше проверок, тем больше шансов получить валидный обмен на шине.

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

Таймируют только максимально-возможную задержку получения ответа.

Типовое значение - 1сек.

Альтернатива - вместо разбора пакета на лету, считать признаком окончания ответа межбайтовую паузу 1,5ch.

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

я бы не рекомендовал такую схему для мастера (хотя для слейва сделал именно так).

... но не любой ценой.

Ответить

- бывает и больше. на столе лежит датчик который читается только по одному регистру и только с паузой в 10секунд LordN(224 знак., 05.01.2024 17:19)
  - Это все же экзотика. Подавляющее большинство устройств, на 9600, ответят в течении 100ms. - Cкpипaч(06.01.2024 13:01)
    - Версий модбасов сколько разработчиков. Хорошо если сам мастер и есть возможность на самом низком уровне обмена подстроиться под особенности реализации. И чем больше разных производителей на шине тем вероятнее получить головняк. - vasily777(06.01.2024 19:27)
      - Если не пытаться мудрить, то и мастер подстраивать не придется. У меня опыт подключения в нашу АСМУ более сотни разных брендов. Cкpипaч(745 знак., 06.01.2024 19:51)
        
        В вашей Асме какое время реакции? Пришлось как то поиметь проблему с расходомером одного российского производителя. Он воспринимал свой запрос только после паузы на шине около 0,5секунды, вне зависимости от скорости обмена. Задача была держать заданный расход по частотнику. Благо что расход не быстро менялся и тормозить шину нечасто нужно было. Но были вопросы от операторов: а чего оно не сразу выключается, если оператор "удачный" момент выбрал. - vasily777(06.01.2024 20:55)
        
        Частота обновления экрана - раз в секунду, плюс секунда на опрос шины и полторы секунды на запись в базу данных. Итого, с запасом на "не-риалтайм" - 5 секунд, на меньшее я бы не подписался. Cкpипaч(173 знак., 06.01.2024 21:15)
    - да вот хз, экзотика или нет. LordN(276 знак., 06.01.2024 19:18)
      - ...а вот эти вот все абсолютно незнакомые мне слова... это типа, бренды? Или все исключительно поделки из сарая дядюшки Ляо? Cкpипaч(78 знак., 06.01.2024 19:38)
        
        тебе проще, а мне приходится все это заставлять работать LordN(14 знак., 07.01.2024 20:59)
- Мы как-то накололись с ОВЕНовским контроллером, который межбайтовую паузу сильно (превышая стандарты Modbus) растягивал. По пути конечно наши программисты и свой глюк выловили, но поводом к его проявлению именно превышение межбайтовой паузы в ответе ОВЕН послужило. А вообще в нормальной реализации протокола RTU должны быть настраиваемые параметры у слейва, как минимум 1) задержка перед ответом на запрос и 2) максимальный таймаут ответа. Во втором случае слейв не reZident(78 знак., 05.01.2024 15:43 - 15:46)
  - Странно это. По идее, ответ весь целиком передается из буфера, по прерыванию "буффер передатчика пуст", никто не собирает ответ "на лету", откуда может появиться межбайтовая пауза? - Cкpипaч(05.01.2024 15:45)
    - В буфер надо сначала ответ положить, а для этого надо его сначала сформировать, а для этого надо сначала разобрать запрос, а для этого надо сначала посчитать контрольную сумму запроса, а для этого надо сначала дождаться окончания 3,5 байтного интервала после последнего байта запроса. Но даже на 1 МГц (реальной частоты) 51ом это не занимало много времени, уж точно не 10мс. Так что ожидание в 10мс - это более чем достаточно. Хотя у нас в одном приборе (из-за ограниченности symbions(653 знак., 05.01.2024 17:53)
      - У нас в одном из (очень) старых приборов был всего один таймер. К прерыванию таймера были привязаны обработчики всех событий и период этот составлял 1/64сек=15,625мс. reZident(869 знак., 05.01.2024 21:19)
    - Спросите это у разработчиков ОВЕН. Пока мы на столе не собрали систему полностью аналогичную той, что была на объекте (включая именно такой же контроллер ОВЕН), глюк в нашем софте никак не проявлялся при многодневных проверках на имитаторах как мастера, так и слейвов. - reZident(05.01.2024 15:48)
      - Типичное, горе от ума, горе от следования протоколам, вопреки здравому смыслу. Сделали бы просто "таймаут ответа", даже бы и не узнали про эти проблемы.Один коллега сказал, я запомнил, "не надо размножать аварию", не надо приувеличивать проблему, если система может функционировать при этой неисправности, то и х с ней. - IBAH(05.01.2024 21:40)
        
        Причем тут таймаут ответа? ОВЕНовский контроллер при передаче фрейма иногда (не всегда) по какой-то своей причине "тормозил" с межсимвольной (!) паузой длительностью даже не 1,5 символа, а больше 3,5 символа! - reZident(05.01.2024 21:52)
        
        Речь идет о овеновском сервере или клиенте? о сервере то и х с ним. Если клиенте, то нефиг следовать установке 3.5 символа, она придумывалась когда модбас был полуаппаратным - IBAH(05.01.2024 22:07)
        
        Мая твая непонимай :-( - reZident(05.01.2024 22:23)
        
        клиент - мастер, сервер - слайв - IBAH(05.01.2024 22:45)
        
        Толерантненько как-то... Но в свежем стандарте теперь так. - Nikolay_Po(05.01.2024 23:16)
        
        По-русски все просто: господин и раб. Четко и однозначно. А толерастные нацики пусть катятся куда подальше. - Eddy_Em(05.01.2024 23:24)
        
        Ну, я всё же за ведущего и ведомого. - Nikolay_Po(05.01.2024 23:35)
        
        Как вариант. А мне ближе непосредственный перевод. - Eddy_Em(05.01.2024 23:47)

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