- В этой теме 12 ответов, 4 участника, последнее обновление 3 года, 6 месяцев назад сделано
.
-
Сообщения
-
Как только останавливаю коммуникатор то начинает работать! Настраивал не я, так передали. Куда копать?
Программа OPCNet.exe версии 1.10.78.0 прекратила взаимодействие с Windows и была закрыта. Чтобы узнать, имеются ли дополнительные сведения о проблеме, просмотрите журнал проблем в разделе «Безопасность и обслуживание» в панели управления.
Идентификатор процесса: 1eb0
Время запуска: 01d909690e77ecb2
Время завершения: 4294967295
Путь к приложению: C:\Program Files\OWEN\Owen OPC Server\OPCNet.exe
Идентификатор отчета: 23412205-7462-46e0-aa10-9650659a1c6a
Полное имя пакета сбоя:
Код приложения, связанного со сбойным пакетом:
Тип зависания: Top level window is idleПриложение: OPCNet.exe
Версия платформы: v4.0.30319
Описание. Процесс был завершен из-за необработанного исключения.
Сведения об исключении: System.Runtime.Remoting.RemotingException
в System.Runtime.Remoting.Channels.Ipc.IpcServerChan nel.StartListening(System.Object)
в System.Runtime.Remoting.Channels.Ipc.IpcServerChan nel.SetupChannel()
в System.Runtime.Remoting.Channels.Ipc.IpcServerChan nel..ctor(System.Collections.IDictionary, System.Runtime.Remoting.Channels.IServerChannelSin kProvider, System.Security.AccessControl.CommonSecurityDescri ptor)
в OPCNet.SingleInstance.SingleInstance`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].CreateRemoteService(System.String)
в OPCNet.SingleInstance.SingleInstance`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].InitializeAsFirstInstance(System.String)
в OPCNet.App.Main()Windows server 2019
Давайте по порядку.
Учтеная запись под которой запущен OWEN OPC и служба коммуникатора одна и таже?
Права пользователям на чтение и запись где лежит проект OWEN OPC предоставлен?Ошибка возникает в OPC-сервере ОВЕН. Имеет смысл обратиться к ним в поддержку для её решения.
Судя по тексту «Тип зависания: Top level window is idle» этот OPC-сервер взаимодействует с рабочим столом Windows, что само по себе является плохой практикой для приложений, которые должны работать 24×7. Коммуникатор работает как служба. Возможно, OPC-сервер не умеет корректно отдавать данные службе.
Рекомендую опрашивать приборы ОВЕН по протоколу Modbus без использования OPC-сервера, который является лишней прослойкой в данном случае.
У них OPC написал как приложение Windows без работы как Sevice.
Они подразумевают, что он будет установлен на 1 ПК и опрашивать modbus устройства. Соотвественно, всегда поднимает OPC тот клиент, кто первый подключился.
Поэтому я уточнил, не запускает ли оператор процесс под учётной записью operator, у которого нет нет прав после сохранения проекта в каталог, а коммуникатор запускается с другого сервера под учётной записью Comm.
Коммуникатор поднял процесс, запустил опрос, а оператор в своей системе не видит данные и перезапускает АРМ. 🙂Овен утверждает, что ОРС должен работать на 2 клиента и больше, но у меня так не получилось, кто первый вставал, того и тапки. Но я это списал на то, что у меня доменный пользователь и даже два разных процесса, запущенных от меня имели разные ID пользователей.
Но тут кажется другая ошибка
Как только останавливаю коммуникатор то начинает работать! Настраивал не я, так передали. Куда копать?
Я бы понимал, если бы при запуске коммуникатора падал OPC, т.к. решили использовать один TCP-порт устройства или RS-232. OPC падает после остановки коммуникатора.
Хм… А может наоборот — падает Owen OPC и останалвивается driver OPC коммуникатора. А путаница потому что время на АРМ спешит вперёд на 5 минут. И по логам АРМ он упал раньше чем коммуникатора залогиповалась его остановка. ?P.S. OPC падают когда количество сессий не вытягивают. Например, шлюз режет сессии подключения потому что они длится больше времени. Драйвер коммуникатора переподключается, т.к. надо связь восстановить. А Owen не очищает мёртвые не активные сессии. После N разрывов уже в сервере 60000 мёртвых сессий.
Уже не падает 2 дня, хз что было) Всем спасибо кто откликнулся! Пока не надо закрывать тему чтоб новые не плодить.
Если система автоматизации ответственная, то желательно всё же убрать из неё OPC-сервер, как ненадёжное звено.
Уже не падает 2 дня, хз что было) Всем спасибо кто откликнулся! Пока не надо закрывать тему чтоб новые не плодить.
Я бы обратил внимание на обновления Windows, которые относятся к .Net Framework.
И нет ли в логах windows проблем подключения к доменному контроллеру.Я разобрался и понял закономерность. В службах стоит автозапуск что овен что скад и начинаются ошибки а если на овен оставить автозапуск а скад автозапуск с отложенной загрузкой то норм все работает.
Вдруг кому понадобиться!На windows 7 такой проблемы нету у меня. На windows server 2019, IIS, последний овен и скад происходит такая проблема. Да, сначала должен OPC запуститься и только потом скал иначе разваливается opc. Не знаю что точно происходит с OPC когда все вместе запускается. Возможно ещё на это как-то влияет iis.
- Для ответа в этой теме необходимо авторизоваться.