This is topic ТМ6.05+ОРС+ТРМ138 in forum TRACE MODE 6 бесплатная Базовая версия / TRACE MODE 6 free Base version at Форум TRACE MODE: техническая поддержка.
Уважаемые господа, подскажите, пожалуйста! Я использую TRACE MODE 6.05 +ОРС сервер фирмы ОВЕН V1.0.0.15 при этом на 485 интерфейс нацеплено 30 приборов ТРМ138 и хотя цикл монитора TRACE MODE составляет 0.25с. общий цикл опроса системы (30 приборов) составляет порядка 1мин. 15с. Работая с подобной конфигурацией через Owen Process Meneger v1.1 я получаю цикл полного опроса порядка 11с. У меня подозрение упало на ОРС сервер, так как Owen Process Meneger v1.1 работает с приборами на прямую. Но, я попробовал протестировать ОРС сервак с помощью MatrikonOPCExplorer весии 3.3.2.0 он мне подтвердил параметры Owen Process Meneger v1.1. Вот и вопрос - может ТМ6.05 плохо дружит с ОРС серваком? Настройки ОРС сервака брал у производителя. Заранее благодарен за ответ и Ваши предположения, Александр.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Какой режим опроса OPC-сервера Вы выбираете? Надо - режим ADVISE.
Posted by M@V (Участник № / Member № 1800) on :
Действительно был режим SYNC/CACHE. Но изменения ни на OPC-серверах ни на ОРС-тегах никаких результатов не принесли. Разнес периоды каналов на F1,F2,F3,F4 немного помогло получил 45-50с. Что подскажете? Да, уточняю у меня в проекте одна группа ОРС в ней ОРС-серверов столько-же сколько приборов (30) в каждом ОРС-сервере по 16-ть ОРС-тегов. С уважением, Александр.
Posted by M@V (Участник № / Member № 1800) on :
День добрый, господа. Просмотрев лог-файл ОРС сервера увидел: 1. Опрос одного тега из ТМ6.05 происходит за 20мс, я опрашиваю 512 тегов итого реальное время опроса всех тегов составит 10.24с. 2. Но у меня есть в сети отключенные приборы ТРМ138. 3. ТМ6.05 обращаясь к тегу отключенного прибора через ОРС сервер включает тайм-аут порядка 180мс. И вот тут вся потеря времени цикла опроса!
Теперь вопрос - есть ли возможность в ТМ6.05 задавать уставку таймаута для опроса ОРС сервера(его тега)??? Сейчас этот момент обойду автоматическим отключением каналов неработающих приборов. Жду Вашего ответа с нетерпением, Александр.
Posted by M@V (Участник № / Member № 1800) on :
Далее... Попытался отключить опрос нерабочих тегов ОРС-сервера манипулируя флагами "Выключить" и "Отключить от источника" и в тегах и в каналах и в группах но не получается. Кстати, правильно ли я понимаю что флагами можно управлять и програмно устанавливая аттрибуты каналов 3,С и 8,W но что туда писать?? Теги вообще таких атрибутов не имеют. Я в большой задумчивости, помогите пожалуйста!!!
Posted by Гусев Александр Петрович (Участник № / Member № 2148) on :
Если писать в атрибут 3 (C, Выключить) или в 8 (W, отключить от источника) единицу, то канал будет соответственно отключен (его пересчет остановлен) либо отсоединен от источника (данные для канала перестанут передаваться от/к источников/приемников). Присвоить единицу можно любым удобным способом: через привязку к атрибуту, через канал CALL/Move или через ф-ю setAttributeI()
Posted by M@V (Участник № / Member № 1800) on :
День добрый, господа. Разобрался я вот в чем: 1. Управлять програмно Флагом "Отключить от источника" не составляет проблем, но это не деактивирует ОРС-тег ТМ6.05 и он продолжает обращаться к ОРС-серверу ОВЕНА. Правильно это или нет - филосфский вопрос, казалось бы зачем кого-то беспокоить если тебя о нем не спрашивают, но а вдруг спросят? Хотя время на перевыборку не должно быть большим. Когда же сохранишь для МРВ убрав привязку канала к тегу, то он просто не компилируется и ОРС-сервер ОВЕНА не беспокоит. 2. Между тегом ТМ6.05 и ОРС-сервером ОВЕНА явно прослеживается связь CALL-BACK, и выдерживает тайм-аут(180мс) явно ТМ6.05 притом процесс синхронен.
Теперь вопросы: 1. Как мне управлять этим процессом? Програмно исключить неработающие приборы не могу, к тайм-ауту доступа нет. 2. Возможно попробовать режим опроса OPC-сервера установить ASYNK/DEVICE?
Связывался со спецами ОВЕНА, они ответили следующее: "по идее, сервер работает исходя из того, что опрос ведется по подписке... в соответствии с заданным вами периодом опроса, он опрашивает теги и складывает значения в некие ячейки, при запросе от скады, он просто выдает это значение из ячейки... сложно еще что-нибудь посоветовать, похоже что у ТМ такой способ общения с OPC." Ответьте, пожалуйста по этому топику, с уважением Александр.
Posted by M@V (Участник № / Member № 1800) on :
Спасибо Александр Петрович, я до этого дошел, но уточните по поводу функции setAttributeI(). С уважением, Александр.
Posted by Гусев Александр Петрович (Участник № / Member № 2148) on :
в программе написаной на языке ST можно устанавливать значения атрибутов при помощи ф-й setAttributeI (для целых значений) и setAttributeF (для вещественных значений). в качестве аргументов ф-ии принимают ID канала, ID атрибута и значение атрибута. подробности можно узнать в справочной системе в разделе Программирование/ST/Спец. ф-ии. ID канала получают привязывая атрибут ID. ID атрибута соответствует его номер. ф-ии полезны если требуется поменять несколько атрибутов или атрибуты которые будете менять еще не известны и корректируются по мере выполнения проекта. в других случаях более естественна прямая привязка нужных вам атрибутов.
Posted by M@V (Участник № / Member № 1800) on :
Спасибо. Я все более склонен к FBD-программам, поэтому момент упущен.
Posted by Гусев Александр Петрович (Участник № / Member № 2148) on :
я тоже был склонен с FBD до тех пор пока не встала необходимость разобраться и изменить одну объемную программу вдобавок лежащую в основе уже работающего проекта. и вот когда после суток разбирательств этот монстр был превращен в несколько строчек ST о FBD я забыл навсегда.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
M@V
Если бы Вы использовали синхронные запросы и они именно так выполнялись бы OPC-сервером, это удлинило бы полное время цикла в самом МРВ Trace Mode, чего Вы не наблюдаете. Как Вам сообщили разработчики OPC-сервера, он опрашивает приборы в своем темпе, независимо от запросов со стороны Trace Mode, и сохраняет полученную информацию в кэше. Таймаут в таком случае может задаваться только самим OPC-сервером. Поэтому скорость обновления данных в самом OPC-сервере не зависит от от частоты запросов со стороны Trace Mode. Выключение каналов Trace Моде также не сможет повлиять на скорость обновления информации в OPC-сервере, поскольку OPC-сервер об этом ничего не узнает и будет продолжать опрашивать отключенные приборы в заданном ритме. Возможно, в регламенте обмена с приборами самого OPC-сервера можно найти какие-нибудь настройки, влияющие на ситуацию? Сколько файлов конфигурации OPC-обмена (типа OPC_VIPA_0_opc0.cnf) в папке узла в Вашем проекте?
Posted by Гусев Александр Петрович (Участник № / Member № 2148) on :
OPC-сервер при запуске создает теги в соответствии со списком предоставляемым TM. если в этом списке есть неопрашиваемые приборы будут таймауты. можно в принципе попробовать добавлять/удалять теги из сервера при работе, хотя я так не разу не пробовал.
Posted by Гусев Александр Петрович (Участник № / Member № 2148) on :
посмотрел. с OPC-каналами TM помоему никак нельзя. однако можно ввести в ваш проект возможности динамического создания и удаления тегов. только для этого придется отказаться от OPC-каналов TM и работать с тегами самому при помощи DLL. компонент для работы с OPC - http://users.kubtelecom.ru/~alphacity/tree/prjs-opc.htm Posted by M@V (Участник № / Member № 1800) on :
Совершенно верно ОРС-сервер опрашивает именно те приборы, теги которых прописаны в ТМ6.05 и ничего более.
Posted by M@V (Участник № / Member № 1800) on :
В папке узла моего проекта один файл типа AFD_pcc_0_opc0 без расширения весом 15КБ и примерным содержанием: %%OPC_SERVER_CONFIG PROGID:OWEN.RS485 CLSID:{59C7DBE0-87CB-11D7-90D8-0080481B054E} %CHANID:13 ID:Com1/TRM138(8bit adr=0)/LogicalDevice1/C.SP %CHANID:14 ID:Com1/TRM138(8bit adr=0)/LogicalDevice2/C.SP %CHANID:15 ID:Com1/TRM138(8bit adr=0)/LogicalDevice3/C.SP %CHANID:16 ID:Com1/TRM138(8bit adr=0)/LogicalDevice4/C.SP .....
Posted by M@V (Участник № / Member № 1800) on :
Уважаемые господа, я не удовлетворен состоянием этого топика. AdAstra: Выключение каналов Trace Моде также не сможет повлиять на скорость обновления информации в OPC-сервере, поскольку OPC-сервер об этом ничего не узнает и будет продолжать опрашивать отключенные приборы в заданном ритме.
Повторяю: ОРС-сервер опрашивает именно те приборы, теги которых прописаны в ТМ6.05 и имеют привязку к каналу и ничего более, независимо от состояния канала в ТМ6.05. ОРС сервер не опрашивает приборы, данные от которых никто не запрашивает, хотя они реально подключены!
Смоделировал ситуацию в других SCADA и увидел, что в тегах этих SCADA имеется програмно-управляемое свойство - опрашивать ОРС сервер или нет(галочка) с помощью которой можно управлять ситуацией и избежать тайм-аутов (как следствие повысить прозводительность системы). Неплохо если такая возможность появится в следующем релизе ТМ. С уважением, M@V.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Цитирую Ваше сообщение из этого же топика: "Связывался со спецами ОВЕНА, они ответили следующее: "по идее, сервер работает исходя из того, что опрос ведется по подписке... в соответствии с заданным вами периодом опроса, он опрашивает теги и складывает значения в некие ячейки, при запросе от скады, он просто выдает это значение из ячейки... сложно еще что-нибудь посоветовать, похоже что у ТМ такой способ общения с OPC." Т.о., у этого OPC-сервера априори считается, что OPC-клиент использует режим подписки (ADVISE). В этом случае для изменения списка "подписки" надо было бы производить переинициализацию коннекта с сервером для отключения каких-то каналов. В МРВ такая функция не предусмотрена. В режиме SYNC/DEVICE МРВ обращается к OPC-серверу только по тем каналам, которые включены. Если бы OPC-сервер организовывал обмен с приборами именно по типу обмена с клиентами, то в этом случае он не должен был бы опрашивать "плохие" приборы, если Вы выключите соответствующие каналы. Но он этого не делает. Можно предложить попробовать обходной вариант с принудительной реинициализацией коннекта с OPC-сервером с помощью переменной @e_OPC. При этом файл конфигурирования обмена AFD_pcc_0_opc0.cnf надо редактировать принудительно, исключив из обмена "плохие каналы". Реальной проверки такого варианта не было.
Posted by M@V (Участник № / Member № 1800) on :
Попробовал реинициализировать коннект с помощью @e_OPC. В результате OPC-сервер захватил все ресурсы системы и отпускать не собирается. Файл конфигурирования обмена AFD_pcc_0_opc0.cnf я пока не трогал. Что подскажете, с уважением M@V.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Реинициализация коннекта - стандартная функция для OPC-интерфейса. Захват ресурсов системы OPC-сервером ОВЕНа уже наблюдался ранее. По-моему, они меняли версию OPC-сервера. М.б., обратиться к ним?
Posted by M@V (Участник № / Member № 1800) on :
Спасибо, обращусь и о результатах сообщу. С уважением M@V.
Posted by M@V (Участник № / Member № 1800) on :
Как и обещал, сообщаю результат. Специалисты ОВЕНА выслали мне ОРС сервер версии 1.0.0.28 реинициализация которого проходит успешно но ожидаемых результатов я не получаю. Поэтапно: 1. запускаю проект. 2. редактирую файл AFD_pcc_0_opc0 (убираю описание нерабочих каналов. 3. реинициализирую ОРС сервер. 4. опрос убраных каналов всеравно продолжается. Только при перезапуске проекта, опрос убраных каналов прекращается. Стало быть при реинициализации сервера файл AFD_pcc_0_opc0 не перечитывается, или я чего-то не понимаю? Господа, что посоветуете на сей раз? С уважением M@V.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Мы перепроверили реинициализацию обмена с OPC-сервером KEPware. Если, как указано в нашей документации, провести полную реинициализацию (подать в канал @e_OPC число, большее 255), то файл конфигурации обмена подчитывается и отсутствующие в нем каналы узла не принимают информацию от сервера. Клиент Trace Mode заново подключается к OPC-серверу с описанием тех связей, которые имеются в файле конфигурации. OPC-сервер должен соответственно перестраивать свой регламент опроса контроллеров.
Posted by M@V (Участник № / Member № 1800) on :
День добрый, уважаемые! Реинициализация проходит так как Вы пишете. Просто я в канал @e_OPC подавал 1 а не число более 255. Действительно плохие каналы исключаются из опроса! Спасибо. Но, как реализовать это програмно и тем более из среды ТМ, тут я в замешательстве, али писать DLL? Или зацепится за posted 26-06-2007 10:40 этого топика, а не хочется! С уважением M@V.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Из среды RTM откорректировать файл OPC-конфигурации нельзя. Писать что-то внешнее придется, например, внешнюю DLL, вызываемую программой из RTM. Эта DLL должна будет находить по переданному ей списку индексов "плохих" каналов соответствующие строки в файле конфигурации и "гасить" их. Список индексов "плохих" каналов должен формироваться в RTM на основании диагностики качества обмена. Однако, нам кажется, что если OPC-сервер выбирает собственный регламент опроса полевой шины, то он должен сам определять отсутствующие приборы и исключать их из обмена. Можно после этого проверять их присутствие периодически с некоторым таймаутом. Возможно, эти проблемы будут исключены, если Вы будете использовать драйвер для Trace Mode 6, написанный ОВЕНОМ? Он поставляется в составе Trace Mode 6.
Posted by M@V (Участник № / Member № 1800) on :
Уважаемые, пытаюсь связаться с ТРМ138 (через драйвер типа Т11 как я понимаю интегрированый - Owen485 18) PLC_4 - OwenRS485_Group_1 - TEG, пользуясь Вашей справочной информацией - бесполезно. Читаю в директории Drivers_with_Setup\Owen документ readme_rus.doc - советы совершенно другие (уже пользовательский драйвер типа Т12) и тот-же нулевой результат да и еще ехидное сообщение "Неправильно задан СОМ порт". Как делать правильно или забросить этих БАРАНОВ подальше!!??? Паралельно высылаю пробный проект и файлы конфигурации для двух случаев. С уважением M@V.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Более точно и актуальнее интерфейс поддерживается пользовательским драйвером ОВЕНа. Последнюю версию драйвера Вы можете скачать на сайте фирмы ОВЕН по ссылке: http://www.owen.ru/device/65105602. Со всеми вопросами по правильности конфигурирования COM-порта следует обращаться к разработчикам ОВЕНа, в часности к Мощицкому Павлу Марковичу - pavel@owen.ru.
Posted by M@V (Участник № / Member № 1800) on :
Уважаемые, спасибо за консультации и подсказки!!! От ОРС сервера я отказался, все прекрасно получилось с драйвером t12s7.dll. Теперь с помощью атрибутов канала 3 и 8 я спокойно управляю опросом тегов, УРА!! Мжет прийдет время и ОРС сервер будет вести себя аналогично?! Еще сообщу Мощицкому. С уважением, M@V.
Posted by Yurganov Vladimir (Участник № / Member № 2734) on :
M@v, здря сейчас занимаюсь разработкой проекта на оборудовании ОВЕН, возникли проблемы с работой ОРС. Можешь выслать описание работы с помощью драйвера?
Posted by M@V (Участник № / Member № 1800) on :
Vladimir, куда отсылать?
Posted by Yurganov Vladimir (Участник № / Member № 2734) on :
bobark@yandex.ru
Posted by Yurganov Vladimir (Участник № / Member № 2734) on :
