Страница 1 из 2 12 ПоследняяПоследняя
Показано с 1 по 10 из 12

Тема: Dde-сервер и Vba

  1. #1

    По умолчанию 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, никогда не будет.

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

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

  2. #2

    По умолчанию

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

  3. #3

    По умолчанию

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

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

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

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

  4. #4

    По умолчанию

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

  5. #5

    По умолчанию

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

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

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

  6. #6

    По умолчанию

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

  7. #7

    По умолчанию

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

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

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

  8. #8

    По умолчанию

    Цитата Сообщение от 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-сервера существует некий "тэг", а вернее параметр с каким-либо именем, к которому можно обратиться из скрипта всегда, не получая "ошибку времени исполнения" и на основании его значения сделать заключение о том, готов ли сервер отдать данные о переменных контроллера скрипту, или занят чем-то.

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

  9. #9

    По умолчанию

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

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

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

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

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

  10. #10

    По умолчанию

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

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

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

Страница 1 из 2 12 ПоследняяПоследняя

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •