Здравствуйте. Тема эта уже затрагивалась, но вразумительного четкого ответа я не нашел. У меня на объекте есть вентустановки, которые необходимо диспетчеризировать. К сожалению У них уже поставлены свои шкафы автоматики, но есть возможность подключится к ним по интерфейсному выходу. Теперь вопрос: Какой выбрать LON или Modbus?
Диспетчеризация на бекхофе. Звонил им , они говорят проще модбас. Читал статейки всякие. Модбас как протокол в автоматизации зданий мало используют, в основном LON. Почему интересно? Ведь на модбасе же проще?
А еще я так и не понял как организовывается связь между устройствами по протоколу LONworks. объясните на пальцах плиз
По модбасу вроде все ясно, общение мастер - слэйвы, посредством запросов. достаточно правильно запрос осуществить.

Решение на Modbus, в данном случае, будет намного дешевле и проще Lon.
В любом случае пришло время налаживать отношения с поставщиком этих щитов, что бы он выдал таблицы сетевых адресов и регистров модбас, или snvt.

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

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

зы мое мнение что будущее конечно за бакнетом но к сожалению еще не скорое

Если все сделано на Beckhoff тогда однозначно Modbus причем в вашем случае еще и поверх IP, так как Beckhoff в основном ориентирован на Ethernet.

Расскажите поподробнее , что вы имеете ввиду пожалуйста

Интересно, чем Модбас проще , чем Лон? Лон очень схож с Езернетом, позволяет вести передачу напрямую от одного устройства к другому, при этом передача идет только при необходимости (изменение состояния).Доступ к шине как и в Езернете носит случайностный характер и реализован механизм разруливания и предотвращения коллизий. Все это позволяет повысить скорость обмена данными и снизить нагрузку на информационный канал. Вот в этой статье вполне доступно изложено ознакомление с Лоном.http://www.rtsoft-training.ru/?p=600041
С другой стороны необходимо определиться с топологией сети автоматики - а нужно ли вам, чтобы устройства общались напрямую между собой? Очень часто этого не требуется. В большинстве случаев вполне достаточно распределенной системы, когда "местный" контроллер опрашивает датчики и управляет исполнительными устройствами какой-либо подсистемы здания и попутно выдает данные на верхний уровень и получает от него команды. И нет необходимости общаться между собой контроллерам подсистем.
Например контроллеру вентиляции не нужно обмениваться данными с контроллером управления станцией хозпитьевого водопровода.
Но есть и другие примеры, когда прямая связь между контроллерами вполне оправдана. Например связь между контроллером пожарной сигнализации, СКУД,вентиляции, системы автоматического пожаротушения.
Эти системы работают взаимосвязанно при пожаре и если их контроллеры подключить в одну сеть, то можно неплохо сэкономить на проводах. В большинстве случаев такие связи делают на "сухих" контактах, тем самым увеличивая число дополнительных кабельных соединений.
КОнечно, можно аналогичную связь контроллеров можно сделать и через головной (мастер), но тогда в нашей цепочке данных поямляется лишнее устройство, а чем больше устройств, тем ниже надежность системы.

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

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

А в российских реалиях состыковать, например, Bolid и Beckhoff можно только на уровне SCADA, подключив Bolid через OPC сервер, а Beckhoff по протоколу Modbus. Соответственно сломалась SCADA - вентиляция не отключится при пожаре. Провод - это надежно и стоит копейки в общем объеме монтажа.

У Rus75 всегда "особый подход" к делу!!!

Beckhoff выпускает много контроллеров, но с высокой долей вероятности у Вас стоит не модель с портом RS-485, а модель с портом Ethernet. Например вот такая:



Надпись X900 обозначает порт подключения к полевой шине, в данном случае это Ethernet он же грубо говоря банальная "локальная сеть". Т.е. через Ethernet подключиться проще всего. Кстати на этом контроллере есть еще CAN, два порта RS-232 и один порт RS-485. Однако я не знаю, такой у Вас контроллер или нет.

