Приложите также вашу конфигурацию ОРС
Приложите также вашу конфигурацию ОРС
Файл конфигурации
А почему версия такая старая? Попробуйте на текущей:
https://insat.ru/products/?category=1666
Установил в место 4.2.7 новую версию 4.2.27, результат тот же!
Снимите также с ней лог.
Коллеги, приветствую!
Подскажите,пожалуйста, допустима ли адресация узла как указана на прикрепленной картинке? Вложение 41427
Да, можно.
Только версию скачайте текущую - у вас совсем древняя
https://insat.ru/products/?category=1666
Доброго времени суток!
1) Есть ли возможность из SQL обращаться к HDA архиву или напрямую к тегам?
2) В документации приведен пример записи значений из HDA архива в SQL, а есть данные о том какое максимальное количество значений ежесекундно можно писать в базу? на тысячи значений в секунду насколько стабильно будет работать?
ДОбрый день, кто нибудь работал с Json массивами получаемыми с Ip порта ? Программа авион от тензо М. Необходимо через опс получать показания весов.
Добрый день!
Есть задача ускорить опрос OPC сервером контроллера S7 1200 по ModbusTCP.
Есть две конфигурации 89 (readwrite) и 175 (readonly-70% и writeonly-30%) тэгов.
Скорость опроса в первом случае составляет 200-300мс, во втором 450-550мс. Это просто чтение, без учета записи.
При этом настройки S7 1200 одинаковы и его внутренний цикл 10мс.
На другом конце MS 3.9.
Эти цифры практически неизменны и если в первом случае приемлемы, то во-втором случае визуализация очень заметно подтормаживает в части отображения аналоговых величин.
Хотелось бы услышать рекомендации по организации связи, группировки тэгов и т.д. и т.п....
Заранее спасибо!
Пришлите лог обмена с устройством (когда тегов 175). Для этого в свойствах сервера включите запись журнала и всех его событий размер лога задайте равным 10000. Запустите режим исполнения и воспроизведите ошибку. Лог пишется в папку:
c:\ProgramData\InSAT\MasterOPC Universal Modbus Server\SERVERLOGS\
Лог заархивируйте и вышлите нам, также пришлите вашу конфигурацию ОРС сервера.
Как назло под рукой нет ни одного исправного 1200-го...(
Сделаю как приедет.
Только подскажите, куда слать?
Спасибо за оперативный ответ!
support(собка)insat.ru
Можете для начала прислать только конфигурацию - без лога.
Добрый день!
Подскажите, поддерживает ли встроенный в MasterOPC интерпретатор модульную систему? Мне нужно выполнить из тела скрипта http post запрос
Попытался выполнить для начала код
http = require("socket.http")
При переходе в режим исполнения появилось сообщение о невозможности найти модуль socket.http , из чего я сделал вывод, что в принципе require работает. Более того, в перечне констант Lua, доступном из окна редактирования скрипта в MasterOPC, были обнаружены переменные LUA_MODULES и C_MODULES.
После того, как в директорию, на которую указывает LUA_MODULES, были помещены lua-модули библиотеки socket, стал ругаться уже сам модуль socket.http, сообщая, что не находит core.lua. После установки в C_MODULES C-модулей этой библиотеки, ругаться перестал, однако скрипт молча падает, не выводя никаких сообщений в консоль. Вывод о падении был сделан потому, что код:
a = require("socket.http")
server.Message ("working")
Не выводит ничего
Попытка поймать какую-то ошибку кодом вида:
a,b = pcall(require,"socket.http")
server.Message (a)
тоже ничего не дала.
Все приседания совершались в тестовой версии MasterOPC Universal Modbus Server.
Я бы вообще этим не стал заниматься, думая изначально, что модульную систему сервер вообще не поддерживает, однако, читая Help на Multiprotocol SDK MasterOPC Server, увидел там описание модульной системы, из чего сделал вывод, что возможно она и поддерживается.
Помогите прояснить ситуацию. Возможно ли использование модульной системы? Конкретно - нужно выполнить из тела скрипта post запрос.
А причем здесь Multi-Protocol?
В Modbus Universal теоретически можно подключать сторонние LUA библиотеки, однако библиотеки должны поддерживать асинхронный режим, иначе просто повиснет сервер.
Большое спасибо за ответ. Я в этом плохо понимаю. Как я узнаю, поддерживает библиотека асинхронный режим или нет? И почему повиснет сервер? И почему в моем случае он виснет без обращения к функциям библиотеки? Я всего лишь выполнил функцию require. Не могли бы вы пояснить.
К сожалению не могли бы.
Мы с данной библиотекой не работали и как она реализована нам не известно.
Тем более описываемые вами вещи - это не штатный функционал ОРС сервера.
Если вам требуется реализовать указанную вами задачу, то вы можете сделать ее на C++ в Multi-Protocol в плагине User Script. Там у вас будет весь функционал C++ и возможность отладки в Visual Studio
Жаль...но, может подскажите, начинающему.
У меня в проекте несколько десятков TCP/IP узлов. Хочу контролировать Езернет-соединения.
Сделал объекты не уровне Скады на базе ФБ Ping с периодическим опросом.. но это решение мне не очень нравится.
Думаю в сторону скриптов в Скаде или в OPC (поэтому и заинтересовался функцией OnServerError) но пока ничего путного не придумывается.
К слову, как в OPC (или Скаде) получить строку с адресом узла для использования в скрипте...?
Контролировать с какой целью?
И чем ФБ Пинг не устраивает?
С целью оперативного выявления и устранения неисправностей... (электричество отключили или в сети легло что-нибудь ...).
"Громоздко" поучилось у меня: отделенный объект с Пингом на каждый узел + тег с адресом, к тому же периодический опрос (раз 30-60 мин) дает задержку в реакции.
В принципе работает конечно... просто ищу более лаконичное решение.
Все равно лучше оставить опрос в 1000 мс, главное чтобы он был по изменению.
Modbus Universal MasterOPC Server в режиме Modbus RTU Slave, версия 4.2.28, идет отладка проекта.
На сервер приходит запрос на чтение нулевого холдинг регистра. Сервер возращает корректный ответ, в котором значение регистра = 0.
Но при этом в слэйве такого регистра вообще нет, добавленные теги начинаются с адреса 500.
Ожидалось, что сервер в ответе вернет код ошибки 02 (Illegal Data Address).
Это баг или поведение в таких ситуациях определяет какая-то настройка?
Вложение 41792
В сервере не реализован ответ на отсутствие адреса - они в памяти всегда выделены
Рассмотрите как пожелание? Я понимаю, что в рабочем режиме это вряд ли кого-то волнует, но в процессе отладки (а я, например, постоянно использую Insat OPC в качестве виртуального слэйва) - было бы здорово, если бы подобные ситуации обрабатывались (т.е. адреса выделялись бы только для добавленных тегов).
Скорее всего нет.
Подскажите пож-та!
Допустим в OPC есть устройство(тип programm) с 20 тегами(тип programm)! период опроса 1сек, время ответа 100млсек, повторов при ошибке 3, повторное соединение через 60 сек!
Так вот. если хоть один тег, из этих 20 не опросится(помеха или ещё какая беда) - запустится таймаут(повторное соединение через 60 сек) и всё устройство будет молчать 60 сек!
Повторов при ошибке больше ставить тоже смысла нет - а если устройтво(а) не в сети(20тегов*3*100млсек) - вообще завал!
так вот сам вопрос - есть ли возможность использовать команды server.SendAndReceiveDataByMask() или server.SendAndReceiveData()(или возможно есть другие) так, чтоб они не выдавали автоматом ошибку (server.GetCurrentDeviceError( ) равную true) в теге типа PROGRAMM и не запускали интервал ошибки автоматом - а только по моей команде!
Ведь в programm я сам контролирую достоверность приёма!
Так сделать нельзя.
Вы можете задать количество повторов с запасом - 1000.
Сделаю через дополнительные свойства свою настройку количества повторов и проверять. Достигло ее количество - выходите из опроса этого и идете дальше.
Но хотим отметить, что в наших ОРС серверах принято что если хотя бы один тег не был опрошен, то все теги принимают качество BAD. Иначе может получиться непонятная ситуация в скаде.
Но хотим отметить, что в наших ОРС серверах принято что если хотя бы один тег не был опрошен, то все теги принимают качество BAD.
Это правило работает если использовать тип устройства(modbus) - из-за этого непонятного свойства мы и отказались использовать стандартное устройство(MODBUS) в OPC.
Вы можете задать количество повторов с запасом - 1000
если я такое сделаю - после команды server.SendAndReceiveDataByMask() или server.SendAndReceiveData() - сервер будет долбить 1000 раз в устройство пока не получит ответ(и в этот момент я ничем ОПРОС не остановлю - код крутится в функции SendAndReceiveDataByMask) - и когда не получит ответ в тысячный раз - начнёт отсчитывать задержку ошибки!
Беда - ладно - я в принципе решил этот вопрос(создал таблицу в скрипте устройства и оттуда опрашиваю - распихивая по тегам) - просто долго и муторно - но работает!
SCADAMaster, мне конечно понятно кто владеет монополией, того и правила.
НО!!!
"Но хотим отметить, что в наших ОРС серверах принято что если хотя бы один тег не был опрошен, то все теги принимают качество BAD. Иначе может получиться непонятная ситуация в скаде."
Звучит как полное непонимание требований рынка автоматизации. Просто палки вставляете в колеса всем интеграторам одновременно и себе черную метку на карму.
Ну вот к примеру, я (или такой как я), готовлю программу для какого-то объекта. Меня туда пустят в самом конце и то на короткий срок. В итоге вынужден изголяться и обходить данные "дурацкие" выдуманные на ровном месте правила. Ну сделайте это настраиваемым, хочу использую, хочу не использую. С Модбасом еще прокатывает, есть имитаторы. А с другими протоколами?
То, что Вы слышите, это хорошо, но смешиваете понятия, к сожалению плохо.
Вот к примеру, у меня сложная многоуровневая задача. Мир не идеален и Вы это сами знаете по своему опыту.
Что-нибудь отвалилось и что терять все остальное? Остановили работу участка до устранения "недочета"?
Такая идиология?
Но Вы же не студенты близорукие...
OPC - это вообще костыль. В нормальных системах его не должно быть.
SCADA за рубежом строятся по принципу - основа встроенные драйвера, а если что-то пришлое, то пожалуйста, через OPC
Здесь, в данном Вашем мире он нормально, вполне гармонично так встроился.
Вполне удобное средство Universal OPC, сам им пользуюсь активно, если нужно писать драйверы на нестандартном протоколе.
Если обыкновенный Modbus - Овен ОПС. Отлично работает на живом объекте, денег не стоил.
А Ваши обновления. Что это такое? Два исправили, одно то что было хорошо - сломали. Хорошо ли это?
То что Мастерскада перестала отображать значения при потере качества - полный и надеюсь сокрушимый БРЕД.
Вы должны отдать интегратору признак качества по тэгу. Пусть сам решает что с этим делать.
Перечеркнуть ли значение, скрыть ли значений, привести ли его к максимуму.
Так что же у вас за такая сложная многоуровневая задача, при которой:
1. Опрашивается устройство.
2. В процессе опроса опросилась только половина тегов устройства.
3. Это нормально и нужно как то с половиной данных продолжать работу.
Что же это за "идиология" такая?
Хотим подчернуть если "отвалилось" одно устройство, то опросу другого устройства этого никак не мешает.
Потрясающее заявление. Как вы считаете ОРС - это российская разработка? Может центральный офис OPC Foundation - находится в Саратове? Kepware, Matrikon, Unified Automation - российские компании?
И что понимать под "пришлым"?
Насчет драйверов, в том же Trace Mode 1500 заявленных драйверов, однако в очень многих проектах даже для Modbus почему то наш ОРС используются. Странно да?
Если говорить про новый ОВЕН ОРС, то он достаточно грубая копия Modbus Universal, даже названия настроек совпадают.
Ну а копируют, как известно, лучшее.
Правда вот его работоспособность на большом количестве тегов вызывает проблемы.
Про что речь?
Кстати в 3.10 реализована настройка отображения значений признака качества - теперь можно текст замещающий делать, а можно оформление менять.
SCADAMaster,
Если мы можем читать - то должны читать!Цитата:
2. В процессе опроса опросилась только половина тегов устройства.
3. Это нормально и нужно как то с половиной данных продолжать работу.
Что же это за "идиология" такая?
Хотим подчернуть если "отвалилось" одно устройство, то опросу другого устройства этого никак не мешает.
Как бы не работать с полученными данными, а хотя бы их видеть.
Видеть значения тех тэгов, с которых еще идут данные. Никак не логично отказывать в просмотре.
Ну в чем тогда логика? Modbus Pool считать данные может, а Мастерскадой уже нет.
Это зачем так делаете?
То что не Вы придумали OPC - верно, это открытый стандарт. Речь же не о том была. Зачем вообще нужен этот шлюз?
Если цель экономическая - принимаю. Если так лучше для дела, простите - нет.
Вы ответите в контраргумент что так работают все отечественные SCADA, причем часто сами покупают Ваш Universal OPC.
Ну да, все верно. Вы молодцы выпустили работающий продукт. А почему так происходит? Причины?
Хотелось бы подчеркнуть, что нахожусь на Вашей стороне и использую Ваши решения в тех проектах, которые реализую.
Вступая в эти дебаты мной двигает стремление улучшить существующую картину, а не привыкать к не очевидному.
Вы уходите от темы. Во первых Modbus Pool - это тестовая утилита, никакого отношения к опросу в работе реальных процессов не имеет.
Во вторых, мы вам задали простой вопрос - опишите задачу, при которой требуется, чтобы если пропала связь с частью тегов одного устройства остальные теги должны получить достоверный признак качества. Вы готовы описать данную задачу?
И хотим подчеркнуть - количество нормально считанных тегов в одном устройстве может быть разным - может быть только один тег считается, а может и 2/3.
Потому что протоколов много, скад - много. И тянуть такое количество протоколов - очень тяжело. Пример Trace Mode кстати очень показателен, на бумаге 1500 драйверов, а на деле даже для Modbus они сами (!) рекомендуют ОРС использовать.
Ну а новый стандарт OPC UA - это вообще путь в светлое будущее.
Не только отечественные. Откроем страшную тайну - наш ОРС сервер продается в том числе и на мировом рынке.
Под причинами что имеете ввиду? Почему его покупают? Да по той же причине по которой ОВЕН его "обводил" - потому что это лучшее решение на рынке.
Постараюсь не уходить с темы:
1. Мне как интегратору важно иметь возможность удаленно отлаживать систему визуализации, даже если физических устройств нет. Только на программных компонентах.
Используя по возможности даже реальный ключ и реальный дистрибутив, чтоб исключить любые оказии при вводе софта в эксплуатацию реального объекта.
В прежних версиях Мастерскада данные с плохим качеством не скрывала и я имел возможность задать любые удобные мне числа, конечно при наличии связи с ОПС.
Теперь это не так. Приходится выкручиваться, ругаясь громко в слух.
2. Давлеет на мою подкорку опыт работы на крупных, достаточно серьезных объектах атомной энергетики.
Там тоже встречались данные с плохим признаком качества Q. Причем никто их и не задумывался скрывать от наладчиков или КИПовцев, наоборот. Мы их индицировали на экране зачеркнутыми.
С таким подходом как у Вас нас бы выкинули, а в руки бы дали коробочку синего цвета.