[VCucumber 0]

По какому принципу сделать сабж ?

Шина типа rs485, хочется получить нечто типа plug&play.

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

[MrYuran 17]

Тогда только дополнительные линии. Для раздачи адресов. У нас была такая система. Модули включались друг за другом по цепочке и друг другу передавали последовательные адреса.

[VCucumber 0]

А интересная, кстати, мысль (хоть и не подходит) - если сделать "кольцо", то очень даже будет работать. При том, что rs422 + никаких коллизий. И с терминаторами все прозрачнее.

[MrYuran 17]

Да нет, всё не так. не кольцо, RS485 как обычно, шиной параллельно на все. А вот дополнительная линия "адрес" проходила последовательно через все модули. Модулей было много, 512 штук, размещались в контейнере 600х60 см (ФАР). Для раздачи адресов подавалась команда ввода адреса, через модули прогонялись адреса и защёлкивались в флеше. Если какого-то модуля не хватало, вместо него надо было ставить заглушку (перемычку адреса).

В общем, вместо plug&play получился, как обычно, plug&pray (включай и молись).

Куча времени уходила на поиск дефектов монтажа. Но альтернатива - только прописывать адреса вручную (что ещё хуже)

[Alex11 3]

Тут есть еще один вопрос. Что на самом деле нужно автору. Определить, какие устройства присутствуют на шине или раздать всем имеющимся устройствам адреса. Очевидно, что решения будут разными. И во втором случае возникает интересный вопрос: предположим, мы раздали адреса присутствующим устройствам. А дальше команды/данные мы будем давать кому? Абы какому устройству? Или мы точно знаем, что тому, которое подключено в определенное место? А как мы это поймем, если адреса розданы произвольно. А если устройство знает, куда оно подключено, может проще из этой информации формировать адрес, а при инициализации системы просто опрашивать все возможные адреса.

[VCucumber 0]

Да нет, всё не так. не кольцо, RS485 как обычно, шиной параллельно на все. А вот дополнительная линия "адрес" проходила последовательно через все модули.

Я понял, но для этого нужно по 2 UARTa. Хотя для конфигурации можно использовать медленный софтовый.

 

 

Тут есть еще один вопрос. Что на самом деле нужно автору. Определить, какие устройства присутствуют на шине или раздать всем имеющимся устройствам адреса.

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

 

Или мы точно знаем, что тому, которое подключено в определенное место?

А не всегда это нужно, в моем случае тоже.

Но в части случаев без этого не обойтись.

Тогда альтернатива - конфигурировать идентификаторы в мастере, там же и физическое расположение устройств, адрес на шине по-прежнему может задаваться динамически. Но это уже далеко не plug&play.

[syv 0]

По какому принципу сделать сабж ?

Шина типа rs485, хочется получить нечто типа plug&play.

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

На мой взгляд, изобретение велосипедов - дело неблагодарное. Вместо того, чтобы разбираться со стандартами того же PROFIBUSа, начинается лепня своего псевдостандарта. Посмотрите, чем кончились забавы фирмы "ОВЕН" со своим стандартом. Все кончилось ModBus-ом.

[VCucumber 0]

На мой взгляд, изобретение велосипедов - дело неблагодарное.

SLIP - велосипед ? Да вы што ?

+Можно сделать "как у всех", Wake. Если себя заставить.

Но это все не решает и не снимает вопроса.

 

Все кончилось ModBus-ом.

 

Модбас удобен при стандартизированной передаче отдельных параметров(слов,бит итд).Его применение оправдано при сравнительно небольшом количестве передаваемых данных и наличии нескольких slave устройств в сети.Опять же он является промышленным стандартом и при совместном использовании покупных и кустарных устройств можно задействовать широкий спектр OPC серверов и SCADA систем.Если же требуется передавать поточные данные то более целесообразно использовать что то на подобии wake.имхо.

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

(с) Не мой, но я, в общем, согласен. Сейчас выйдут мелкие(дешевые) камни с CAN и вопросы с выбором XXX-BUS снимутся. А мудрить на половину ресурсов текущего камня MOD-BUS ради гипотетической совместимости с какими-то гипотетическими устройствами которые гипотетически могут быть подключены к той же шине вряд ли целесообразно.

И кроме того, на сколько я успел понять, MOD-BUS так же не решает поставленный вопрос, хотя дополнительные байты идентификатора и м.б. определены. Так чего же ради.

[VCucumber 0]

Все кончилось ModBus-ом.

 

Еще довод против:

 

Передатчик посылает 1-2 байта преамбулы 0xFF, открывающую стаффинг последовательность, RTU пакет, закрывающую стаффинг последовательность, и байт преамбулы. Использую этот подход в радио каналах и серьезно задумываюсь над переносом этого протокола в 485 сети потому что жесткие времянки модбаса слегка достают уже (при том что против формата RTU пакетов я ничего не имею - формат грамотный).

Плюсы:

