передача данных из VB в SCADA

[werg]

Здравствуйте!
Помогите пожалуйста разобраться
В наличии имеется промышленный компьютер MS DOS, данные с которого передаются на PC c win xp
На компе с виндой программа управления на VB.
Необходимо с этого компа передавать некоторые данные (15-20 аналоговых величин, в формате с плавающей запятой) в Другой компьютер в InTouch
Я новичок и не понимаю как можно это реализовать

[MuadDib]

1. Какой физический интерфейс между промПК и PC?
2. Какой протокол обмена используется?

[abbat81]

Есть ли исходники на программу VB?

[werg]

пром пк работает в связке с компом на котором программа на VB
это своего рода связка
таких связок 10
это с одной стороны

с другой стороны есть компьютер со скадой интач на который нужно получать данные от всех компов с программой на VB
промышленный комп не причем, так как все данные которые нам нужны есть в VB

Исходников на VB нет, но есть связь с разработчиком, которому надо объяснять через переводчика что мы хотим - в этом вся сложность...((

А хотим мы кинуть витую пару и через RS 485 (двухпроводку) по протоколу модбас получать переменные с компов на которых VB
На нашем компе стоит интач и модбас опс сервер лектус, который хочется просто настроить и работать
Как и что нужно сказать программеру чтобы он понял?
и как это вообще будет
я сам слабо понимаю в этих вопросах но быстро учусь
может кто подскажет?

[MuadDib]

Вам нужно попросить разработчика реализовать в VB-приложении функционал Modbus RTU slave, с размещением нужных вам данных в регистрах. Кроме того, понадобится свободный порт RS485 на компе с VB. Если существующий порт уже занят обменом с промПК, задействовать его не получится.

Если у компа с VB есть ethernet, можете попробовать использовать Modbus TCP (понадобится реализация Modbus TCP slave), однако для этого понадобится поддержка со стороны вашего OPC-сервера.

[werg]

MuadDib благодарю!
насколько реально в VB-приложении реализовать функционал Modbus RTU slave, с размещением нужных данных в регистрах ?
это сложнее чем реализовать OPC сервер в VB приложении, и обращаться к нему через OPC LINK из InTouch?
Хочется понять как же будет правильнее
если реализовать Modbus RTU slave, то я так понимаю каждому слэйву нужно будет назначать адрес в VB программе, а если это будет OPC сервер, то достаточно будет прописать путь у серверу в моём клиенте
что же проще ?

[DonArchibaldos]

Если у Вас существуют какие-то сложности в общении с программистом, может лучше у него сначала узнать, какой из способов передачи данных ему будет под силу реализовать и в какой срок? Думаю, перевести фразу "Нужно реализовать на базе вашей программы шлюз в Modbus RTU или OPC. Это реально?" не составит труда.

[MuadDib]

MuadDib благодарю!
насколько реально в VB-приложении реализовать функционал Modbus RTU slave, с размещением нужных данных в регистрах ?
это сложнее чем реализовать OPC сервер в VB приложении, и обращаться к нему через OPC LINK из InTouch?
Хочется понять как же будет правильнее
если реализовать Modbus RTU slave, то я так понимаю каждому слэйву нужно будет назначать адрес в VB программе, а если это будет OPC сервер, то достаточно будет прописать путь у серверу в моём клиенте
что же проще ?

Вопрос сложный.
Во-первых, VB бывают разные. VB6 (наиболее распространённый вариант) - это одно, а VB.NET - совсем другое. Какой VB используется, вы не сообщили.
Во-вторых, что реализовать проще, а что - сложнее, зависит от опыта программиста и от имеющихся в его распоряжении готовых решений, библиотек, компонентов и т.п. Так, VB6 - язык, предназначенный, в основном, для работы с готовыми компонентами (конкретнее, с COM-объектами, поддерживающими IDispatch-интерфейс). Если программист предложил вам вариант с OPC-сервером, значит у него есть какие-то наработки в данном направлении, и такой вариант следует всерьёз рассмотреть.

В случае, если наработок ни для Modbus Slave, ни для OPC-сервера нет, разработка OPC-сервера будет на порядок сложнее. В VB6 дело будет осложняться тем, что язык напрямую не поддерживает custom-интерфейсы, а функционирование OPC основано именно на таких интерфейсах. Реализовать OPC-сервер с использованием VB6 можно лишь применив некие библиотеки-обёртки (то есть, фактически, разработав на другом языке программирования некий специальный компонент OPC-сервера, управляемый через dispatch-обёртку). Лично мне такой готовый инструментарий встречать не приходилось.

Скажу больше, при отсутствии наработок даже Modbus Slave в VB6 будет реализовать непросто - слишком много ограничений у данного языка. Что уж тут говорить об OPC...

С точки зрения эксплуатации, работа с распределённой системой из нескольких OPC-серверов также крайне нежелательна. Намучаетесь потом с настройкой DCOM по самое не балуйся.

Резюмируя вышесказанное, рациональнее всего для вас будет затребовать Modbus Slave (RTU или TCP - по обстоятельствам). Если разработчик сам предложит вам вариант с OPC, имеет смысл такое решение рассмотреть, но с учетом того, как потом это всё вам поддерживать. Повторюсь, распределённая система из OPC-серверов - это что-то с чем-то... Даже сама OPC foundation в новом варианте OPC-стандарта (OPC UA) полностью ушла от использования COM/DCOM, вот только продуктов поддерживающих UA я пока не встречал :?

[san]

Резюмируя вышесказанное, рациональнее всего для вас будет затребовать Modbus Slave (RTU или TCP - по обстоятельствам). Если разработчик сам предложит вам вариант с OPC, имеет смысл такое решение рассмотреть, но с учетом того, как потом это всё вам поддерживать. Повторюсь, распределённая система из OPC-серверов - это что-то с чем-то... Даже сама OPC foundation в новом варианте OPC-стандарта (OPC UA) полностью ушла от использования COM/DCOM, вот только продуктов поддерживающих UA я пока не встречал :?

Не вижу смысла в данном случае в Modbus RTU, лучше уж Modbus TCP или ОРС. Примеров для VB в инете хватает, когда-то сам писал облегченные варианты.
Для Modbus TCP Client на VB6 - https://sites.google.com/site/fieldbusb ... modbus-tcp
Для OPC Client на VB6 - https://sites.google.com/site/fieldbusb ... ologii/opc, (рпример 31.4), правда тут комменты на украинском, если будет интересно, комментарии переведу

[MuadDib]

Для OPC Client на VB6 - https://sites.google.com/site/fieldbusb ... ologii/opc, (рпример 31.4), правда тут комменты на украинском, если будет интересно, комментарии переведу

OPC-клиент на VB в поставленной задаче ничем не поможет. OPC-сервер - совсем другая тема.

[san]

Вы хотитпе сказать, что InTouch не поддерживает интерфейс OPCServer? Сомневаюсь, так как это одна из самых дорогих и мощных СКАД. А ОРС клиента реализовать проще, чем ОРС серевера. То же самое касатеся и Modbus.
Предлагаю топикстартера посмотреть также в стороно уобмена по SQL/ODBC - возможно реализовать это будет ещё проще. Правда надо узнать как это в InTouch. Вобще, надо бы начать с того что InTouch поддерживает и какие дрова для этого надо покупать. С этой скадой не работал, по этому не в курсах.

[werg]

В Скадах как правило реализованы OPC клиенты
интач - не исключение
Данные надо забирать ИЗ VB а не наоборот
А предоставлять данные - это функция сервера
и клиент тут не поможет...
мне кажется MuadDib прав

[san]

Вот кстати отсюда http://old.intouch.ru/support/pub/InTouchUGRus9.5.pdf

Обмен данными
Взаимодействие системы InTouch с другими приложениями Windows, серверами
Wonderware ввода/вывода и внешними серверами ввода/вывода осуществляется по
протоколам обмена данными Microsoft DDE (Dynamic Data Exchange), FastDDE,
NetDDE и Wonderware SuiteLink.

Так что можно даже NetDDE, архаично конечно, но если это прямой путь, то почему бы и нет, реализовывается просто

[werg]

В общем попробую объяснить китайцу, что надо реализовать MODBUS RTU или TCP слэйв в VB
добавить в VB программу окошечко для установки модбас адреса
и предоставить мне таблицу регистров модбас
то есть адрес каждой переменной
В своём OPC Сервере я создаю узелы с соответствующими адресами и опрашиваю переменные по по представленной мне таблице адресов регистров
Так вроде?

[san]

В Скадах как правило реализованы OPC клиенты
интач - не исключение
Данные надо забирать ИЗ VB а не наоборот
А предоставлять данные - это функция сервера
и клиент тут не поможет...
мне кажется MuadDib прав

Это вопрос риторический. Для приложений уровня MES, SCADA - это как раз Сервер, и для этого эти же SCADA поддерживают ОРС Сервер. А в Вашем случае, кто кому передавать данные или кто у кого их будет забирать - это так принципиально? Нужно детально обсудить задачу. И это должны делать ваши программеры и ваши разработчики SCADA. Технологий может быть много: DDE, OPC, SQL/ODBC, ActiveX, Modbus TCP (или другие открытые), свой протокол (VB<->InTouch ActiveX)... и другие возможно тоже есть. Клиентская или серверная сторона будет в одном или другом конце - надо решать индивидуально для каждой технологии. Если проще реализовать клиентскую сторону в VB, и это не перечит всем условиям и не ухудшает надежность - то почему бы и нет!

[san]

В общем попробую объяснить китайцу, что надо реализовать MODBUS RTU или TCP слэйв в VB
добавить в VB программу окошечко для установки модбас адреса
и предоставить мне таблицу регистров модбас
то есть адрес каждой переменной
В своём OPC Сервере я создаю узелы с соответствующими адресами и опрашиваю переменные по по представленной мне таблице адресов регистров
Так вроде?

Если уже идёте по этому пути, то нужно "китайцу" ещё объяснить какой запрос будет приходить при чтении FLOAT (так как у Modbus нет такой функции) и в какой очередности будут идти байты в этом самом FLOAT. Это надо уточнять у знатоков InTouch и их драйверов Modbus.

[MuadDib]

Это вопрос риторический. Для приложений уровня MES, SCADA - это как раз Сервер, и для этого эти же SCADA поддерживают ОРС Сервер. А в Вашем случае, кто кому передавать данные или кто у кого их будет забирать - это так принципиально? Нужно детально обсудить задачу. И это должны делать ваши программеры и ваши разработчики SCADA. Технологий может быть много: DDE, OPC, SQL/ODBC, ActiveX, Modbus TCP (или другие открытые), свой протокол (VB<->InTouch ActiveX)... и другие возможно тоже есть. Клиентская или серверная сторона будет в одном или другом конце - надо решать индивидуально для каждой технологии. Если проще реализовать клиентскую сторону в VB, и это не перечит всем условиям и не ухудшает надежность - то почему бы и нет!

Действительно, клиентам SCADA абсолютно поровну, как SCADA получает данные - как сервер или как клиент. И действительно, теоретически сравнительно просто реализовать на VB OPC-клиент, который может складывать данные в некий специальный OPC-сервер со стороны InTouch. Но у данного решения будут 2 недостатка, существенно усложняющих эксплуатацию:
1. Конфигурация VB-клиента будет зависеть от конфигурации серверного ПО.
2. Для _каждого_ из VB-клиентов потребуются отдельные конфигурации, поскольку каждая машина с VB должна будет складывать свои данные в "свои" и только в "свои" тэги.

Не будем упоминать, что подобная схема усложнит администрирование DCOM и что даже такая тривиальная задача, как контроль состояния связи с удалённой VB-машиной посредством OPC quality, станет при такой схеме взаимодействия узлов невозможной :)

В общем, такая архитектура годится разве что для лабораторного стенда (типа, запускается, и ладно) ну или для типичного случая, когда всё уже куплено, поставлено, запуститься надо "вчера", а тут кто-то вспоминает, что в распределённой системе узлы, заразы такие, должны взаимодействовать! :amazement: Поддерживать на плаву такое хозяйство я бы и врагу не пожелал.

[MuadDib]

В общем попробую объяснить китайцу, что надо реализовать MODBUS RTU или TCP слэйв в VB
добавить в VB программу окошечко для установки модбас адреса
и предоставить мне таблицу регистров модбас
то есть адрес каждой переменной
В своём OPC Сервере я создаю узелы с соответствующими адресами и опрашиваю переменные по по представленной мне таблице адресов регистров
Так вроде?

Да, как-то так. TCP обычно предпочтительнее, но сначала лучше убедиться, что ваш OPC-сервер способен работать через Modbus TCP.

[werg]

Действительно, клиентам SCADA абсолютно поровну, как SCADA получает данные - как сервер или как клиент. И действительно, теоретически сравнительно просто реализовать на VB OPC-клиент, который может складывать данные в некий специальный OPC-сервер со стороны InTouch. Но у данного решения будут 2 недостатка, существенно усложняющих эксплуатацию:
1. Конфигурация VB-клиента будет зависеть от конфигурации серверного ПО.
2. Для _каждого_ из VB-клиентов потребуются отдельные конфигурации, поскольку каждая машина с VB должна будет складывать свои данные в "свои" и только в "свои" тэги.

Согласен! Абсолютно!
Я использую Lectus OPC MODBUS server
и TCP он поддерживает
что касается передачи переменных типа FLOAT, то в серевере предусмотрен прием старшим байтом вперед/назад и слова тоже можно вертеть)
Так что отображение переменных не есть проблема!
Кроме того я могу дать ссылочку на опс лектус китайцу, есть 30 дневная копия
Так что будет даже на чем попробовать связь.

