Зарегистрирован: Dec 22, 2009 Сообщения: 61 Рейтинг: +0/-0 Откуда: Кировская обл.
Добавлено: Чт 24 Май, 2012 10:33:01 Заголовок сообщения: Проблемы c моделями истории и опросом пар в RSView32 v. 7.20
Здравствуйте уважаемые коллеги, в процессе эксплуатации RSView32 V7.20 CPR 7 возникло несколько проблем:
1.Остановка записи некоторых моделей истории, причем модели останавливаются разные, и на следующие сутки они снова сами не запускаются, настройка моделей: создание файла периодическое ежедневное. От проектов RSView не зависит и на разных машинах. Лечится удалением файлов DLG и DNS в папке модели истории или удаление папки целиком. Но это очень не удобно надо постоянно отслеживать работу модели и хорошо, если это модель для графиков, персонал сразу замечает, а если модель срабатывания блокировок и т.п., где нет визуального контроля, короче потом возникают неприятные ситуации при разборе «полётов». Да и за всеми не уследишь, когда машин на предприятии достаточно много.
2.Замирает опрос одного или двух параметров, т.е. он или вообще замирает или изменяется раз в минуту примерно, и что самое интересное остальные изменяются нормально, опрос в нодах установлен раз 1 секунду, так же не зависит от проекта и машин. В Linx 2.54 в этот момент нет никаких ошибок, обмен идёт в пакетном режиме. Лечится перезапуском проектRSView или машины.
Может у кого есть опыт решения подобных проблем, и как с этим бороться, буду благодарен за информацию и обсуждение.
Причин сего явления может быть множество, причём самого разного свойства, как зависящих от каких-то факторов в файловой системе Windows, так и в конфигурации RSView. Как определить причину в Вашем компьютере на расстоянии, честно говоря, не представляю.
Так было всегда, или появилось некоторое время назад?
Было ли время, когда система работала нормально, без этих явлений? _________________ Обращайтесь к профессионалам.
Windows XP SP2, файловая система NTFS.
Где то сразу идут такие проблемы, где то спустя какое то время. Это проявляется не на одной машине, а на разных и в разных проектах RSView. Бывает после перезапуска машины, модель истории может не запуститься, а перезапуски делают, когда замирает опрос параметров. На вирусы проверяли, все чисто.
К примеру, на другой системе замирания опроса параметра, стали проявляться, когда добавили третью машину оператора, но как это может быть связанно, не очень понятно, потому что на сколько я знаю, допускается использование трёх машин, без использования сервера GATEWAY, т.е. каждая машина напрямую обращается к контроллеру. В проекте опрашивается 4157 тегов.
Используется 7 контроллеров FlexLogix 1794 v16.22 и три оперторские станции.
По опыту знаю, что когда три машины под RSView32 независимо друг от друга лезут в сеть и опрашивают несколько оконтроллеров, то это почти всегда создаёт очень серьёзную нагрузку на сеть, иногда близкую к граничной. Это, в свою очередь, может привести к замедлению работы и (при дальнейшем увеличении нагрузки на сеть), даже к её отказу, не считая нарушений функциональности системы - более или менее заметных.
Знать точно Вашу ситуацию я не могу, но думаю, что сеть у Вас серьёзно забита сканированием контроллеров со стороны рабочих станций. Если моё предполжение верно, то попробуйте разгрузить сеть.
Что произойдёт, если Вы отключите одну рабочую станцию на какой-то немаленький промежуток времени (хотя бы несколько часов)? Уйдёт ли тогда этот неприятный эффект, или будет наблюдаться дальше?
Если система будет устойчиво и без сбоев вести модели данных на двух станциях вместо трёх, то моё предположение верно, и тогда надо заниматься разгрузкой сети.
Что будет, если на несколько часов оставить только одну (1) рабочую станцию, а остальные выключить? Уйдёт ли тогда этот неприятный эффект, или будет наблюдаться дальше?
Если неприятности будут продолжаться при работе только 2-х или даже 1-й станции, то надо копать более глубоко. Например: что показывают лог-файлы Windows на этой единственной работающей станции - нет ли ошибок, предупреждений и т.п.? _________________ Обращайтесь к профессионалам.
К сожалению эффект остановки моделей истории проявляется не каждый день, а может проявится через неделю или две или вообще месяц, а отключать на такой период времени машины нет возможности. Обычно модели останавливаются при перезагрузке машины, после её зависания или остановки опроса параметра и персонал сам перезапускает машину, путем отключения питания при запущенном проекте АРМ, что и вызывает сбой, как я подозреваю. Может есть какой-нибудь upgrade для RSView, который устраняет данный эффект, не возобновления записи истроии?
Под разгрузкой сети вы подразумеваете установку сервера RS Linx GATEWAY, что бы машины обращались к нему?
Версия 7.20 - это устойчивая версия, в неё не наблюдается каких-либо багов с Data Logging. Разумеется, можно сделать update до самой актуальной версии 7.60, но с вероятностью 99,9% дело не в этом.
Vladimir_Ch писал(а):
Под разгрузкой сети вы подразумеваете установку сервера RS Linx GATEWAY, что бы машины обращались к нему?
Не только это, но и многое другое.
1) Грамотная установка классов сканирования тэгов для foreground и для background (никогда не используйте значение 0, создайте несколько классов сканирования с различными периодами опроса, например, foreground 1с, 2с, 4с, 8с, background 8с, затем вдумчиво разбейте тэги на группы с различным периодом опроса, сканируйте каждую группу тэгов так редко, как это только имеет смысл и т.п.)
2) Какая у вас сеть? Если рабочие станция связаны с контроллерами по Ethernet, то используете ли вы хабы или свичи? Должны быть свичи, причём хорошие, с хорошей быстрой задней шиной, желательно с IGMP-Snooping. Есть ли у вас в этом сегменте сети ещё какие-нибудь устройства, которые грузят сеть? Если да, то выделите их в отдельный сегмент.
3) RSLinx - посмотрите в Windows в список процессов, сколько процентов системных ресурсов потребляет RSLinx. Если более 20%, то это много, нужно что-то думать, т.к. ресурсов может не хватать.
4) Посмотрите, как расположены в контроллерах сканируемые данные. Чтобы снизить нагрузку на процессор и сеть, данные нужно располагать по возможности более плотно, т.е. для получения двух тэгов со смежными адресами, например, B3:0/0 и B3:0/1 обычно требуется примерно вдвое меньше ресурсов, чем для передачи двух тэгов с адресами, например, B3:0/0 и B3:1/9.
5) Что показывают системные логи Windows на рабочих станциях? есть ли в них ошибки или предупреждения?
и т.п. _________________ Обращайтесь к профессионалам.
Последний раз редактировалось: oldDad (Пн 04 Июн, 2012 18:32:13), всего редактировалось 1 раз
Занимательная история ... было у нас что-то похожее ...
Посмотрите для начала значения следующих параметров:
в настройках RSLinx:
- значение Communications\Configure Cip Options\Connections for clx processor\Optimize User Defined Data Types
(если вы используете типы данных User-Defined, обязательно д.б. включен)
- значения поля Packets/sec в окне DDE/OPC\Optimized Packets
в RSLogix:
- System Overhead Time Slice (при таком обмене д.б. 30-40%)
в RSView:
- сколько у вас DataLog'ов и сколько параметров вы пишете
- как настроены DataLog'и
DataLog настроен: каждый день создавать новый файл, стирать по истечению 30 дней, пишется в зависимости от модели, где только аналоговые, то по изменению на 1% или через каждые 30 секунд, а где только дискретные по изменению состояния параметра.
Используем в среднем 10 моделей истории.
Кол-во параметров допустим в аналоговой модели ~300.
В Linx все настройки так и сделаны, как у вас написано, в RS logix System Overhead Time Slice установлено 40%
И вот вчера снова произошёл случай у нас: была гроза, упала сеть и после её восстановления из 200 параметров снова только два параметра опрашивались с большими задержками, а остальные нормально, вылечилось перезапуском ПЭВМ.
К сожалению, практика показывает, чем проще, тем надежнее работает. Ну а после пропадания соединения возможны какие-угодно сюрпризы, и ваш случай не исключение.
Попробуйте следующее:
- уменьшить количество тэгов в моделях до 100
- используйте Storage Format - Wide
- перевести все модели "по изменению" на запись с заданной дискретностью (гораздо лучше будет работать модель с записью пусть даже 1сек, чем по изменению на 1%!!!)
Если данная картина происходит всегда!!! после проблем со связью, скорее всего DataLog не причем. В таких случаях RSView пытается восстановить связь с контроллером(ми), а эту задачу выполняет RSLinx. Бывает, что как раз сам RSLinx некорректно оптимизирует обмен данными и появляются задержки с обновлением данных и т.п. Это можно посмотреть в окне DDE/OPC Optimized Packets, в нормальном режиме в поле Item Count значения должны быть больше 1!!!, а значение Packets/sec должно примерно соответствовать значению установленному вами при конфигурировании соотв. топика до контроллера.
И еще ... как у вас обстоят дела с обновлениями на продукты Rockwell?
Если их нет, обязательно поставьте все патчи!
у нас WIDE установлен.
а модели разбить по 100 параметров не получится, просто не хватит кол-ва одновременно запущенных моделей, насколько я знаю их должно быть не более 15.
Необязательно. Это зависит от того, сколько каких продуктов и когда у вас приобретено и зарегистрировано. В зависимости от этого, update будет предоставлен либо бесплатно, либо в рамках контракта на услугу TechConnect. _________________ Обращайтесь к профессионалам.
продукты приобретены 3-4 года назад,точно не помню и контракта поддержки нет(
сколько примерно update стоит?
и ещё вопрос сколько рекомендованно или не более скольки машин и контроллеров может быть в одной сети, в одном проекте?
насколько я знаю не более трех машин рекомендуют, без использования RS Linx GATEWAY, а не более скольки контроллеров для стабильной работы системы?
и ещё вопрос сколько рекомендованно или не более скольки машин и контроллеров может быть в одной сети, в одном проекте?
насколько я знаю не более трех машин рекомендуют, без использования RS Linx GATEWAY, а не более скольки контроллеров для стабильной работы системы?
в принципе, рекомендовано использовать один сервер RSLinx и до 10 Logix контроллеров на один RSLinx, но в вашем случае 3 машины это не критично.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
Smart Solutions VDT GmbH | Friedrich-List-Allee 38, D-41844 Wegberg-Wildenrath, Germany Tel.: +49 2432 933 57 83 | e-Mail: office@vdt-solutions.de Все товарные знаки и торговые марки являются собственностью их владельцев.
При использовании материалов сайта ссылка на данный сайт обязательна. Открытие страницы: 0.145 секунды
FAQ
Поиск
Группы
Профиль
Войти и проверить личные сообщения
Вход
