|
|
Связь с АСУТП |
Например Модбас! Позвоните специалистам АСУ. Спросите тупо "Какие промышленные протоколы поддерживает ваша SCADA система? (Или какой там потребитель данных)". |
|
|
Главный инженер проектов.
"УралРТСофт" |
|
 |
|
|
Понимате в чем дело.. я не против мод баса, наоборот это все сверх доступно... Но по существу, проектов с интеграцией в асу очень много... и разных производителей... просто боюсь, что в один прекрасный момент производитель асу покаким либо причинам не будет поддерживать мод бас.. Почему и был затронут вопрос... есть ли этот 103 как 100% поддерживаемый асу.. только из этого исхожу... |
|
|
|
|
Понятно. Если хотите 100% поддержки всеми сущействующими в мире АСУ - ваяйте OPC сервер.
Либо на основе UniOPC, либо сами. OPC поддерживается всеми распространенными SCADA системами. |
|
|
Главный инженер проектов.
"УралРТСофт" |
|
|
|
|
Например, счётчики Меркурий-230 передают ток, напряжение, энергию и прочее. Протоколы Modbus, CAN. 101 протокол - это передача значений с привязкой ко времени по modbus, 104 - через Ethernet (задумка энергетиков (Чубайса?)) |
|
|
|
|
Не Modbus у Меркуриев, а нечто свое, отдаленно похожее, и от CAN вроде только физический уровень. Зато к ним есть OPC -сервер, что серьезно упрощает их применение.
|
|
|
|
|
Ни в коем случае не лезте в свой прибор. Это на всех пожелальщиков не напасешься! Если кто- то высказывает пожелания, то скорее всего из делетантских соображений. Отладить систему команд прибора - очень сложная задача и за ней ведь идут программы конфигурирования. Так что, самое правильное: OPC сервер на той стороне, который поддерживает протокол прибора. Собственно, все так и делают. Самому писать OPC сервер я бы посоветовал при наличии полугода или более времени - надо в виндах разбираться. А вообще, складывается практика, что под скаду обмен пишут программисты системного интегратора (особенно, есле не винды а QNX). Если они говорят что это не так- значит они не интеграторы, а так.
|
|
|
При экспериментах ни один чайник не пострадал
----------- Плохому системному интегратору всегда OPC сервер мешает. ______________ Пишу на C++ за еду |
|
|
|
|
Полностью согласен с теми коллегами, что советуют релизовывать в качестве максимально универсального решения ОРС-сервер. Сомневаюсь, что разумно ждать его написания от системных интеграторов. В конце концов спрос на Ваш прибор - Ваш шкурный интерес и безусловно этот спрос будет существенно выше при возможности безболезненного опроса прибора любой SCADA. И опять же - даже если системный интегратор ОРС-сервер напишет, то не подарит же он Вам его, денег попросит. Тогда уж целенаправленно нанимать программеров, профессионально этими задачами занимающихся. Немного не по теме: CAN - это и есть физический уровень. А уже на его базе существует ряд программных реализаций. |
|
|
|
|
Согласен, что лучшее решение - профессиональные программисты для написания OPC сервера.
Но OPC, это для виндовых скад, а для QNX ных все равно придеться писать интеграторам обмен. |
|
|
При экспериментах ни один чайник не пострадал
----------- Плохому системному интегратору всегда OPC сервер мешает. ______________ Пишу на C++ за еду |
|
|
|
|
Лет 5 назад, когда мы занимались разработкой своих приборов то старались выбирать протоколы которые поддерживают большинство скада-систем, например – Modbus на базе TCP. Если же так сделать не получалось (на тот момент CANOpen поддерживался не всеми) то ставили PC шлюз (к примеру что-нибудь из продукции JANZ). Который помимо преобразования из одного протокола в другой выполнял еще функции концентратора, аварийного архива и программатора. Да для него нами писался софт, так же разрабатывали свои конфигураторы. Но, сколько я себя помню, проблем передачи данных для скады у нас не было. Я это к тому, что на мой взгляд если есть возможность реализовать “обычный” протокол то его надо реализовывать в приборе а не городить свой OPC сервер.
|
|
|
С уважением!
|
|
|
|
Что значит "обычный"... Самый распространенный? Самый простой? OPC Foundation для того и выпустила стандарт, позволил навести порядок во всей этой чехарде протоколов. |
|
|
Главный инженер проектов.
"УралРТСофт" |
|
|
|
Ответить 
|
Страница <1234 6> |
| Переход на форум | Права доступа на форуме  Вы не можете публиковать новые темы в этом форуме Вы не можете отвечать на сообщения в этом форуме Вы не можете удалять Ваши сообщения на этом форуме Вы не можете редактировать Ваши сообщения на этом форуме Вы не можете создавать голосования на этом форуме Вы не можете выражать своё мнение в голосованиях на этом форуме |
