[rezident 0]

Во-первых, эта задержка нужна для протокола, а не для собственно передачи по RS-485. А во-вторых, если эта задержка задаётся протоколом, то зачем её дополнительно настраивать? :)

Чтобы реализовать протокольную часть связи, нужно иметь возможность реализации на физическом уровне, не так ли?

По закону тов. Мерфи, если есть настройка, то обязательно найдётся пользователь, который настроит неправильно:)

Закон Мерфи гласит, что если вероятность неприятного события отлична от нуля, то оно обязательно произойдет, причем в самый неподходящий момент :) Заложить дополнительную возможность это как соломки себе подстелить. Неоднократно встречались ситуации, когда производитель оборудования был вынужден модифицировать аппартно-программную часть, для реализации возможности подключения его оборудования в уже существующую сеть приборов. Причем доработки были связаны именно с введением дополнительных задержек, реализации поддержки протокола и, например, введения гальванической развязки RS485. Но если вам нравится ходить по чужим и уже известным граблям, то ради Бога! :laughing: Шагайте!

[AHTOXA 18]

Чтобы реализовать протокольную часть связи, нужно иметь возможность реализации на физическом уровне, не так ли?

 

Ерунда. Протокольные задержки реализуются протоколом, задержки физического уровня - на физическом. Если заложить "настраиваемые задержки" на физическом уровне, то протоколу придётся учитывать ещё и их.

 

Закон Мерфи гласит, что если вероятность неприятного события отлична от нуля, то оно обязательно произойдет, причем в самый неподходящий момент :)

 

Вот именно. Потому каждая лишняя настройка потенциально ведёт к неприятному событию.

 

Неоднократно встречались ситуации, когда производитель оборудования был вынужден модифицировать аппартно-программную часть, для реализации возможности подключения его оборудования в уже существующую сеть приборов. Причем доработки были связаны именно с введением дополнительных задержек, реализации поддержки протокола и, например, введения гальванической развязки RS485.

 

Предлагаете и гальваноразвязку делать в качестве настраиваемого параметра? :) Ещё раз: это — протокольные дела. Подстройка протокола - это нормально. Но вопрос стоял о работе физического уровня. Я так понял, что для него удержание линии по окончании передачи таки не нужно.

 

Но если вам нравится ходить по чужим и уже известным граблям, то ради Бога! :laughing: Шагайте!

 

Когда кончаются аргументы, начинают пугать граблями и рассказывать о своём богатом опыте, ага. А я-то надеялся, что Вы что-то умное мне поведаете...

[rezident 0]

Ерунда. Протокольные задержки реализуются протоколом, задержки физического уровня - на физическом. Если заложить "настраиваемые задержки" на физическом уровне, то протоколу придётся учитывать ещё и их.

Конечно, А как же без этого если реализованы поддержки различных протоколов на одном физическом уровне? Кроме того, задержки в любом случае нужно учитывать, т.к. линия связи RS485 может быть удлинена репитерами. А каждый репитер вносит задержку.

Вот именно. Потому каждая лишняя настройка потенциально ведёт к неприятному событию.

В руках дурака и рогатка - самострел

Предлагаете и гальваноразвязку делать в качестве настраиваемого параметра? :)

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

Ещё раз: это — протокольные дела. Подстройка протокола - это нормально. Но вопрос стоял о работе физического уровня. Я так понял, что для него удержание линии по окончании передачи таки не нужно.

Исходя из вероятности возникновения коллизий, чем меньше время удержания, тем меньше вероятность коллизии. С этой точки зрения нет, не нужно. Но для поддержания протокольной части и увеличения надежности связи - весьма полезно. "Растяжку" линии тоже ведь широко используют для этой же цели (увеличение надежности связи), а ее ведь в стандарте EIA/TIA-475-A нет и в обязательном порядке для функционирования RS485 она не нужна.

Когда кончаются аргументы, начинают пугать граблями и рассказывать о своём богатом опыте, ага.

Пугать? :07: Да ни в коем разе. :) Всего лишь обмен опытом. Как говорится Sapenti sat. :laughing:

[AHTOXA 18]

Конечно, А как же без этого если реализованы поддержки различных протоколов на одном физическом уровне? Кроме того, задержки в любом случае нужно учитывать, т.к. линия связи RS485 может быть удлинена репитерами. А каждый репитер вносит задержку.

 

Тут скорее всё же нужно подстраивать задержку перед началом передачи, нежели задержку по окончании приёма.

 

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

 

Не обижайтесь, я пошутил:)

 

Исходя из вероятности возникновения коллизий, чем меньше время удержания, тем меньше вероятность коллизии. С этой точки зрения нет, не нужно.

 

Здесь полный консенсус :beer:

 