[san]

Действительно, клиентам SCADA абсолютно поровну, как SCADA получает данные - как сервер или как клиент. И действительно, теоретически сравнительно просто реализовать на VB OPC-клиент, который может складывать данные в некий специальный OPC-сервер со стороны InTouch. Но у данного решения будут 2 недостатка, существенно усложняющих эксплуатацию:
1. Конфигурация VB-клиента будет зависеть от конфигурации серверного ПО.

Это как? SCADA - одна.

2. Для _каждого_ из VB-клиентов потребуются отдельные конфигурации, поскольку каждая машина с VB должна будет складывать свои данные в "свои" и только в "свои" тэги.

Однозначно так, но и если SCADA будет Клиент - будет тоже самое, для каждого ОРС Сервера будут свои теги.

Не будем упоминать, что подобная схема усложнит администрирование DCOM и что даже такая тривиальная задача, как контроль состояния связи с удалённой VB-машиной посредством OPC quality, станет при такой схеме взаимодействия узлов невозможной :)

Это я не понял. В случае OPC-сервер на SCADA - OPC Сервер будет один, а если наоборот - их будет 10 (и все самописные), и один клиент в SCADA InTouch. Естественно что система с одним OPC Server-ом с точки зрения DCOM проще настраивается. И кто вобще должен контролировать связь - SCADA или VB. Если SCADA, тогда MuadDib, Вы правы, она должна быть клиентом, а если VB - тогда наоборот.

