 | |
Предыдущие результаты
 Так как нет возможности задействовать бОльшее количество машин (и так уже все полкомнаты проводами опутал, другие сотрудники ворчат), то и FT-сервер и контроллер домена и HMI-сервер установлены на одной и той же физической машине.
На обект заказано все в соответсвии с рекомендациями Rockwell: 2 сервера для контроллеров домена (основной и резервный), 2 сервера для RSView SE (основной и резервный. Я пока что использовал только 1 HMI сервер. Больше не пробовал т.к. нет необходимости.
2 oldDad: связь везде по EtherNet
|
Vad, Спасибо за ответ.
Всю сеть со всеми подробностями мне будет трудно описать по памяти, но я опишу её глобально.
Пять рабочих станций с проектами RSView32 (примерно 5 тыс аналоговых и 1 тыс дискретных тэгов) прописаны "локально" (т.е. на каждом компьютере свой OPC сервер) на один из двух контроллеров-концентраторов, расположенных в отдельных шасси, и полностью дублирующих себя по функциям. Активным может быть только один из концентраторов.
В каждом шасси расположено по 2 модуля ENBT (через первый прописаны топики на рабочих станциях, а через второй - топики для сервисных станций: загрузка проектов Logix, проектов RSView32, и др.). Также в каждом шасси присутствуют по 5 CNBR-ов для связи с другими подсетями ControlNet. Из них самым загруженным является тот, который я уже описывал выше, т.е. через него количество коннектов может возрастать до критичных значений (55-60).
Теперь опишу сеть, одним из узлов которой является данный загруженный CNBR. Причем стоит отметить, что у этого узла наименьший адрес - скорее всего он является и кипером.
В сети 12 узлов, расположенных в разных шасси. Каждый узел служит для связи с другим контроллером.
Теперь о проблемах.
1. Периодически возникали ситуации, когда не возможно было связаться с контроллерами-концентраторами через Logix. Выдавалось сообщение о превышении количества коннектов. Здесь причина понятна, просто на тот момент не было достаточных средств диагностики. В данный момент уже сделал контроль состояния загрузки CPU модулей ENBT и CNBR, и коннектов через CNBR.
2. Иногда возникали ситуации, когда один из модулей CNBR в шасси-концентраторов светил загрузку центрального процессора 100%. Т.е. фактически "зависал" и лечилось это только передергиванием модуля. Но вот интересно, сказывалось ли это на работе других модулей в шасси, а особенно на ENBT.
3. Недавно, несколько дней подряд, возникала ситуация, когда загрузка центрального процессора под 100% светилась на одном из модулей ENBT. Продолжалось это примерно 4 минуты (время оставалось одинаковым для всех случаев). А в одной из таких ситуаций загрузка процессоров в районе 90-100 % светилась на всех 4-х модулях ENBT в двух корзинах-концентраторах.
После всех этих проблем необходимо было анализировать откуда они возникают. По двум последним ответ не был найден, а в первой проблеме основным было выяснить откуда берутся коннекты на загруженном CNBR-е.
Около 35 коннектов дает запланированный обмен (я считал по потребляемым тегам в других проектах Logix). Остальные, около 20, образуются от MSG, причем некоторые из них не кэшируются, поэтому значение может меняться. Коннектов от модулей ввода-вывода нет, т.к. в I/O проектов концентраторов прописаны только L-55. А дают ли они дополнительное соединение мне не известно.
По проблеме с модулями ENBT, возможно, необходимо применить программу RSNetworx for Ethernet? Но с ней я никогда не работал и её функции мне не известны.
|
Большое спасибо! Четко и понятно - приятно работать :)
Тогда следующий вопрос:
[quote:bcfdd18122]4. Если не хотите или не можете использовать RSViewSE, а компьютеров с HMI должно одновременно работать более. чем 2, то применяйте хотя бы RSLinx Gateway на одном (или двух компьютерах, если нужен резерв), а остальные компьютеры "вешайте" на Ethernet у тому. на котором работает RSLinx Gateway.
[/quote:bcfdd18122]
Допустим, что две станции ST1 и ST2 подключены к ControlNet, на них установлен RSLinxGateway (одна из станций ST2 - резервный RSLinx Remote OPC Server). На третьей станции ST3 конфигурируем узел, который ссылается на первую станцию ST1 - например OPC_ST1, формируем базу данных тэгов, в имени которых фигурирует название узла OPC_ST1.
Переход на резервный RSLinx Remote OPC Server вижу таким образом:
на станции ST3 конфигурирую узел, который ссылается на станцию ST2 - например OPC_ST2. В базе данных тэгов данного проекта имя этого узла не встречается.
В случае выхода из строя станции ST1, на станции ST3 переименовываю узел OPC_ST1 в OPC_ST1res, а OPC_ST2 в OPC_ST1 соответственно. Т.о. базу данных тэгов перелопачивать не надо - ограничиваемся только переименованием узла.
Является ли правильным данный подход, или это можно делать как-то автоматически, или можно системными средствами переименовывать узлы, а не вручную?
Заранее спасибо! :)
|
[quote:b48ddcf42c]Просто странно не использовать одинаковые проекты RSView, например, в одной системе: это проще и обслуживать, и разрабатывать, и исправлять во время наладки, и контролировать версии и т.д. [/quote:b48ddcf42c]
Видите ли, нужно использовать не просто [color=darkblue:b48ddcf42c]одинаковые[/color:b48ddcf42c] проекты RSView, а [color=darkblue:b48ddcf42c]один и тот же[/color:b48ddcf42c] проект RSView, причём не несколько параллельно работающих копий его, а именно один-единственный :) Правда, не RSView32, а RSViewSE, который именно для этого и предназначен.
Видите ли, с тех пор, как стали применяться контроллеры ControlLogix (и lдругие из серии Logix) с мультизадачной операционной системой и динамическим распределением памяти, принципы организации связи систем HMI с контроллерами изменились.
Дело обстоит так, что если просто механически увеличивать количество одновременно работающих на шине проектов HMI, и при этом пренебречь этими соображениями, то производительность системы может пострадать. Проблемой является то, что при проектировании систем с контроллерами серии Logix люди исходят из тех же соображений и принципов посторения систем, которые применялись раньше, с более простыми старыми контроллерами без мультизадачности и динамического распределения памяти, какими были SLC и PLC-5, и всё ещё выпускаются другими производителями. Кроме того, старые сети с низкой скоростью обмена, работащие по принципу "master-slave" и не имеющие CIP и предсказуемого времени доставки, работали по совершенно другим принципам, не обеспечивающим детерминизма в реальном времени. При этом использовался совершенно другой механизм обслуживания рабочих станций.
RSView32 - это достаточно старый продукт, он был создан в эпоху, когда ещё не было ни тэгов в контроллерах, ни динамического распределения памяти, ни самого ControlLogix, ни встроенной мультизадачности, ни прозрачных благодаря CIP детерминированных сетей. RSView32 широко применяется и сейчас для тех случаев, когда нужен all-in-one stand alone продукт, когда количество компьютеров не превышает 2 или применяются старые контроллеры не-Logix.
Но для вновь проектируемых на базе контроллеров Logix систем рекомендуется всё-таки применять не RSView32, а RSViewSE, т.к. даже если в системе предусматривается только один компьютер с HMI, продукт RSViewSE Stand Alone обеспечивает более оптимизированный обмен с контроллерами.
RSViewSE оптимизирована для мультиклиентского применения и строится на (несколько) иных принципах, которые нужно знать и учитывать при проектировании системы. Поэтому при построении системы с нескольими (3 и более) компьютерами, которые собирают данные по OPC, нужно учитывать вполне определённые вещи, от которыъ непосредственно зависит производительность системы.
В соответствии с веянием времени повысились требования к скоростям передачи информации, к реактивности системы, к детерминизму сетей, что непосредственным образом повлияло на идеологию построения рапределённых систем управления. Принципы построения таких систем отличаются от принципов построения систем с "простыми" контроллерами и сетями", их просто нужно знать.
Коротко: если в Вашей системе не 1 и не 2 компьютера, на которых должны работать проекты HMI, обращающиеся к одному и тому же контроллеру ControlLogix, то:
1. Если Ваша система построена на современных кнотроллерах серии Logix, а количество компьютеров, на которых должны работать средства HMI_ больше двух, то применяйте RSViewSE с выделенными (резервированными) серверами вместо RSView32, которая применялась с SLC или PLC-5.
2. Ставьте один или два сервера (если нужнол резервирование) и столько "тонких" клиентов, сколько нужно. Их колмчество неограничено.
3. Пользуйтесь RSLinx Enterprise, встроенным в RSViewSE вместо RSLinx Сlassic, использующегося с RSView32. Он специально предназначен для работы в конфигурациях с контроллерами Logix и мультиклиент-мультисерверной платформой HMI.
4. Если не хотите или не можете использовать RSViewSE, а компьютеров с HMI должно одновременно работать более. чем 2, то применяйте хотя бы RSLinx Gateway на одном (или двух компьютерах, если нужен резерв), а остальные компьютеры "вешайте" на Ethernet у тому. на котором работает RSLinx Gateway.
5. Не пренебрегайте рекомендациями по планированию производительности системы HMI, описанными в документации. И тогда у Вас получатся красивые, надёжные, "прозрачные" и очень быстродействующие системы :)
Вот здесь [u:b48ddcf42c][url=http://vdt-solutions.de/modules.php?name=Forums&file=viewtopic&p=529#529]здесь[/url][/u:b48ddcf42c] я уже привёл несколько важных документов.
|
Задача: необходимо иметь удаленный доступ к контроллеру для контроля, редактирования, обновления программы на контроллере без выезда программиста на объект (иногда изменение занимает 10мин., а дорога на Камчатку или Сахалин - это стоимость контроллера...или двух...когда штормит...или трех...когда тайфун...).
Регион: вся Россия, страны СНГ.
Типичная конфигурация: L32E, v15, комп(бук) в качестве панели оператора, на нем крутится RSView32 7.1, связь по Ethernet/IP.
Вопрос: какие методы/способы уже применяются? Где можно поподробней узнать об этом? Интересуют все возможные способы.
|
Есть проблема - отказ L34.
Краткое описание:
Контроллер 1769-L34 вышел из строя 7 апреля 2006г. Отказ был зафиксирован в 7.00 по Московскому времени.
Перед отказом 6 апреля до 22.00 по Московскому времени контроллер находился в рабочем состоянии, производилась отладка и проверка установленной программы в режиме RUN.
Состав системы:
1. 1794-L34
2. 1794-IB32
3. 1794-OB32
4. 1794-OB32
5. 1794-IF8
6. 1788-ENBT/A
7. 1788-CNC/A
Питание +24В всей системы от модуля 1606-XL240. Выхода ОВ32 развязаны с исполнительными устройствами через реле Finder, общий ток всех катушек реле на одном модуле ОВ32 не превышает установленных лимитов по паспорту. Катушки реле шунтированы диодами от влияния переходных процессов.
Силовая коммутационная аппаратура в шкафу управления отсутствует (кроме того, на момент отказа не был включен ни один двигатель исполнительных механизмов).
Силовая защитная аппаратура рассчитана конструкторским отделом относительно всей системы автоматики (на момент отказа ни один автомат защиты сети по ~220В и +24В в шкафу автоматики не сработал по защите).
В момент отказа модуль 1788-CNC/A был программно заигнорирован, коаксиальный кабель не был подключен.
В момент отказа производилась связь Ethernet/IP через модуль 1788-ENBT/A, через хаб на персональный компьютер.
Общее заземление между контроллером, корпусом шкафа, металлоконструкциями завода и компьютером соответствует необходимым требованиям, акт поверки сопротивления заземления имеется.
Порт RS-232 на момент отказа не был соединен электрически с какими-либо устройсвами.
Отказ был зафиксирован через Ethernet/IP (нет связи проекта RSView32 v 7.1). Перезапуск компьютера, RSLinx и проекта не дал результата. При осмотре контроллера светодиод "ОК" горел красным цветом постоянно, светодиод на модуле 1788-ENBT/A (не успели зафиксировать какой именно) тоже постоянно горел красным цветом.
Персоналом были произведены следующие действия:
1. Переключение ключа из RUN в PROG и обратно (несколько раз). Результат отрицательный.
2. Выключение/включение питания контроллера несколько раз. Самотестирование контроллера не происходит, сразу горит красным цветом светодиод "ОК".
3. Демонтаж контроллера и монтаж на стенде предприятия. Демонтаж модуля 1788-ENBT/A как вероятной причины ошибки контроллера.
4. Попытка связи через порт RS-232 не удалась, светодиод порта не индицирует наличие связи.
5. При отключенном питании демонтирована батарейка подпитки ОЗУ на 12 часов. После обратной установки батарейки состояние контроллера прежнее.
6. При отключенном питании произведена смена батарейки с рабочего контроллера этого типа. Состояние контроллера не изменилось. Батарейка с отказавшего контроллера полностью работоспособна.
7. Проверка модуля 1788-ENBT/A на другом подобном рабочем контроллере показала полную работоспособность модуля.
8. Проверка всех остальных модулей на рабочем контроллере показала полную работоспособность всех модулей.
Состояние контроллера на последний момент: при включении питания постоянно горит красным цветом светодиод "ОК", связь по порту RS-232 невозможна, визуальный осмотр контроллера и всего шкафа автоматики показал отсутствие видимых причин отказа или провокации со стороны обслуживающего персонала.
Вопрос стоит о вероятных причинах отказа, пусть даже теоретических. Какие воздействия могут привести к подобному отказу?
|
1. Входит ли RSlinx Gateway (9355-WABGWENE) в состав RSLinx Enterprise, входящий в поставку RSViewSE?
2.
[quote:b7e60d6204]Получите Вы вот что:
http://www.software.rockwell.com/rslogix/order.cfm [/quote:b7e60d6204]
Странно, в описании профессиональной версии ничего не сказано о RSNetworx for Ethernet/IP.
А как же тогда быть с публикацией [url]http://literature.rockwellautomation.com/idc/groups/literature/documents/pp/9324-pp001_-en-p.pdf[/url]
Ведь там сказано что в RSLogix 5000 Proffecional
RSNetWorx for EtherNet/IP [b:b7e60d6204]included[/b:b7e60d6204]
|
Сталкивался с подобной проблемой на ControlLogix, но на этапе наладки, поэтому дело темное (слишком много людей занято).
Также сталкивался с подобной проблемой на SLC 5/05 c EtherNet.
Сначала при наладке 3 года назад, потом недавно 3 месяца назад - после 2 лет нормальной работы.
Поставил Flash. :?
Во втором случае шкаф был закрыт и никто ничего не делал =(
Но в целом контроллерами доволен, т.к. за 5 лет понаставил уже штук 50.
Вспомнил, были такие проблемы с FlexLogix, в котором 64 kb памяти. Этот контроллер использует свой процессор и память и для модулей, и для программы, и для сетевого обмена. Если оставить в нем мало свободной памяти (значение не помню), то он больше недели не работает. :evil:
Видимо происходят коллизии при передаче данных, что требует дополнительной памяти и ... память обнуляется.
|
[quote:f5f0ad613e]Тогда нужно радикальное решение, "хирургия". Я думаю, что Вам нужно "отцепить" рабочие станции от шины ControlNet и посадить на отдельный сегмент сети (Ethernet достаточно, но можно и ControlNet). А для этого нужно вставить соответствующие модули в каждое из шасси контроллеров.[/quote:f5f0ad613e]
Хотелось бы радикальные решения пока не применять. :( Вы как то обмолвились, что успешно работают и более сложные системы, дело в правильности конфигурации. Раз у меня не работает, значит что-то не так. Будем искать. :)
[quote:f5f0ad613e]Если Вы уже оптимизировали расположение тэгов в памяти контроллера[/quote:f5f0ad613e]
Вы не знаете где можно почитать про расположение тегов в памяти(может на примере SLC) и механизмам передачи данных по СontrolNet-у? .
Вопросик в тему. У меня есть сотня датчиков температуры. Я определил тип данных TE_Sensor в котором два поля СV-Real(текущее значение в физ. величине); Limit-Real (верхний предел измерения датчика). Стоит ли создавать массив элементов типа TE_Sensor, а в программах работать с алиасами, или можно просто создать сотню тегов?
[quote:f5f0ad613e]поигрались со скан-классами в RSView32[/quote:f5f0ad613e]
нет не поигрался. у меня нет такой возможности. При выборе в редакторе тегов RSView32 в качестве узла локального сервера RSLinx, у меня пропадает список выбора скан-класса. :!: Сел, покопался, так пока и не нашел как эти классы к моим тегам прикрутить.
[quote:f5f0ad613e]поигрались с NUT (а если его увелисить до 15? или больще[/quote:f5f0ad613e]
Уж с кем я наигрался так это с NUT-ом. :D Максимально увеличивал до 40. Видимых изменений так и не получил.
Пока стараюсь настроить RSLinx Gateway, может вытащу одну машину из сегмента ControlNet.
|
Ну, раз у Вас только 2 рабочие станции, то смысла применять сервер, тем более резервированный, нет.
Если Вы уже оптимизировали расположение тэгов в памяти контроллера, поигрались со скан-классами в RSView32 ("быстрые" тэги часто, но по возможности реже, а "медленные"- настолько редко, насколько вообще возможно) и поигрались с NUT (а если его увелисить до 15? или больще?), и т.д., то "терапия! оказлась неэффективной.
Тогда нужно радикальное решение, "хирургия". Я думаю, что Вам нужно "отцепить" рабочие станции от шины ControlNet и посадить на отдельный сегмент сети (Ethernet достаточно, но можно и ControlNet). А для этого нужно вставить соответствующие модули в каждое из шасси контроллеров.
|
Предыдущие результаты
Ещё результаты |
|
| |
|