Но для поддержания протокольной части и увеличения надежности связи - весьма полезно. "Растяжку" линии тоже ведь широко используют для этой же цели (увеличение надежности связи), а ее ведь в стандарте EIA/TIA-475-A нет и в обязательном порядке для функционирования RS485 она не нужна.

 

А вот здесь я всё же пока не понимаю. Растяжка - понятно. Она держит незанятую линию в определённом состоянии. А какая польза от удержания линии занятой после окончания передачи? Или Вы имеете в виду, что, зная задержку ответа устройства и удерживая линию занятой после запроса почти всё это время, мы уменьшаем таким образом время незанятого (восприимчивого к помехам) состояния линии?

[rezident 0]

Тут скорее всё же нужно подстраивать задержку перед началом передачи, нежели задержку по окончании приёма.

Дык выше она у меня под №1 шла. А против которой вы возражаете - №2.

А вот здесь я всё же пока не понимаю. Растяжка - понятно. Она держит незанятую линию в определённом состоянии. А какая польза от удержания линии занятой после окончания передачи? Или Вы имеете в виду, что, зная задержку ответа устройства и удерживая линию занятой после запроса почти всё это время, мы уменьшаем таким образом время незанятого (восприимчивого к помехам) состояния линии?

А вы рассмотрите линию как со стороны передатчика, так и со стороны приемника. Начальные условия. Растяжки нет, есть только терминальные резисторы.

- линия свободна и нагружена только на терминальные резисторы. При наличии помех приемники возможно ловят их как ошибочные символы.

- включился драйвер RS485 мастера. Произошел перезаряд линии. Приемники возможно опять словили ошибочный символ. Поэтому здесь для реализации RTUного протокола нужно сделать паузу перед началом передачи, иначе пакет уйдет в никуда. Слейв обязан начать прием только после временнОй паузы определенной величины.

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

- идет передача пакета.

- передача пакета завершена. Если тут же отпустить линию (выключить передатчик мастера), то приемники слейвов имеют шанс словить ошибочный символ. И весь пакет уйдет в помойку. :laughing: Но мастер у нас не дурак и держит линию (своим включенным на передачу драйвером) в течение времени, определяемым требованиями RTU-ной протокольной "паузы".

- пауза закончилась. Мастер отключил трансмиттер. Все свободны.

- ждем ответа от слейва, отбиваясь от помех в линии.

 

Вот примерно такой расклад.

 

Кстати, исходя из этой же концепции слейв тоже должен делать паузу после приема пакета запроса перед отправкой ответа. Для уменьшения вероятности коллизии из-за разбежки формирования временнЫх пауз у него и у мастера. Хотя, эта пауза и необязательна. Коллизия в линии RS485 не так уж и страшна. А для протокольной совместимости слейв тоже сделает задержку перед передачей после включения трансмиттера. Главное чтобы мастер успел отключиться к тому времени.

[AHTOXA 18]

Дык выше она у меня под №1 шла. А против которой вы возражаете - №2.

А, ту, что под номером один я целиком и полностью одобряю:)

- передача пакета завершена. Если тут же отпустить линию (выключить передатчик мастера), то приемники слейвов имеют шанс словить ошибочный символ. И весь пакет уйдет в помойку. :laughing:

Это почему? Пакет-то уже принят, целиком, корректный и без ошибок. Слейв должен ответить... Или в MODBUS (вы же про него, да?) положено выкидывать принятый валидный пакет, если после него пришёл лишний символ?

 

Остальное-то всё понятно, с остальным я собственно и не спорил:)

[rezident 0]

Это почему? Пакет-то уже принят, целиком, корректный и без ошибок. Слейв должен ответить...

Дык а слейв еще не не в курсе о том, что весь пакет уже принят. Он должен поймать "паузу тишины", которая и будет означать конец пакета для режима RTU.

Или в MODBUS (вы же про него, да?) положено выкидывать принятый валидный пакет, если после него пришёл лишний символ?

Естественно выкинуть! Откуда слейв знает какой символ лишний? Он обязан принимать все символы. А если какой-то принят с ошибкой, то аннулировать весь пакет. Точно также как если бы CRC правильно принятого пакета не сошлась. Достоверность данных это самое главное в любой системе связи.

 

Вы про семиуровневую модель взаимодействием открытых систем (OSI) что-нибудь слышали?

[AHTOXA 18]

Дык а слейв еще не не в курсе о том, что весь пакет уже принят. Он должен поймать "паузу тишины", которая и будет означать конец пакета для режима RTU.

Понятно. Но это особенность именно MODBUS-RTU, во многих других протоколах это не нужно. Взять хоть MODBUS-ASCII или Wake. Там начало и конец пакета определяются иначе.

Естественно выкинуть! Откуда слейв знает какой символ лишний? Он обязан принимать все символы. А если какой-то принят с ошибкой, то аннулировать весь пакет. Точно также как если бы CRC правильно принятого пакета не сошлась. Достоверность данных это самое главное в любой системе связи.