В общем, такая архитектура годится разве что для лабораторного стенда (типа, запускается, и ладно) ну или для типичного случая, когда всё уже куплено, поставлено, запуститься надо "вчера", а тут кто-то вспоминает, что в распределённой системе узлы, заразы такие, должны взаимодействовать! :amazement: Поддерживать на плаву такое хозяйство я бы и врагу не пожелал.

Вы не смотрите что "я худой и кашляю" :-) . Работаю не только со стендами, но и с реальными объектами. Я бы и врагу не пожелал писать OPC Server на VB, так как это без изврата НЕВОЗМОЖНО. Под извратом я имею ввиду писать dll на C, а потом его включать в код VB, или что-то подобное. А вот клиент написать можно, через OPC Automation интерфейс. Так что это путь заведомо неробочий. Другой вариант - найти (написать на C/C#...) промежуточный ОРС-Сервер, к какому будут обращаться оба клиента VB и InTouch, но это ещё более не надежное.
Так что, Modbus/TCP всё таки наверное наиболее лучший вариант. А кто клиент и Сервер в этом варианте - сами выбирайте, если у InTouch дрова только клиентские - выбора уже нет, на VB надо реализовывать серверную сторону.

[MuadDib]

Очень странно, что на пустом месте возникает такой спор, но если хотите ответы на свои вопросы - пожалуйста.

Это как? SCADA - одна.

Допустим, вы развернули OPC-сервер на стороне СКАДА, и VB-клиенты должны складывать данные в него. Соответственно, вы задаете на каждом клиенте OPC-тэги типа "ServerName.FromClient1.Data1". По какой-то причине пришлось поменять OPC-сервер "наверху" на другую версию, и строка названия сменилась. Или сменилось имя компьютера. Все, меняется конфигурация на 10 VB-клиентах - это при том, что внизу ничего не изменилось. Не говоря уже о том, что все вышеупомянутые пути нужно как-то вгонять в конфигурацию VB-клиента. В случае с исполнителем из Китая согласования могут вылиться в долгие искромётные диалоги в лучших традициях Равшана-Джумшута. "Насяльника, моя твоя АйПиСи тэга савсэм ни видит, да!"...

Однозначно так, но и если SCADA будет Клиент - будет тоже самое, для каждого ОРС Сервера будут свои теги.

Во-первых, клиент ли SCADA, сервер ли, а отдельные тэги на каждый VB-компьютер всё равно будут: данные разные. Во-вторых, если на VB реализовать клиентскую сторону, у вас будет 10 разных конфигураций для компьютеров "нижнего" уровня, а если реализовать серверную, то всего одна конфигурация в 10 экземплярах. Есть разница?

Это я не понял. В случае OPC-сервер на SCADA - OPC Сервер будет один, а если наоборот - их будет 10 (и все самописные), и один клиент в SCADA InTouch. Естественно что система с одним OPC Server-ом с точки зрения DCOM проще настраивается.

Нет, не естественно. Настройка с клиентской стороны ничуть не проще, чем с серверной. И, как показывает практика, основные пляски с бубном бывают именно с OPC-клиентами. Во всяком случае, диагностировать проблему с клиентской стороны часто бывает намного сложнее. Почему так - не знаю. Может особенности нашего софта, может руки у меня кривые :( Но факт имеет место быть.

И кто вобще должен контролировать связь - SCADA или VB. Если SCADA, тогда MuadDib, Вы правы, она должна быть клиентом, а если VB - тогда наоборот.

Раз InTouch собирает данные с VB-машин, контроль связи со стороны SCADA должен быть однозначно.

Вы не смотрите что "я худой и кашляю" :-) . Работаю не только со стендами, но и с реальными объектами. Я бы и врагу не пожелал писать OPC Server на VB, так как это без изврата НЕВОЗМОЖНО. Под извратом я имею ввиду писать dll на C, а потом его включать в код VB, или что-то подобное. А вот клиент написать можно, через OPC Automation интерфейс. Так что это путь заведомо неробочий. Другой вариант - найти (написать на C/C#...) промежуточный ОРС-Сервер, к какому будут обращаться оба клиента VB и InTouch, но это ещё более не надежное.

Тут вот какая ситуация. На самом деле, VB6 прекрасно взаимодействует с native-кодом посредством механизмов Automation. Именно так работает пример в той статье на украинском языке, на которую вы ссылались. Не нужно "писать dll на C", вы просто создаёте на Си++ нужный набор COM-объектов и используете их в VB так, как считаете нужным. И "изврат" это не больший, чем использовать OPC Automation interface. Другое дело, что для OPC-клиента есть готовое Automation-решение (одно из таких решений, собственно, и описывает вышеупомянутая статья, есть и другие варианты клиентских OPC-обёрток), а для OPC-сервера, как я уже писал, готового компонента нет. Но если учесть, какие архитектурные проблемы за собой тянет решение с OPC-клиентом на стороне VB, то ещё не известно, где в итоге больший "изврат" получится.

Так что, Modbus/TCP всё таки наверное наиболее лучший вариант.

Полностью согласен. Спор какой-то беспредметный получается :D

[san]

Ладно, не будем спорить, хотя практически ничем Вы меня не переубедили. Если кто-то пишет что-то на VB, сомневаюсь что он будет писать на C++. А статья, на которуя я сослался, на самом деле вырезка из книги... моей.
Я когда-то писал на VB маленькие программы и интересовался проблемой использования чистых COM-интерфейсов в VB. То что предлагали VB-шники на своих форумах - это встраивание Assemblera в код VB и использование недокументированых функций VB. Если можете привести код для ОРС-Server на VB - очень внимательно его изучу и возможно переосмыслю всю сложившуюся у меня в голове картину.
На самом деле, я так понял топикстартер хочет пойти по пути VB<->OPC Server Lectus > Modbus/TCP<->InTouch, если это так, то это как по мне самый худший из вариантов, в котором китайцу придется всё-таки реализовать ОРС-Клиента. Или чего-то я недопонял?

[MuadDib]

На самом деле, я так понял топикстартер хочет пойти по пути VB<->OPC Server Lectus > Modbus/TCP<->InTouch, если это так, то это как по мне самый худший из вариантов, в котором китайцу придется всё-таки реализовать ОРС-Клиента. Или чего-то я недопонял?

Нет, речь идёт о VB > Modbus TCP Slave Modbus-> Lectus OPC OPC-> InTouch. Просто топикстартер задумался над альтернативным вариантом: VB > локальный OPC Server OPC-> InTouch. Я высказал свои размышления о реализации OPC Server в рамках проекта VB, вы предложили вариант с OPC Client и пошло-поехало ;)

Я когда-то писал на VB маленькие программы и интересовался проблемой использования чистых COM-интерфейсов в VB. То что предлагали VB-шники на своих форумах - это встраивание Assemblera в код VB и использование недокументированых функций VB. Если можете привести код для ОРС-Server на VB - очень внимательно его изучу и возможно переосмыслю всю сложившуюся у меня в голове картину.

Честно говоря, я не совсем понимаю, о чем вы. "Чистые" COM-интерфейсы в VB, встраивание ассемблера в Бейсик :amazement: Если вопрос интересен, предлагаю или создать отдельный топик или перенести беседу в личку, ибо оффтоп страшный. А то, чего доброго, придут модераторы с черенком от лопаты

[san]

А что InTouch не поддерживает Modbus/TCP?
По поводу СОМ, думаю это нужно на форму по VB. Щас пороюсь в ссылках, давно я туда не заглядывал.

[san]

Нашёл, начал отсюда http://bbs.vbstreets.ru/viewtopic.php?f=1&t=8571 и попал сюда http://www.vbstreets.ru/VB/Articles/65974.aspx, дальше если продолжать, то наверное на том форуме.