[chefdesigner 0]

Дано:

1. 20-30 Ведомых устройств в сети, над ними один Ведущий. Таким образом, логическая топология сети-звезда.

2. Физическая топология сети - один луч витая пара, на луче сидят Ведомые.

3. Время реакции Ведущего на события у Ведомых допустимо до 0,5 с, и наоборот - до 0,5с.

4. Сеть раскидана по площади примерно с квартиру, помехообстановка тоже соответствует примерно жилому помещению.

5. Ведомые питаются от своих SMPS от одной силовой сети 220В.

 

Инфооборот по этой сети мал:

1. Ведущий спрашивает Ведомого жив или нет.

2. Спрашивает состояние Ведомого(8 бит - максимум).

3. Даёт команду Ведомому(8 бит - максимум).

 

Вопросы такие. Вобщем, это можно сваять многими разными способами. Но, я, поскольку не имею практического опыта в этом деле, прошу совета у знающих, кто раскидывал похожие сети, на чем это сваять так, чтобы было посовременнее чтоли. Интересует только низко... как бы это сказать... низкоуровневая сеть. Про IP и даже езернет неинтересно.

 

Итак, вопросы:

1. CAN или RS485?

2. Нужна ли в данной физической обстановке опторазвязка Ведомых от витой пары-луча?

3. Какие IC-приёмопередатчики CAN/RS485 <-> UART посоветуете?

4. Я правильно понимаю, что в такой сети можно обойтись RS485 с тайм-слотом в сотню-другую миллисекунд? и чем лучше будет применение CAN?

5. Какие-то наработки из MODBUS тут применимы? при условии, что всё фирмваре я буду делать на ассемблере? система-закрытая, не будет общаться с вне.

 

Ну, и, обладаю бюджетом, готов рассмотреть готовое решение Сеть<->GPIO, чтобы не делать самому. других дел хватает. Предложения рассмотрю, шлите их, пожалуйста, в личку. но здесь обсуждать не буду. Здесь я хочу обсудить, что быстро, "на коленках", можно сваять мне самому.

Изменено 8 декабря, 2014 пользователем In_an_im_di

[smalcom 0]

1-2. изолированный 485-й

3. те что есть в местном магазине

4. не регламентировано. ка напишете так и будет.

5. с MODBUS вам легче будет вести документацию - как минимум через год протокол вспоминать не надо. Есть библиотеки. Если купить какой-нибудь пром.контроллер с MODBUS сможете всё это объединить.

 

Ну, и, обладаю бюджетом, готов рассмотреть готовое решение Сеть<->GPIO

ключевые слова: MODBUS(если надо), GPIO, DIN-рейка.

[ДЕЙЛ 24]

1. CAN или RS485?

2. Нужна ли в данной физической обстановке опторазвязка Ведомых от витой пары-луча?

3. Какие IC-приёмопередатчики CAN/RS485 <-> UART посоветуете?

4. Я правильно понимаю, что в такой сети можно обойтись RS485 с тайм-слотом в сотню-другую миллисекунд? и чем лучше будет применение CAN?

5. Какие-то наработки из MODBUS тут применимы? при условии, что всё фирмваре я буду делать на ассемблере? система-закрытая, не будет общаться с вне.

имел дело с RS485, могу сказать, почему применил бы его

1. Число ведомых до 32 нагруженных, как подсказывает википедия

2. Опторазвязка никогда лишней не будет, я имел дело с преобразователями RS485<>232 MAX1480, если правильно вспомнил. Древние, дорогие, но с трансформатоной развязкой по питанию и опторазвязкой по передаче данных. Ещё они дубовые, т.е. надёжные.

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

 

[psL 0]

Трансивер CAN умеет автоматическое переключение направления обмена, а трансивер RS485 - нет. CANOpen умеет PDO, а Modbus - нет. Если подчиненные - датчики, то CAN предпочтительней. Но CANOpen сложнее Modbus.

Видимо пакет управления длиной 8 бит - очень оптимистично. 8 бит - это 8 портов GPIO?

[chefdesigner 0]

Видимо пакет управления длиной 8 бит - очень оптимистично. 8 бит - это 8 портов GPIO?

8 бит это байт, пересылаемый по сети.

чую, что надо бы на CAN всё это сделать, дабы было сделано. На 485 там всё ручками просто делается, вроде. MODBUS не нужен, просто навязывается заказчиком и я не понимаю, почему. Там в мире модбасов тьма, накой в эти релизы мне вникать, мне дело сделать надо и потом делать другие дела.

Изменено 8 декабря, 2014 пользователем In_an_im_di

[smalcom 0]

Для "дёргать ножками" в квартире CAN сверхизбыточен. А PDO в данном случае - это процесс ради процесса.

 

