Dde-сервер и Vba

Написал письмо, посмотрим что ответят стороны:

info@prolog-plc.ru
Копия: info@3s-software.com, support@owen.ru
Тема: DDE - server

Здравствуйте!

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

При исполльзовании DDE - сервера, при обращении к нему из скрипта на VBA при чтении переменных из сервера стандартная функция бейсика выдает ошибку. Нерегулярно. Выход из ситуации собственными силами найден лишь один - организовать обработчик ошибок в коде VBA. Но такое решение нам нормальным не представляется.

Хотелось бы понять, каким образом можно проверить готовность DDE - сервера в любой момент времени с тому, чтобы функция DDERequest, вызываемая в коде VBA не приводила к шибре выполнения задачи.

Чтобы Вам было понятнее о чем идет речь, поясню, откуда возникла потребность использовать DDE - сервер из комплекта поставки CodeSys:
Представьте, например, что работает ПЛК Овен, а журналирование производится в документ MS Excell.
Нормальная, абсолютно реальная ситуация.


Только в стандартных средствах MS Office никаких средств доступа к OPC-серверу нет.
Зато есть DDE.
В документе MS Excell используются следующие функции:
Chan = DDEInitiate("CODESYS", "")
Topics = DDERequest(Chan, "PLC_PRG.MOTOR_FRQ")

Хотелось бы иметь пример программы на VBA, который корректно работает с DDE сервером, с точки зрения поставщиков и разработчиков CodeSys.
Вопрос достаточно принципиальный, т.к. ПЛК "Овен", в силу доступности и простоты использования нередко включаются в такие проекты, где дорогостоящего SCADA ПО, имеющего всроенные средства доступа через OPC, никогда не будет.

Заранее признательны за ответ.

С уважением, Александр.

Александр. Я давно использую ОРС в VB,VBA. Вам неообходимо подключить к проекту VBA - Library OPCAutomation
C:\WINDOWS\system32\OpcDAAuto.dll
OPC Automation 2.0
Смотрите пример поставляемый с OPC OWEN.

Уаважаемый Nik!
Данный подход мне хорошо известен.
Однако, в связи с тем, что в комплект поставки пакета CodeSys входит именно DDE-server, я все же настаиваю на своем праве выбирать между использованием его и OPC сервера, уже хотя бы потому, что плодить сущности в виде сторонних компонентов от третьих лиц в составе проекта - рыть себе могилу заблаговременно.

Поясню: кошмар начинается уже где-то на этапе восстановления работоспособности АРМ оператора по поводу вышедшего из строя жесткого диска.

Я знаю, что такое "самописные" и сторонние компоненты. Однако, стремлюсь сокращать их количество в проекте настолько, насколько это возможно.

Поэтому на фразу "Вам неообходимо подключить к проекту VBA - Library OPCAutomation", при личном общении в рамках технического совещания, могу невежливо засмеяться, например.

Уважаемый Александр!
В пакет CoDeSys так же входит и OPC server. OPC спецификация общепромышленный стандарт и создан специально для систем автоматизации, а DDE древнее как ... мамонта.
Поскольку, для вас востановление АРМ - кошмар! Впору невежлево засмеятсья мне.

не понимаю, почему предложение Nik вызвало такою реакцию? в поставку CoDeSys кроме DDE-сервера входит и OPC-сервер. OpcDAAuto.dll - компонент от OPC Foundation, который поставляется практически со всеми OPC-серверами.

я так же не понимаю, почему свой обработчик ошибок в скрипте считается неприемлемым?

к сожалению, по сути проблемы я вам помочь не могу.

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

Не с контроллерами а с ПО CoDeSys.

Dynamic data exchange (DDE) — механизм взаимодействия приложений в операционных системах Microsoft Windows и OS/2. Хотя этот механизм до сих пор поддерживается в последних версиях Windows, в основном он заменён на более мощные механизмы — OLE, COM и Microsoft OLE Automation.

Читайте книжки.

Цитата:

---

Сообщение от Nik

Не с контроллерами а с ПО CoDeSys. .

---

В комплект поставки контроллера ПЛК 100 входит ПО CoDeSys, следовательно, ПО вхдящее в CodeSys, поставляется с контроллером.
Я специально уточнял этот вопрос у менеджеров компании "Овен".
Тогда что заставило вас таким образом прокомментировать фразу:

Цитата:

---

И все же я настаиваю на своем праве использовать DDE, как средство, имеющееся в составе ПО, поставляемого с контроллером.

---

?

Цитата:

---

Dynamic data exchange (DDE) — механизм взаимодействия приложений в операционных системах Microsoft Windows и OS/2. Хотя этот механизм до сих пор поддерживается в последних версиях Windows, в основном он заменён на более мощные механизмы — OLE, COM и Microsoft OLE Automation.

