На видео видно, что я имитирую значения и показываю их на тренде (там же видно и потерю многих значений), после чего вывожу отчёт по этим данным. На двух видео выше вроде постарался подробно показатьЦитата:
Сообщение от SCADAMaster
Вид для печати
На видео видно, что я имитирую значения и показываю их на тренде (там же видно и потерю многих значений), после чего вывожу отчёт по этим данным. На двух видео выше вроде постарался подробно показатьЦитата:
Сообщение от SCADAMaster
Обнаражулись такая ошибка в проекте - у вас некоторые связи перетащены напрямую. Например:
Пользователь.Служебная информация.Имя оператора -> НА.Двухопорный.Сбор данных вкл.Имя_оператора
Из-за этого валится куча ошибок, ну и работать это не будет. Нужно сделать это через вкладку типизация. СДелать строковое значение, его кинуть в события, а уже на вход этого значения подать сигнал через вкладку Типизация.
Поправьте эту и подобную ошибки.
Убедится что вы все убрали, можно посмотрев файл:
\MasterSCADA Projects\sys_log\MasterSCADA_net.log
Если в нем есть сообщения вида:
17-10-12 18:32:02.558. [Error] Пользователь.Служебная информация.Имя оператора -> НА.Двухопорный.Сбор данных вкл.Имя_оператора [ID=147709 Index=0 PT_POUT Direct] [persistId=0 cacheId=8665],
Значит что-то еще осталось.
Насчитал 4 ошибки, все ссылались на Имя оператора и Должность оператора. Переделал, хотя тот факт, что данные внешние связи не отображаются во вкладке "Внешние связи" много удивляет.Цитата:
Сообщение от SCADAMaster
Теперь из ошибок он ругается лишь на ТИ из АСУТП, причем что именно ему не нравится я так и не понял, удалив 2 объекта и сделав их с нуля. Он просто начал ругаться на 2 других телеизмерения из АСУТП.
Все ошибки, что я описывал раннее остались на месте, ничего не изменилось, за 5 запусков приложение вылетело 3 раза. Прилагаю полнейшний отчет об ошибках в виде ссылки
upd. с предыдущих проектов я попробовал изменить место хранения архивов с PostreSQL на файловый архив. Потеря данных пропала, но в отчетах все равно не выводится ничего. Там отображаются лишь значения при запуске проекта, как будто игнорируя дальнейшие изменения. Тренды всю информацию показывают исправно
Создал новый небольшой проект и тестирую досконально, есть одно замечание:
Когда на мнемосхему типизированного объекта добавляются контроллы "Начало отчета", "Конец отчета" и сама кнопка отчета, то в свойствах экземпляров у нее стоит "Все", и данное свойство не изменяется. Т.е. его можно изменить на "По выбору", сохранить документ, закрыть его, но когда открываешь, то свойство снова оказывается "Все".
Могу сделать предположение, что именно из-за этого глючат отчеты - они просто отображают значения других экземпляров, причем какого именно экземпляра в данный момент неизвестно и зависит от текущего цикла опроса.
upd. проверенно на небольшом проекте, кажется моя догадка подтвердилась - при ~50 вызовах отчета 6 раз отчет не совпал с экземпляром, с которого он вызывался (кол-во экземпляров = 3).
Такое происходит как с сохранением в архив, так и с PostgreSQL. Т.е. если увеличить количество экземпляров до моих, то отчет превращается просто в русскую рулетку.
p.s. кстати я не первый кто это заметил, вот сообщение пользователя barton72:
Цитата:
Сообщение от barton72
То, что происходит со средой разработки - это нечто. Если вам удастся запустить мой проект на исполнение хотя бы 5 раз подряд без перезапуска среды или без вылетов и критических ошибок, то я снимаю свои претензии.
При остановке SCADA при типизации действительно не очищаетя память. Мы знаем об этой проблеме и занимаемся ей.
Одной из проблема медленного цикла опроса является ФБ "Счетчик событий". Мы доработали его работу, чтобы он работал эффективнее исправление будет доступно завтра.
В моем проекте данный ФБ не используется, есть ФБ "Активные неквитированные", если он как-то имеет отношение к замедлению.Цитата:
Сообщение от SCADAMaster
Ну это он и есть
Что насчет данного замечания? Это ошибка или так и было задумано?Цитата:
Сообщение от MTven
Мы проверили - у нас свойство изменяется.
По умолчанию стоит режим "Все" - это значит что берется текущий отчет. У вас проблема была в работе ФБ "Управление документом", которую мы уже исправили.
Текущая проблема связана с большим временем цикла. Мы уже сделали оптмизацию, время цикла существенно снизилось. Отчет сейчас начал формироваться корректно.
Возникла небольшая ошибка в ФБ "Счетчик событий" (после исправления он не считает аварии от шкал), после ее исправлений можно будет проверять работу.
Но если хотите - можете скачать текущую Beta уже сейчас.
Я не совсем понимаю, что именно вы подправили, но теперь у меня просто не прогружаются данные. Обычно загрузка занимала 1-2 минуты максимум, но теперь я ждал вплоть до 15 минут и данные так и не прогрузились. Пробую старые проекты, но и их тоже зацепило. Сейчас формирую данные для отчета об ошибках, чтобы можно было понять с чем это связаноЦитата:
Сообщение от SCADAMaster
Что значит "данные не прогрузились"?
Значит, что типизированные данные не достигли типизированного объекта. Такое ощущение как будто и нет никакой типизации и я выбросил на мнемосхему просто пустой шаблон.Цитата:
Сообщение от SCADAMaster
А вы как это проверяете? На вкладке типизация? Или на мнемосхемах?
На мнемосхемах, если до этого при загрузке данных появлялись показания, записи в журнале и т.п., то сейчас все пусто. В логах нашел такое сообщение, быть может причина в этом:Цитата:
Сообщение от SCADAMaster
Возможно приложение действительно пытается куда-то достучаться. Дерево системы не менялось, пробовал запустить проект v.3.01, который прикладывал до этого, но оно так же не прогружается. На предыдущей beta версии все было нормально.Цитата:
17-10-16 17:06:06.917. Start application 3.9.0.60666
17-10-16 17:07:05.923. [Error] Opc.Ua.ServiceResultException: Error establishing a connection.
в Opc.Ua.Bindings.TcpAsyncOperation`1.End(Int32 timeout)
в Opc.Ua.Bindings.TcpClientChannel.EndSendRequest(IA syncResult result)
в Opc.Ua.Bindings.TcpTransportChannel.EndSendRequest (IAsyncResult result)
в Opc.Ua.Bindings.TcpTransportChannel.SendRequest(IS erviceRequest request)
в Opc.Ua.DiscoveryClient.GetEndpoints(RequestHeader requestHeader, String endpointUrl, StringCollection localeIds, StringCollection profileUris, EndpointDescriptionCollection& endpoints)
в Opc.Ua.DiscoveryClient.GetEndpoints(StringCollecti on profileUris)
в OpcUaClient.Client.Connection.OpcUaServerAdapter.G etEndpointDescriptionCollection(ConfiguredEndpoint configuredEndpoint, ApplicationConfiguration appConfiguration, Int32 operationTimeout)
в OpcUaClient.Client.Connection.OpcUaConnection.GetE ndPointDescription(MessageSecurityMode mode, SecutityPolicy secutityPolicy)
в OpcUaClient.Client.Connection.OpcUaConnection.Open ()
в OpcUaClient.Client.RT.OpcUaClientRtProcessor.TryCo nnect()
Последнее сообщение повторялось 1 раз(раза).
17-10-16 17:07:21.988. Stopped Project=TIP_NA_v.4.02.vav
Версию скачивал с вашего ftp-сервера, перед этим удалил старую специальным деинсталятором с очисткой реестра и остаточных файлов, папка MasterSCADA projects в корне диска была удалена.
Пробовал переустанавливать несколько раз, но результат один.
Прикладываю видео-демонстрацию работы с отчетом об ошибках.
Попробовал на вашей сегодняшней beta версии, ничего не поменялось. Есть какие-то догадки в чем может быть причина?
Догадка очень простая - у вас все переменные пропущены через скрипт. И с его выхода нет значения. А вот почему - не срабатывают ли условия, или что-то некорректно обрабатывается в скрипте - пока не ясно.
Вы можете проверить очень просто - в вашем скрипте в конце после всех ваших условий напишите
ЗначВых = ЗначВх;
И попробуйте.
:confused: так в скрипте-то я ничего не менял с момента предыдущей beta версии. Да и вы могли заметить, что я для примера запускал старую версию проекта (которая точно была рабочей).Цитата:
Сообщение от SCADAMaster
Как бы то ни было, сейчас тестирую выполнение в обход условий скрипта и вообще без скрипта.
В обход условий скрипта (все условия были закомментированы) значение выводится. Так же пробовал комментировать каждое условие в отдельности, т.к. думал, что причиной является условие "DisableDev", но закомментировав его, срабатывало условие OPCStatus - отсюда можно сделать вывод, что причина именно в обработке скрипта.
НО проект вел себя так и раньше, но лишь до тех пор, пока не прогружались данные. Для примера снял видео с проектом 2.06, который работает нормально, хотя никаких внутренних изменений, по сравнению с 3.01 он не имеет. Различие только в списке экземпляров - в версии 2.06 я еще не разделил все агрегаты на 3 типа и как следствие все агрегаты находились в одном списке, но я не думаю, что это может послужить причиной. Внутренняя структура обработки данных не изменялась, скрипты те же самые.
На видео видно, что сначала агрегаты так же уходят в статус отключенных, как и в 3.01, но затем проходит загрузка и все данные приходят в нормальное состояние, а журналы отображают новые данные.
Тут пока не совсем ясно - то ли глючит отработка скрипта при типизации, то ли у вас такие входные данные поступают, что он не отрабаывает.
Пока что вылез еще один глюк. У каждой переменной типизированного проекта есть вкладка Типизация, на ней можно увидеть текущие значения в режиме исполнения. В вашем проекте, значения почему то не отображаются. Сейчас мы исправляем эту ошибку, после этого можно будет проанализировать работу скрипта.
Входные данные поступают из объекта "Имитация", из дерева объектов. Никаких внешних источников (OPC, БД) для типизированных объектов не подключено, так что я не думаю, что дело во входных данных.Цитата:
Сообщение от SCADAMaster
Сейчас я у одного из экземпляров убрал внешние связи, и вписал константы OPC Status, Disable Dev,Sensot Status и т.д. Данные на выходе скрипта появились.
Так что похоже что данные.
Починим вкладку - скажем точно.
Вписали константы как "Значение до опроса", во вкладке "Типизация" или просто как константу на вкладке "Опрос"? Кстати переменная DisableDev никак не связана с внешними данными типизации, она привязана напрямую к значению "Сбор данных отключен" в корне НА.Цитата:
Сообщение от SCADAMaster
upd. выставил у себя значения в "Значение до опроса", все сработало нормально, но тогда я не совсем понимаю, почему данные не поступают от объекта "Имитация"? Это ведь обычные константы, специально добавленные для чистоты эксперимента.
Вскрылась еще одна ошибка с масштабом шкалы трендов - в режиме разработки масштаб нормальный и соответствует границам значения, но в режиме выполнения все настройки слетают и приходится по одному их править.
В режиме разработки:
Вложение 33728
В режиме выполнения:
Вложение 33729
Вложение 33730
Вложение 33731
Возможно у вас в режиме исполнения менялись настройки. Попробуйте выключить настройку (см. приложение).
Я уже исправил все вручную, но это сейчас не главная проблема. Что в итоге с главной проблемой - значения на выходе так и не отображаютсяЦитата:
Сообщение от SCADAMaster
Проблема как выянилось именно DisableDev. Команда почему то не передает сигнал на вход, мы изучаем с чем это может быть связано.Цитата:
Сообщение от MTven
Если вместо условия в первое строке поставить true, то значения на выход у нас начинали поступать.
Очень надеюсь, что это не займет много времени?Цитата:
Сообщение от SCADAMaster
Испытания уже дышат в затылок, а у меня вместо рабочего проекта участие в бета-тестировании стоимостью в 380 т.р.
Ошибка по передаче значения от команды уже исправлена. Скрипт заработал. В принципе можно пробовать и на текущей версии, но есть еще одна ошибка - команды при старте не инициализируются "Выкл". Нужно каждую вручную прощелкать.
Эту ошибку мы тоже сейчас устраняем.
Если успеете, то гляньте пожалуйста и еще на один небольшой недочет: мнемосхема типизированного объекта открывается с полосами прокрутки, если открывать ее через изображение объекта. Но если вызывать мнемосхему через ПКМ в дереве объектов, то все нормально. По видео можно увидеть процесс:Цитата:
Сообщение от SCADAMaster
Не проявляется. Приложите текущую версию проекта, и укажите к мнемосхеме откуда вы вызываете окна типизированных объектов.
Вызов может происходить из нескольких мест на главном окне:Цитата:
Сообщение от SCADAMaster
Но результат всегда одинаков:
Если вызывать через ПКМ в дереве объектов, в рантайме:
Никаких скроллбаров не наблюдается:
Можете не обращать внимание на эти скролбары, лучше почините обратно сообщения о превышении пороговых значений! :D
Прикладываю видео на котором видно, что сообщения не формируются в журнале.
Так же история с отчетами так и не разрешилась! По трендам видно, что история у значений имеется, так же имеется претензия к отображению строк, у которых отсутствует значение на момент вывода отчета - расчет максимума и минимума в этом случае просто выпадает в крайнее значение и в итоге в таблице полная вакханалия.
Как обычно полный отчет об ошибках с конфигурацией и видео прикладывается. Ребят, давайте поднажмем... на следующей неделе испытания.
p.s. имеется так же небольшой баг с трендами (возникает очень редко) - он как раз попал на первые секунды видео, при открытии тренда может открыться совершенно постороннее окно.
Проект запускался на сегодняшней сборке:
Вложение 33771
upd. А теперь все заработало (по части отображения аварий).. хотя я просто добавил тестовый отчет и перезапустил скаду... Не совсем понял, что это было. Хотя даже при возникновении этих аварий счетчик событий "Активные неквитированные" не сработал и не увидел их почему-то.
Вложение 33772
С сообщениями ситуация иная. Ранее они выдавались вообще, сейчас они некорректно формируются при неизменности значения, но при изменении ВАГ и ВПГ. На тестовом кстати опять же работает нормально. Мы изучим эту проблему, но нам она кажется сейчас не столь актуальной - в реальном проекте текущее значение будет меняться, что приведет к формированию сообщения при его изменении.
По отчету не до конца ясна в чем проблема. Большое значение в ячейки выводится если не было данных - обработка Min некорректно обрабатывает эту ситуацию. Мы уточним у разработчиков редактора, как можно покрасивее решить эту проблему, но в крайнем случае можно будет просто несколько изменить условие чтобы подобные большие числа скрывались.
А зачем вы вообще сделали так отчет? Сначала бэнд данных по изменению (их там могут быть тысячи), а потом ищите максимум, минимум и среднее. Зачем? Просто сделайте источник данных "Итоговый", задайте параметры Начало и Конец, и у каждой колонки задайте нужный вам способ обработки - последнее, максимум, среднее интегральное. И прямо эти колонки и выводите (в бэнде Данные).
P.S. И кстати в том режиме подсчета среднее как у вас, среднее считаться будет неправильно, так как данные в архиве могут идти не равномерно. Нужно считать не среднее, а интегральное среднее
Проблема с отчетом в том, что он не выдает данные, т.е. на видео видно, что значение виброускорения менялись:Цитата:
Сообщение от SCADAMaster
Вложение 33775
После выбора промежутка времени и открытии отчета данных по этому ускорению никаких:
Вложение 33776
Тоже хотел так сделать, но в вариантах обработки у меня всего три параметра, хотя в хелпе их гораздо больше:Цитата:
Сообщение от SCADAMaster
Вложение 33777
Потому что в свойствах источника данных у вас установлен отчет по изменению, а нужно итоговый.
Пропустил этот момент, спасибо. Попробовал итоговый отчет и вроде дело пошло, но вопрос с показаниями сейчас самый важный.Цитата:
Сообщение от SCADAMaster
Цитата:
Сообщение от SCADAMaster
Очень необходимо решить эти проблемы как можно скорееЦитата:
Сообщение от SCADAMaster
Ошибка, при которой не выполнялась инициализация переменных (команды выключающей опрос) решена.
Версия выложена на FTP.
Отлично, теперь поехали по замечаниям:Цитата:
Сообщение от SCADAMaster
1. Сигналы теперь грузятся, но не все и не всегда - проводил 3 запуска подряд и каждый раз в первой насосной несколько агрегатов не заводятся (все подробности на видео №1). Теперь у некоторых из них не прогружается другие переменные на входе - у кого-то OPCStatus, у кого-то SensorStatus, OPCNormal или SensNormal, причем в одном запуске отдельный агрегат может завестись нормально, а в следующей загрузке он уже вылетает в ошибку. Самое интересное, что это касается только первой насосной, исключение составляют сигналы от задвижек (видео №2) - у них так же не грузятся OPC статусы.
Вложение 33802Вложение 33803Вложение 33804
2. Счетчик событий почему-то не считает системные сообщения о превышении пороговой величины. Т.е. знак аварии (Треугольник с восклицательным знаком) моргает при появлении активных неквитированных тревог, но даже когда срабатывает превышение и в журнале появляется соответствующая запись, то счетчик не учитывает это событие. В то время как на ошибку отсутствия связи он реагирует адекватно и моргает на агрегатах, окрашенных серым цветом.
Как обычно полный комплект данных прилагается.