Это, в принципе, не особо относится к функционалу SCADA систем. Поставьте OPC сервера, в них реализуете все протоколы опросов устройств, которые нужны. В скаду отдаете унифицированными OPC DA, UA. Для этих целей это все как раз и было придумано.Сообщение от ASo
ASo Это просто людям нужно понимать энергопотребление своего "предприятия".
KrAssor - а кто вам сказал, что у меня Modbus RTU ????
НЕ НАДО предлагать OPC там где они нафик не нужны... пожалуйста
Вот пример, у MasterScada4D есть драйвер для Меркурий 230, а для однофазников НЕТ.
Ну и так далее в том же духе... я как раз выяснял возможность написания драйверов под нее для недостающего, но и тут не все "сахар"...
Последний раз редактировалось melky; 06.09.2019 в 14:43.
А причем тут именно Modbus RTU? Я про него не сказал ни слова. OPC сервера есть разные. Multi-Protocol MasterOPC Server - вот для примера, если необходимо реализовать обмен по своему протоколу. В этом вообще вся суть, ради которой создали технологию OPC - предоставить разработчику фиксированный интерфейс для работы с устройствами, которые имеют различные протоколы и стандарты обмена.
SCADAMaster вопрос, почему для ВСЕХ приборов не сделать работу с COM портом поверх TCP ?
Независимо на какой прибор я буду писать драйвер ? То есть в API или как у вас там устроено предусмотреть возможность работы линии связи COM, COM over TCP (UDP)
Что значит новые модели Меркуриев ? речь о банальном 230-м, сидящем за преобразователем интерфейса Ethernet - RS485.
Как выше написал, не уверен что система переварит 300 овер дофига виртуальных COM портов... насколько помню на это было ограничение в ОС.
KrAssor - OPC DA и т.д. кроме UA работают только в Windows среде, меня это не устраивает.
И опять же, если есть возможность писать драйвера в самой среде, зачем прибегать к OPC даже универсальным ?
Момент номер 2, за Универсальный OPC от Инсат, написав для него драйвер для устройства я еще должен платить ? вот с пуркуа бы ?
Последний раз редактировалось melky; 06.09.2019 в 16:04.
Это реализация делается на уровне каждого конкретного драйвера. В целом это правильно, потому что прибор может вообще работать только по UDP, и ни COM, ни TCP использовать уже нельзя.
В ОРС сервере кстати примерно также - на этапе разработки указывается какие интерфейсы может использовать тот или иной драйвер. Правда с MPS сделать реализацию различных интерфейсов значительно проще.
Имеющийся драйвер Меркурия - перенесенный из MS3, достаточно старый. Сейчас мы его переделываем, и само собой нужны новые модели счетчиков которые появились у Инкотекс - 234, 236.
Если хотите - то через неделю можем попробовать предоставить предварительную версию нового драйвера для Меркурия, где будет TCP.
Не за него, а за плагин User Protocol, но цена на него смешная.
И вообще логично, что раз вы используете инструментарий который реализуют большую часть функций, и от вас по сути требуется только послать что-то в порт, а потом обработать, то за этот инструментарий нужно платить.
Последний раз редактировалось SCADAMaster; 06.09.2019 в 16:18.
Спасибо.
Так протокол 234, 236 тот же самый, есть конечно отличия, но это не отменяет их предназначение по работе с портом или с портом поверх TCP в зависимости от условий подключения.
Получается сейчас у вас по два драйвера на один прибор ? глупо. Прибор, который работает по COM может быть подключен так же и через преобразователь интерфейса, последовательность посылок данных при работе со стороны драйвера не меняется. По крайней мере я в своих драйверах пакеты никак не меняю, просто указываю системе, что линия у меня TCP клиент, с таким то IP и таким то портом.
Цена у него не смешная, так как зависит не от наличия единицы плагина а за количество тегов - 300 счетчиков да на 25 - 7,5 тысяч тегов.
Или вы изменили с тех пор политику ценовую для данного решения ? Ну и само по себе, я пишу драйвер и я же еще кому-то должен платить за это ? весело...
пока не требуется, я еще не знаю, выберут ли MasterScada или нет. Но поверхностно, что я увидел, мне лично не понравилось. Ожидал большей скорости в ее работе, а ощущение, что вернулся на характеристики железа лет на 15 назад....
Последний раз редактировалось melky; 06.09.2019 в 16:57.
Отличия есть, в чтении архивов.
Пока что один.
Когда выпустим новый, старый уберем (скроем)
Обмен по TCP и COM имеет существенные отличия. Не ясно какие драйверы имеются ввиду, но очевидно эти отличия реализуются на уровне самого драйвера.
Верно, только градация по тегам идет 500, 2500 и безлимитная. При этом безлимитная стоит 5000 рублей.
Учитывая вы получаете DA, HDA и UA сервер это очень низкая цена
Политика не менялась.
Пишите то вы драйвер себе, вот только на нашем готовом инструментарии, который упрощает вашу работу до банальных посылок в порт и последующей обработки. Да еще наверняка и в техподдержку будете обращаться, в процессе разработки. ПО (в том числе инструменты разработки) такой же товар как контроллеры, приборы, компьютеры и прочие инструменты которые облегают работу разработчика. Странно что это приходится объяснять.
А написать с нуля OPC DA, а тем более HDA или UA сервер - очень непростая задача.
Последний раз редактировалось SCADAMaster; 06.09.2019 в 17:24.
Спасибо.
драйвера устройств под другую систему, где разработчики позаботились о том, чтобы конечному пользователю не пришлось заморачиваться как именно работает линия связи - Com или Com поверх TCP. Думал в MasterScada аналогично, но как оказалось ошибался. Пока еще не изучал API, что вообще в ней можно а что нет.
з.ы. конечно буду мучать техподдержку, когда доберусь
На счет цены принято, действительно не сильно дорого, думал дороже.. Еще нет пока желания использовать Универсальный OPC из-за языка, там только LUA и C++. А на счет 4D обещали C# еще пару лет назад, только если правильно понял, воз и ныне там... Опять же пока только C++ при использовании API в 4D
Кстати вопрос по архивам, куда в MasterScada4D они попадают ? так же в теги основной БД ?
Просто не первый раз сталкиваюсь с красивыми рекламными лозунгами разных систем, но вот технической документации по архитектуре практически нет ни у кого. Имеет ввиду как именно все устроено и как взаимодействует.
Для понимания, в качестве примера смотреть функциональную схему. Вот что-то вроде такой функциональной схемы хотелось бы видеть и для ПО. Очень редкие продукты могут этим похвастаться. А такие схемы как правило снимают часть лишних вопросов.
https://owen.ru/product/plk63
Последний раз редактировалось melky; 06.09.2019 в 21:08.
В Multi-Protocol так и сделано - есть функция sendandrecive, в которую нужно передать данные, а потом обработать полученные. Какой тип связи роли не играет - она сама со всем разбирается.
В MS4D действительно отдельные функции, но обернуть все в одну функцию, которая сама уже определять по какому интерфейсу идет обмен - дело 15 строк кода.
Спасибо.
Ага, чувствуется подход программиста и с вашей стороны ��
Почему вы вдруг решили, что остальные пользователи вашей системы тоже
программисты? Вот и обернули бы в 15 строк кода для остальных.
Я вот "шашки" в руки взял всего пару-тройку лет назад. В смысле вообще занялся программированием.
Из-за этого нет желания прыгать с одного языка на другой.
А C# в 4D вы обещаете к концу года уже не первый год.
Ваши права
Ответить с цитированием