---

Скажите пожалуйста, вам не кажется странным тратить свое время на такие "эрзац-лекции", когда уже был задан конкретный вопрос, подразумевающий наличие базовых знаний о том, как организованы итерфейсы обмена данными между приложениями и процессами в операционной системе Windows?

Цитата:

---

Читайте книжки.

---

На каом уровне формирования личности формируется такой стиль общения с собеседниками? Семья, школа, тяготы и лишения воинской службы?

Теперь к делу.
Исходя из опыта написания ПО, работаюего в реальном времени с переферийными устройствами с составе SCADA - систем, мне известно, что для корректной организации опроса переферийного оборудования и передачи данных в прикладное ПО, необходимо предусмотреть как минимум два "потока" событий.
Причем, один из этих потоков действительно является программным потоком в терминологии Microsoft (тредом), запускаемым из серверного приложения и используется для обмена данными с портами ввода-вывода через драйвер операционной системы.
Второй поток событий, потоком в терминологии Microsoft не является и представляет собой последовательные обращения прикладного ПО к серверной компоненте.

Чтобы было более понятно, о чем идет речь: ActiveX компонента, размещенная на экранной форме SCADA - программы TraceMode, занимающаяся обменом данными с нестандартным "железом", подключенным через удаленный сервер портов RS-232 и записывающая в свои "свойства" значения, вычисляемые на основании обмена с подключенным устройством, а так же, получающая из "свойств" значения, передаваемые в устройство.

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

Поскольку два "потока" являются асинхронными, неизбежным действием является введение такого механизма, как "качество данных", с терминологии OPC. А в простейшем случае - время последнего обновления полученных от устройства данных.
Более того, организовать сервер так, чтобы он ждал получение данных от устройства, а только затем отвечал на запросы экранной формы - "повесить" скаду при первом же обрыве связи с устройством.
Для корректной работы сервер должен возвращать клиенту что-либо немедленно. Хотя бы статус ошибки.

Мне не нравится то, что в DDE сервере CodeSys этот статус ошибки организован на уровне вызова функции DDERequest, как "ошибка времени исполнения" программы на стороне скрипта клиента.

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

Способные адекватно ответить на таком уровне есть?
Очень на это надеюсь.

Вопрос явно не к Овен а к 3S Software и их лицу в России ПК Пролог.
Далее можно пропустить... Но сдержаться не смог.... Виноват, извините.

Для себя я ответил давно и обоснованно на личном опыте, что DDE не является надежной технологией передачи данных между приложениями.

OPC - ключ к решению вопроса. Понимаю Ваше решение не переписывать работающий код с DDE, но по моему (не очень точному) мнению в DDE Codesys тега качества нет.

А если Вам смешно работать с OPCAutomation Wrapper давайте вместе посмемся над тем что язык бейсик можно использовать для создания Scada приложений.

А "самописность" компонента определяется не чем нибудь а авторитетом конторы его создавшей - для примера посмотрите кто входит в opcfoundation.org

Писал долго, ответ обрезался. Какие-то фокусы с форумом, видимо.
Уважаемый Олег! VBA - не худший язык сценариев для SCADA-программ, по-моему. Те скриптовые языки, которые предлагают разработчики - часто хуже. Дело тут - в экономии. Не все готовы делиться с Microsoft за VBA в собственных средах разработки.

OPC - знаю, умею. Как и вызывать методы объектов библиотек из программного кода. Не хочется перегружать проекты, если есть такая возможность. Поэтому использование Excel в качестве DDE-клиента и средства регистрации событий все таки представляет для меня определенный интерес.

Если производители коммерческих дорогостоящих SCADA жадничают и пишут крайне неудобные, сырые языки скриптов с минимальными средствами отладки, почему бы мне не действовать так-же?

D_O_K, вы кажется перемудрили с VBA, не силён в CoDeSys, но у вашего нелюбимого омрона подобная задача решается без VBA, просто вставляем в ячейку экселя формулу

=CDMDDE|'D:\Zaprud_6\PECH_6.CDM'!'\Воздух_С9'

CDMDDE-приложение осуществляющее связь с контроллером (бесплатное)
D:\Zaprud_6\PECH_6.CDM-путь к файлу с описанием настроек связи и опрашиваемых точек.
Воздух_С9-имя точки, в файле указывается её адрес и тип данных.

частота обновления и прочая ерунда в файле настроек. можно и по запросу из VBA.

Вы уверены что у Вас ошибка именно DDE, а например не связи с контроллером?

МНОГАБУКАФФ