На самом деле это совсем не естественно:) За достоверность данных отвечает CRC. Другое дело, что у RTU нет поля длины пакета, потому нет иного способа определить его конец. Но RTU - это далеко не единственный протокол, потому на его примере не стоит делать обобщений.

Вы про семиуровневую модель взаимодействием открытых систем (OSI) что-нибудь слышали?

А с чего бы я так упорно делил физический и протокольный уровни? :)

 

Мне кажется, причина нашего с вами спора в том, что я говорю про 485 в общем, а вы - в приложении к RTU. Но теперь, вроде бы, всё прояснилось? :)

[rezident 0]

Понятно. Но это особенность именно MODBUS-RTU, во многих других протоколах это не нужно. Взять хоть MODBUS-ASCII или Wake. Там начало и конец пакета определяются иначе.

Не только Modbus, есть и другие протоколы, использующие формат RTU.

На самом деле это совсем не естественно:) За достоверность данных отвечает CRC.

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

Другое дело, что у RTU нет поля длины пакета, потому нет иного способа определить его конец. Но RTU - это далеко не единственный протокол, потому на его примере не стоит делать обобщений.

Почему это не стоит? Я же везде указываю что это для случаев, когда прибор поддерживает несколько протоколов и в т.ч. какой-то RTU-ный. Если протоколов RTU нет в поддержке прибора, тогда да, наверное можно и не задумываться об этом. Хотя, например, (еще один пример :) ) в (радио)модемах, работающих в "прозрачном" режиме настраиваемые задержки тоже акутальны. Ведь модем, работающий в таком режиме, вообще ничего о протоколе не "знает". Как пример радиомодема , имеющего подобные возможности по настройке параметров (проводной) связи, могу привести "Спектр-433". Разработчики этого радиомодема весьма умные и грамотные специалисты потому, что осознали проблему, задумались и реализовали соответствующие настройки связи. У нас такие радиомодемы кое-где используются. Установлены обычно вблизи антенны, которая может находится довольно далеко (и в недоступном для обслуживания месте) от ближайшей точки/узла/сетевого устройства. На расстоянии до сотни метров. Поэтому используется интерфейс связи именно RS485, а не RS232. Питание радомодему в таком случае подается по свободным проводам того же кабеля связи. Уверяю вас, что возможность настройки задержек и пауз в такой конфигурации связи отнюдь не лишняя.

А с чего бы я так упорно делил физический и протокольный уровни? :)

Т.е. знакомы? И программировали наверняка такие устройства? Тогда неясно, откуда недопонимаение? RS485 работает совмсетно с UART МК. UART работает по прерываниям. На прерываниях UART "сидит" линейный (типа FIFO) или кольцевой буфер, который знать не знает о протоколе. Его задача получить байт, при возможности определить его валидность и поместить в буфер. Разбор содержимого буфера на более высоком уровне осуществляется. Можно конечно кое-что совмещать, а некоторые уровни OSI вообще исключать. Но OSI ведь общую (типовую) структуру связи описывает. Частная реализация может как-то отличаться от типовой.

Мне кажется, причина нашего с вами спора в том, что я говорю про 485 в общем, а вы - в приложении к RTU.

Я говорю, исходя из общего применения, а вы упираетесь в частности. Частное это часть общего, не так ли? ;)

Но теперь, вроде бы, всё прояснилось? :)

Надеюсь :)

[AHTOXA 18]

Не только Modbus, есть и другие протоколы, использующие формат RTU.

Вот именно что протоколы. И это - их задержки. А речь изначально шла про обычный 485й.

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

Да ладно:) Всё же фрейм отвечает в первую очередь за определение границ пакета. И нужен именно для этого. Остальное вторично, всё равно CRC выявит ошибку.

Почему это не стоит? Я же везде указываю что это для случаев, когда прибор поддерживает несколько протоколов и в т.ч. какой-то RTU-ный. Если протоколов RTU нет в поддержке прибора, тогда да, наверное можно и не задумываться об этом.

Ну про RTU в исходном посте (после которого я встрял) точно не было:)

..."Спектр-433"...

Мы их тоже используем:) ИМХО, задержка там связана с радиоканалом, чтобы заново не раскочегаривать передатчик на каждый символ.

Т.е. знакомы? И программировали наверняка такие устройства?

Знаком, программировал. Это было нечто по мотивам X.25, не RTU. И не на микроконтроллерах:) И OSI там было поOSIстей:))) А на микроконтроллерах использовал голый 485, либо Wake.

Тогда неясно, откуда недопонимание?

Я-то как раз уверен, что понимаю всё предельно ясно:)

Передача:

