[aaarrr 69]

Так как это хобби - ну выкину я несколько тыр на LAN, если оно заработает - получу удовольствие.

Боюсь что в этом случае в нагрузку к удовольствию пойдет еще гора сетевого оборудования. Громоздко слишком для "умного дома".

[CSS 0]

Простите за настырность, а какое ещё? Ну LAN модули. Витуха и свитч?

Есть, положим, UASRT у микроконтроллеров. И шо с ними делать? Читать про RS-485?.. И поверх вешать свой протокол?

С чего начать-то? Начать хочется... Физический интерфейс?

Изменено 28 июня, 2010 пользователем C.S.

[aaarrr 69]

Простите за настырность, а какое ещё? Ну LAN модули. Витуха и свитч?

Свитчам нужны еще источники питания, получите в результате пионэрнет с ворохом проводов в отдельно взятой квартире - а оно надо?

 

Есть, положим, UASRT у микроконтроллеров. И шо с ними делать? Читать про RS-485?.. И поверх вешать свой протокол?

С чего начать-то? Начать хочется... Физический интерфейс?

Почитать про RS-485 в любом случае полезно. Заодно рекомендую почитать про CAN - в вашем случае он вполне подойдет.

[adnega 11]

Себе дома сделал на CAN. Контроллер сам по себе: управляет выходами, по информации со входов и другим признакам. Однако, есть возможность "кинуть в сеть" уникальный идентификатор события и принять событие из сети. Возможно передавать параметры в теле события.

 

По CAN прошивается логика, устанавливается время и т.п., а также гоняется аудио-трафик с нескольких переговорных блоков. Есть преобразователь CAN в Ethernet (UDP), для "общения по сеточке" с буком и внешним миром.

 

Скорость делал, вроде, 500 килобит, проверял на катушке CORE4, метров на 100 работает устойчиво (правда терминаторы подбирал щепетильно с осциллографом, но на мегабите).

 

Идентификаторы в контроллеры зашиваю железные. Раз в секунду все контроллеры грят "я жыф".

[MrYuran 18]

С чего начать-то? Начать хочется... Физический интерфейс?

Сегодня в моде AIR

Проводки остались в прошлом веке.

Радиомодуль простенький стоит от 25р

Есть готовые интегрёные решения, типа CC430 у TI, нанонет (по-моему) у мелкочипа и у атмела тоже что-то завалялось.

 

Раз в секунду все контроллеры грят "я жыф".

А оно надо?

Пусть говорят, когда их спрашивают. Типа:

- 12-й, ответь 3-му...

-12-й на связи!

[adnega 11]

Радио не могу назвать надежным и безопасным.

 

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

 

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

 

Я проектировал распределенную систему...

 

+ кста, насчет проводков: а питание?

Изменено 29 июня, 2010 пользователем adnega

[CSS 0]

Тшшш, ребят! Я только-только подбираюсь к теме, и вообще пока не ориентируюсь.

 

Почитал про RS-485 и DMX-512. Я правильно понимаю, что фактически 485й, это как бы паралельное включение всех приёмников и передатчиков? Ну то-есть, если я передаю - все принимают. Кто-то передаёт - все тоже принимают (в том числе и я). А уж чего с принятым делать - это задачи протокола?

 

И ещё вот какой вопрос: видел, что RS-485 можно гнать по двум витым парам: одна чисто для передачи, другая чисто для приёма.

Для начинающих проще, или нет с двумя витыми связываться? По одной тупо отправлять команды, по другой - получать от них ответ?

[ViKo 1]

А как насчет LIN?

[adnega 11]

А почему не CAN?! Если нужно гонять данные до 8 байт, то самое простое решение (или нет?).

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

Что касается витой пары, то дифференциальная пара, высокая скорость, не дорого и понятно.

Кодить тоже приятно и не сложно. По сути реализовать буфер приемника сообщений и буфер передатчика сообщений. Не сложно делать преобразователи CAN что в RS232, что в Ethernet.

 

Где минусы?! У меня восемь месяцев - полет нормальный; верните на грешную землю)

[CSS 0]

Эээ... так я же всех тут вопросами потом достану %)