1. Передатчик волен вставлять любые паузы между символами (актуально когда хост - компьютер с не реал-тайм драйвером UART'a),

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

3. Опять же хост - тот же компьютер с не риалтайм приемником вместо непрогнозируемого таймаута четко распознает конец пакета - что уменьшает время реакции.

[rezident 0]

Еще довод против:

Довод не совсем в кассу. Вы наверное просто не в курсе, что в стандарте ModBus кроме режима RTU есть еще и символьный режим ASCII. У него есть свои недостатки, но, тем не менее, там начало/конец пакета определенными символами, а не временнЫми паузами задается.

 

По теме топика. У каждого устройства должен иметься свой уникальный серийный номер. Исходя из значения этого номера, и должна определяться пауза для выдачи устройством идентификационной информации по широковещательному хапросу. По этому же номеру монтажники должны регистрировать местонахождение прибора. А без наличия карты размещения устройств назначать вслепую сетевые адреса это нонсенс какой-то :07:

Modbus_over_serial_line_V1.pdf

[navy2000 0]

По какому принципу сделать сабж ?

Шина типа rs485, хочется получить нечто типа plug&play.

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

С RS485 красиво сделать не получится. Даже если Мастер пошлет широковещательную команду на которую Слэйвы будут отвечать через случайные интервалы, при этом слушать линию что в нее не передает ктото друго, выдерживать паузу (чтобы отличить передачу бита соответствующего растяжкам линий A и B от тишины в линии), все равно не нулевая вероятность начать передачу одновременно, а это, в отличие от CAN аварийный режим. По этому, ИМХО, смотрите в сторону CAN.

У меня в качестве серийного номера прибора служит 48-бит его Ethernet MAC-адрес. Были конечно сложности с автоматизацией определения устройств в сети (В CAN идентификатор учавствующий в арбитраже только 29 бит), но они были решены. После определения всех MAC-адресов, по ним можно отправлять служебные команды (когда сетевых адресов еще нету), узнавать тип устройства и просить поморгать светодиодом попищать динамиком, после этого ему уже присваивается сетевой адрес.

 

По теме топика. У каждого устройства должен иметься свой уникальный серийный номер. Исходя из значения этого номера, и должна определяться пауза для выдачи устройством идентификационной информации по широковещательному хапросу.

Разница между соседними номерами должна быть более длительности одной посылки (ответа на запрос), а весь диапазон адресов определяется серийностью изделия. Завод может выпускать сотни тысяч приборов в месяц. На конкретном объекте модут собраться приборы из разных партий. Ждать ответов может быть придется очень долго.

[rezident 0]

После определения всех MAC-адресов, по ним можно отправлять служебные команды (когда сетевых адресов еще нету), узнавать тип устройства и просить поморгать светодиодом попищать динамиком, после этого ему уже присваивается сетевой адрес.

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

Разница между соседними номерами должна быть более длительности одной посылки (ответа на запрос), а весь диапазон адресов определяется серийностью изделия. Завод может выпускать сотни тысяч приборов в месяц. На конкретном объекте модут собраться приборы из разных партий. Ждать ответов может быть придется очень долго.

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

[VCucumber 0]

в стандарте ModBus кроме режима RTU есть еще и символьный режим ASCII. У него есть свои недостатки

Согласен, поэтому не нравится.

 

По теме топика. У каждого устройства должен иметься свой уникальный серийный номер.

Есть, уникальный, но он не серийный(последовательный).

 

Исходя из значения этого номера, и должна определяться пауза

Номер 16 байт - слишком длинная пауза получается ))) даже если с шагом через 1us.

Можно бы сделать свертку (crc) до 8 бит.

Можно сделать вместо одного идентификационного запроса - шестнадцать, по одному на каждый байт.

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

 

А без наличия карты размещения устройств назначать вслепую сетевые адреса это нонсенс

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

[navy2000 0]

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

В таком случае при монтаже в документацию (кабельный журнал и еще чего) заносятся МАС-адреса смонтированных устройств, соответствие требуемых сетевых номеров и МАС-адресов доносятся до мастера (человека или программы) который занимается развертыванием сети. Просто, если бибикать не нужно, не используем. это сервис не более того.

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

Если вы говорите про CAN, соглашусь, вариант вполне жизнеспособный. Но, если ваш ответ относится к исходно заданному вопросу (RS-485), то коллизии там не допустимы, нештатная ситуация. А без коллизий, ИМХО, возможно только с теми оговорками что я изложил ранее.

[rezident 0]

Если вы говорите про CAN, соглашусь, вариант вполне жизнеспособный. Но, если ваш ответ относится к исходно заданному вопросу (RS-485), то коллизии там не допустимы, нештатная ситуация. А без коллизий, ИМХО, возможно только с теми оговорками что я изложил ранее.

В RS-485 коллизии допускаются, в том смысле, что это конечно не штатная, но и не совсем криминальная ситуация. Другое дело, что коллизии в RS485 довольно сложно идентифицировать, это да.