Современные технологии автоматизации» («СТА») —  журнал для квалифицированных специалистов по промышленной автоматизации Форум СТА — современные технологии автоматизации Домашняя страница
Домашняя страница форума CTA Домашняя страница форума CTA > II. АСУТП и SCADA > Промышленные сети и коммуникации
  Активные темы Активные темы
  FAQ FAQ  Искать в форуме   Зарегистрироваться Зарегистрироваться  Вход в систему Вход в систему

Как лучше организовать алгоритм объединяющий несколько протоколов

 Ответить Ответить
Автор
Сообщение
1111 Смотреть выпадающим
Участник
Участник


Присоединился: 24 Апрель 2007
Online Status: Offline
Публикации: 41
Свойства публикации Свойства публикации   Ответить, цитируя автора - 1111 Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Тема сообщения: Как лучше организовать алгоритм объединяющий несколько протоколов
    Опубликовано: 01 Февраль 2008 18:19
Например есть некий алгоритм который на верхнем уровне объединяет и получает данные от устройств работающих по нескольким протоколам (профибас, модбас, специализированные протоколы (от различных термо и прочих датчиков)) и собственный протокол. Понятно что все обмены придется выносить в отдельные потоки, вводить кучу таймеров и тп, но что еще можно придумать?
Наверх
Vald Смотреть выпадающим
Действительный член
Действительный член
Аватар

Присоединился: 02 Октябрь 2007
Категория: Russian Federation
Online Status: Offline
Публикации: 427
Свойства публикации Свойства публикации   Ответить, цитируя автора - Vald Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 02 Февраль 2008 01:45

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

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

При экспериментах ни один чайник не пострадал

-----------
Плохому системному интегратору всегда OPC сервер мешает.
______________
Пишу на C++ за еду
Наверх
Pike Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 24 Апрель 2006
Категория: Russian Federation
Online Status: Offline
Публикации: 135
Свойства публикации Свойства публикации   Ответить, цитируя автора - Pike Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 04 Февраль 2008 09:23
Берться модульный ПЛК обвешивается модулями профибас, ethernet, коммуникационными модулями под протоколы на базе RS-ов и вяжется с верхним уровнем. И время сэкономите, и нервы.
Наверх
uzga Смотреть выпадающим
Действительный член
Действительный член
Аватар

Присоединился: 07 Октябрь 2004
Категория: Russian Federation
Online Status: Offline
Публикации: 359
Свойства публикации Свойства публикации   Ответить, цитируя автора - uzga Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 04 Февраль 2008 10:06
А не факт, что он сможет переварить даже часть этих протоколов одновременно.
Наверх
Pike Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 24 Апрель 2006
Категория: Russian Federation
Online Status: Offline
Публикации: 135
Свойства публикации Свойства публикации   Ответить, цитируя автора - Pike Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 04 Февраль 2008 12:39

Что значит одновременно в вашем понимании?

В общем-то, в классических ПЛК каждый сетевой модуль имеет свой процессор на переваривание протоколов и обменом обработанных данных с центральным процессором. На практике, были проекты с десятком сетевых модулей и все работало как часы.

Наверх
Kanzi Смотреть выпадающим
Действительный член
Действительный член
Аватар

Присоединился: 27 Сентябрь 2006
Online Status: Offline
Публикации: 125
Свойства публикации Свойства публикации   Ответить, цитируя автора - Kanzi Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 04 Февраль 2008 13:32

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

Наверх
Vald Смотреть выпадающим
Действительный член
Действительный член
Аватар

Присоединился: 02 Октябрь 2007
Категория: Russian Federation
Online Status: Offline
Публикации: 427
Свойства публикации Свойства публикации   Ответить, цитируя автора - Vald Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 04 Февраль 2008 14:33
Первоначально опубликовано Kanzi

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

Если вы их подружить друг с другом сможете.  А то в поле нашего зрения два подрядчика год воду переливают из одного места в другое и не могут заставить работать один OPC сервер. И все потому что вокруг него закрутили виртуальные машины , удлинители com портов и две операционные системы.

При экспериментах ни один чайник не пострадал

-----------
Плохому системному интегратору всегда OPC сервер мешает.
______________
Пишу на C++ за еду
Наверх
 Ответить Ответить

Переход на форум Права доступа на форуме Смотреть выпадающим

Bulletin Board Software by Web Wiz Forums® version 9.64
Powered by Web Wiz Forums Free Express Edition
Copyright ©2001-2009 Web Wiz