Видимо пакет управления длиной 8 бит - очень оптимистично.

хм, как вариант

7 - всегда один(типа синхронизация)

6 - "0" - запрос состояния, "1" - установка состояния

при установке состояния:

5 - новое лог. сост. GPIO

4-2 - номер GPIO

 

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

Получаем ещё два свободных бита. Нехватает для адресации 30 устройств. Да, 8 бит - это оптимистично.

--------------

вникать, мне дело сделать надо и потом делать другие дела.

в данном свете рекомендую просто купить готовое оборудование.

[chefdesigner 0]

2. Опторазвязка никогда лишней не будет,

ок, спасибо

 

в данном свете рекомендую просто купить готовое оборудование.

продайте, куплю.

[psL 0]

8 бит это байт, пересылаемый по сети.

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

Про байт понятно:) Непонятно назначение этого байта. Байты же сами собой по сети не ходят. Вообще, если не секрет, какое назначение у подчиненных устройств?

Modbus RTU - неформальный стандарт для всякого АСУТП.

 

[chefdesigner 0]

Вообще, если не секрет, какое назначение у подчиненных устройств?

Modbus RTU - неформальный стандарт для всякого АСУТП.

 

Это и есть АСУТП с быстродействием в полсекунды.

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

 

ну, то есть, что достаточно слота 100мс на 9600 на всёпровсё. 485 и не парицо.

 

Времена всегда одни и те же?

Изменено 8 декабря, 2014 пользователем In_an_im_di

[psL 0]

Это и есть АСУТП с быстродействием в полсекунды.

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

 

ну, то есть, что достаточно слота 100мс на 9600 на всёпровсё. 485 и не парицо.

 

Времена всегда одни и те же?

на 9600 1 байт передается ~1 мс, но у вас будет не 1 байт. Посмотрите описание CAN, либо Modbus. В кадрах для канального уровня присутствует синхронизация и контроль целостности, для сетевого уровня - адрес.

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

А еще для "самодельной" сети существует проблема распределения адресов между подчиненными.

 

[Lagman 1]

Если хотите чтобы датчики сами (без их опроса со стороны мастера) начинали передачу по какому либо событию, то модбас не подойдет.

[toweroff 0]

Так старый добрый X10 чем не устраивает? И никаких лишних проводов, все по силовой

Получится 100 бит/с, пример реализации на PIC у Микрочипа пылится уже ковырнадцать лет

[chefdesigner 0]

на 9600 1 байт передается ~1 мс, но у вас будет не 1 байт. Посмотрите описание CAN, либо Modbus. В кадрах для канального уровня присутствует синхронизация и контроль целостности, для сетевого уровня - адрес.

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

А еще для "самодельной" сети существует проблема распределения адресов между подчиненными.

Ведомые будут передавать по запросу от Ведущего как только "услышат" свой адрес в сети. тайминги, да. Адресов мало, штук 30, остальная часть байта будет командой Ведомому, что передать обратно и что исполнить. Таким образом, достаточно байта для логического обмена(пять бит - адрес 0-31, и три бита - команда 0-7, что достаточно для моего применения)

Конфигурироваться сеть будет "ручками", адреса будут физически прописываться в Ведомые, в прошивки их процессоров.

Я правильно понимаю сей процесс?

Изменено 9 декабря, 2014 пользователем In_an_im_di

[psL 0]

Ведомые будут передавать по запросу от Ведущего как только "услышат" свой адрес в сети. тайминги, да. Адресов мало, штук 30, остальная часть байта будет командой Ведомому, что передать обратно и что исполнить. Таким образом, достаточно байта для логического обмена(пять бит - адрес 0-31, и три бита - команда 0-7, что достаточно для моего применения)

Конфигурироваться сеть будет "ручками", адреса будут физически прописываться в Ведомые, в прошивки их процессоров.

Я правильно понимаю сей процесс?

Если не хочется заморачиваться с обеспечением достоверности данных в канале видимо лучше использовать CAN. В поле данных кадра можно передавать до 8 байт. Контроль целостности кадра при этом будет выполнять узел CAN контроллера.

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

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

[chefdesigner 0]

спасибо за советы.

 

физическая раскладка сети. сегодня побывал на объекте, позырил, и с "лучём" витой пары вырисовалась такая ситуёвина: луч длиной метров 150-200, подключиться к лучу можно в десятке мест примерно(это уже данность, не изменишь). подключения будут длиной до метров 3-х "звёздочки" такие, мдя.

 

тут вижу два варианта для себя.

 

1. на доступном месте разрез луча с установкой розеток на концах, и далее подключаюсь в петлю и сохраняю топологию линии но увеличиваю число контактов в сети.

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

 

что посоветуете, бывалые в этой теме?