Есть так же контроллер с RS-485:



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

У меня заложен BC9000 , А к нему модуль EL6021 (485,422).


Т.е. на базе этого модуля создается модбас сеть А BC9000 подключается просто в свободный порт СКС.

Прикольно, но другими словами вы выразили ту же мысль, что и я.
Я не агитирую стыковать в сеть оборудование разных мало совместимых или не совместимых между собой систем. Как вы правильно заметили и как я писал выше - дополнительные элементы в системе снижают надежность.
А вот на вновь создаваемых объектах применяя комплексные решения можно прилично сэкономить и при монтаже,наладке и при последующем обслуживании.

Можно релическое отступление от темы?

Я тут на днях сдавал парочку своих систем автоматизации в одном многофункциональном здании и мне стало просто жалко службу эксплуатации от ассортимента примененного на объекте оборудования .
Общая пожарная сигнализация выполнена на Болиде , помимо нее есть еще газовое пожаротушение со своими "забугорными" контроллерами, охранная система на Гольфстриме, водопровод и теплоснабжение -Wilo,Кондиционирование -Митсубиши, вентиляция - Segnetics и Carrier, электрическая часть контрололя и управления на ABB. Узел теплового учета - Логика СПТ-91 и еще куча всего по мелочевке. Благо, что большинство этих систем работают автономно, либо диспетчеризируются сухими контактами. Но все-равно разнообразие в парке управляющих контроллеров впечатляет и состыковать эти системы на протокольном уровне было бы сложно.
Служба эксплуатации носится за монтажными организациями с просьбой дать им краткие руководства пользователя по смантированным системам, а то им накидали тонну томов руководств производителей, в которых 99% информации просто не нужны для эксплуатации, а больше нужны проектировщикам систем.
А каково будет службе эксплуатации через год, когда гарантия закончится и они останутся один на один со всем этим оборудованием, придется общаться с десятком производителей.
А еще видили бы вы киллометры различных кабелей, опутывающие здание. Это просто мама не горюй. Даже с боле-менне прилично выполненной исполнительной документацией найти нужный кабель довольно сложно, а я уж молчу о некоторых неродивых монтажниках, которые изменяют начальные проекты и не вносят эти изменения в исполнительную.

И другой пример. Вновь создаваемое производство . Для автоматики используем одного единственного производителя промконтроллеров и блоков ввода вывода со своим программным обеспечением. На нижнем уровне контроллер попроще, на верхем посерьезнее. Оборудование сертифицировано и включено в реестр средств измерения. В итоге парк оборудования сокращается до двух-контроллеров - шести наименований ввода вывода. Одно программное обеспечение. Собирать и обрабатывать сигналы от разных систем одно удовольствие, Склад ЗИП минимален из-за унификации. Не нужно мудрить со шлюзами и т.д. На обучении персонала тоже экономия, т.к. работать нужно только с одним оборудованием.
Вот только второй вариант почему-то прокатывает на пром.предприятиях в Сибири, но никак не получается реализовать на общественных в Москве.

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

Вы немного запутались. Раскладываю по полочкам.

1. EL6021 НЕ РАБОТАЕТ с контроллером BC9000. У BC9000 шина К-Bus, у EL6021 шина Ethercat.

2. У контроллера BC9000 мозгов мало. Рекомендую купить один для экспериментов. В него может не влезть библиотека Modbus.

Магу посоветовать контроллер BC9020 с модулем KL6041. Работает идеально как с MBus RTU так и с MBus ASCII. Проеренно лично.

Возвращаясь к первоначальному вопросу. Modbus в данном случае будет предпочтительнее LONa. Он сильно проще и в обучении, и в настройке.
Главное, и в данном случае основное, преимущество LONа -- децентрализованная коммуникация -- для диспетчеризации не важна. А полноценно разбираться со снивитами, байндингами, лонмейкерами и прочими неологизмами не стоит ради одного проекта.