LIN, вроде не совсем скоростной? Мой критерий скорости - чтобы было не хуже DMX-512 (примерно 10-20 мс на одну команду), так как я маньячу по управлению освещением. RS-485 всё равно основа основ?

2adnega А вот у меня есть штук 5 АТМег 8ых. Я ни одного примера ещё не видал - у меня получится CAN сваять так, чтобы не расстроиться сразу и не бросить? Я хотел начать с простых байт туда-сюда...

[adnega 11]

5 mega8 по CAN связать, не то чтобы не получится... проще сделать на контроллере где есть аппаратный CAN.

В avr-семействе есть такие, но я их не пробовал. Может, лучше махнуть сразу на C-M3? ;)

[syv 0]

Никакой корявости, говорите?

А пляшущий эндианизм в Modbus-RTU?

Это вовсе не сложности.

Задачка для одной команды современного МК.

Кстати, почему эндианизм вместо чередования байт?

А избыточные заголовки, с указанием длины в регистрах (которые всегда 2 байта) и байтах?

А в стандарте расписано для чего.

 

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

Самое привлекательное в MODBUS - простота реализации и реальная открытость протокола.

Кроме этого, в MODBUS все демократично, если что не так - заводите свои команды и пользуйтесь.

[aaarrr 69]

Кстати, почему эндианизм вместо чередования байт?

Тогда уж порядок, а не чередование.

 

А в стандарте расписано для чего.

Для чего предназначены поля - расписано. А вот почему информация бездумно дублируется - нет.

 

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

Самое привлекательное в MODBUS - простота реализации и реальная открытость протокола.

Кроме этого, в MODBUS все демократично, если что не так - заводите свои команды и пользуйтесь.

И снова приходим к закономерному выводу: от протокола нам на самом деле нужна простота, открытость и "демократичность". То есть как таковой стандарт ценности не имеет, нужен "скелет", на базе которого будет построено что-то свое.

 

Жадные организации, создающие заумные протоколы, вообще-то работают над их усовершенствованием. А если бы за Modbus надо было что-то платить, он бы скончался еще лет двадцать назад.

[syv 0]

Для чего предназначены поля - расписано. А вот почему информация бездумно дублируется - нет.

 

И снова приходим к закономерному выводу: от протокола нам на самом деле нужна простота, открытость и "демократичность". То есть как таковой стандарт ценности не имеет, нужен "скелет", на базе которого будет построено что-то свое.

Мне, как лицу, эксплуатирующему огромное количество электронных "покидух" в сфере промавтоматики хотелось бы, чтобы все придерживались стандартов как можно ближе.

К примеру, ПЛК "ОВЕН" не прошел проверку, поскольку его разработчики имели свое, отличное от стандарта представление именно о MODBUS/RTU.

Жадные организации, создающие заумные протоколы, вообще-то работают над их усовершенствованием. А если бы за Modbus надо было что-то платить, он бы скончался еще лет двадцать назад.

Ой, неправда Ваша.

К примеру, частотные преобразователи CIMR-V7 от OMRON или VFD от DELTA вовсю используют именно MODBUS.

Да и вообще, в области частотных инверторов MODBUS/RTU де-факто стандарт.

Для PLC бюджетного ряда тоже. MODBUS/RTU включен в перечень поддержки удаленными модулями таких фирм, как Beckhoff и Wago Systems.

Что-то не похоже на умирающего.

А вот заумный PROFIBUS, похоже, скоро окончательно сдохнет. От него даже SIEMENS уходит, правда, в еще более заумные дебри в виде PROFINET.

Устройства на CAN-оподобных шинах, типа DeviceNet применяются крайне редко в виду плохого сочетания цена/скорость.

HART практически не применяется. Приборы КИПиА просто цепляются на токовую петлю. Каждый на свою.

 

 

[aaarrr 69]

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

 

Мне, как лицу, эксплуатирующему огромное количество электронных "покидух" в сфере промавтоматики хотелось бы, чтобы все придерживались стандартов как можно ближе.

Мне тоже, но для этого стандарты должны быть современными. В противном случае приходится или уродовать и усложнять интерфейсы нового оборудования, вписывая его в реалии тридцатилетней давности, или "расширять" стандарт, тем самым от него все дальше уклоняясь :(