• Канальный уровень(MODBUS Serial Line Protocol): получение пакета с уровня приложения, занятие линии, выдержка интервала 3.5 байта*, отправка пакета на физический уровень, ожидание флага окончания передачи от физического уровня, выдержка интервала 3.5 байта (или поменьше), отпускание линии.
• Физический уровень (EIA/TIA-485): передача байтов из буфера, флаг немедленно по окончании передачи последнего байта.

*Занятие линии и выдержка интервала перед началом передачи могут быть перенесены на физический уровень.

 

Приём:

• Физический уровень принимает байты и отправляет их на канальный.
• Канальный уровень их проверяет, складирует в пакет и засекает тайм-ауты.

Как видите, всё замечательно делится по уровням OSI. И я продолжаю утверждать, что на физическом уровне задержка по окончании передачи - не нужна. Ибо при наличии сверху протокола типа RTU будет мешать ему выдерживать свои, протокольные паузы, а при отсутствии оного - увеличивать вероятность коллизий при слишком быстром начале ответной передачи.

 

Я говорю, исходя из общего применения, а вы упираетесь в частности. Частное это часть общего, не так ли? ;)

То есть, по-вашему, RTU over RS-485 - это общее, а RS-485 - частности? :)

[shasik 0]

2 AHTOXA & rezident :bb-offtopic:

Помните как все начиналось:

Каким образом мне поймать момент опустошения сдвигового регистра, чтобы переключить направление передачи? Сделал по таймеру, но в этом случае отправляется лишний байт и как-то не нравится такое решение. Кто может что-то предложить?

[rezident 0]

То есть, по-вашему, RTU over RS-485 - это общее, а RS-485 - частности? :)

Если выражаться математически, то протокол + физический уровень это общее от множества связи, а физический уровень это всего лишь подмножество, входящее в множество :)

В вашем описании, управлением передатчика физического уровня почему-то занимается непосредственно канальный уровень. В моих реализациях физический уровень сам управляет направлением передачи драйвера, в соответствии с заранее установленными параметрами (паузами и задержками). Эти параметры может задавать пользователь или наладчик оборудования, одновременно со сменой типа протокола связи.

 

2 AHTOXA & rezident :bb-offtopic:

Помните как все начиналось:

Ну дык сказали же уже. Либо нужно отсчитывать задержку как минимум в один символ от прерывания передатчика (или от установки флага TXIFGx), либо опрашивать TXEPT и отсчитывать от момента установки его задержку не менее одного битового интервала для выбранной скорости передачи. Насчет лишних байт, ИМХО у человека всего лишь некорректная реализация буфера передатчика.

[landrey 0]

Можно сделать следующий финт ушами:

На время передачи подключить UTXD к URXD (бит LISTEN). После того, как последний передаваемый байт помещается в сдвиговый регистр, бит LISTEN убираем.

А уже в прерывании по приему проверяем, если бит LISTEN выставлен, то это принято эхо - ничего не делаем, если сброшен и направление передачи было на "Передачу", то переключить направление передачи на "Прием".

[AHTOXA 18]

2 AHTOXA & rezident :bb-offtopic:

Помните как все начиналось:

 

Ещё пара страниц, и мы бы вплотную к этому подобрались:)

 

Если выражаться математически, то протокол + физический уровень это общее от множества связи, а физический уровень это всего лишь подмножество, входящее в множество :)

 

Шикарно :a14:

Теперь я понял, зачем ранее была упомянута опторазвязка - для ещё большего увеличения общности :)

 

В вашем описании, управлением передатчика физического уровня почему-то занимается непосредственно канальный уровень. В моих реализациях физический уровень сам управляет направлением передачи драйвера, в соответствии с заранее установленными параметрами (паузами и задержками). Эти параметры может задавать пользователь или наладчик оборудования, одновременно со сменой типа протокола связи.

 

Я не знаю, как бы я это реализовал, если бы стал делать, вполне возможно так же, как вы. Но с точки зрения OSI отмерять задержки должен канальный уровень, потому я так написал. А на приём тайм-ауты у вас тоже физический уровень ловит?

 

Можно сделать следующий финт ушами:

 

Отлично. Замечу только, что есть более универсальное решение: не отключать приём у драйвера 485. Далее - аналогично.

[ashr 0]

Можно сделать следующий финт ушами:

На время передачи подключить UTXD к URXD (бит LISTEN). После того, как последний передаваемый байт помещается в сдвиговый регистр, бит LISTEN убираем.

А уже в прерывании по приему проверяем, если бит LISTEN выставлен, то это принято эхо - ничего не делаем, если сброшен и направление передачи было на "Передачу", то переключить направление передачи на "Прием".

Кто-нибудь так делал? Это работает?

А то у меня тоже скоро будет аналогичная проблема (для решения на основе таймера нужно еще иметь свободный таймер, отсюда и интерес к этому "финту ушами").