 | |
Предыдущие результаты
 [quote:e2c0fc6010="chameleon"]Пять рабочих станций с проектами RSView32 (примерно 5 тыс аналоговых и 1 тыс дискретных тэгов) прописаны "локально" (т.е. на каждом компьютере свой OPC сервер) на один из двух контроллеров-концентраторов, расположенных в отдельных шасси, и полностью дублирующих себя по функциям.
[/quote:e2c0fc6010]
Как я уже говорил, каждая станция с RSLinx формирует до 4-х (по умолчанию) коннектов, итого 5*4=20. Вам можно попробовать настроить на одной или 2-х рабочих станциях RSLinx Gateway и подключать остальные станции по OPC через их Remote OPC Server.
[quote:e2c0fc6010="chameleon"]Активным может быть только один из концентраторов.В каждом шасси расположено по 2 модуля ENBT (через первый прописаны топики на рабочих станциях, а через второй - топики для сервисных станций: загрузка проектов Logix, проектов RSView32, и др.). Также в каждом шасси присутствуют по 5 CNBR-ов для связи с другими подсетями ControlNet. Из них самым загруженным является тот, который я уже описывал выше, т.е. через него количество коннектов может возрастать до критичных значений (55-60).
Теперь опишу сеть, одним из узлов которой является данный загруженный CNBR. Причем стоит отметить, что у этого узла наименьший адрес - скорее всего он является и кипером. [/quote:e2c0fc6010]
Вы организуете резервирование процессорных модулей с помощью 1757-SRM? Если да, то необходимо учитывать, что активные киперы по умолчанию (CNBR-ы с наименьшим адресом) нельзя размещать в резервированных шасси, т.к. переключение с основной на резервную корзину нарушит работу сети. Какая версия прошивок процессорных модулей и CNBR? ПО возможности, следует обновлять прошивки последними версиями.
По поводу организации межпроцессорного обмена, могу повторить то что говорил ранее: от MSG по возможности желательно отказаться, всю порцию данных от одного проц. модуля желательно "упаковывать" в один боьшой массив и планировать этот массив в расписание сети, чтобы остальные проц. модуля его потребляли оптимальным образом.
Также обратите внимание, что для межпроцессорного обмена необходимо устанавливать у удаленных CNBR-ов режим соединения "None" - и не в коем случае не "Rack Optimisation"!!!
|
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? Но с ней я никогда не работал и её функции мне не известны.
|
Можно ли как либо контролировать присутствие в сети ControlNet - PanelView550?
Панель подключена как Unscheduled. Процессор - ControLogix, диагностика на RSView.
|
Приветствую всех!
Интересует вопрос диагностики сетевых соединений устройств, висящих на ControlNet из SCADA-системы RSView32.
Хотелось бы видеть на экране мнемосхему всей сети ControlNet, причем не только контроллеров, но и других станций.
Из набора системных тегов RSView32 понятно, что можно диагностировать OPC-соединение с сервером OPC:
system\ComErrorStringOPC (string)
system\ComErrorValueOPC (analog)
system\ComStatusStringOPC (string)
system\ComStatusValueOPC (analog)
Честно говоря, этот путь не очень устраивает, так как фактически мы диагностируем связь с RSLinx.
Как можно решить такую задачу? Что можно(нужно) дописать в контроллере для реализации задачи? Может можно как-нибудь обратиться к Linx, чтобы взять конфигурации сети?
Заранее благодарен,
Vitaliy D. Burtsev
|
Большое спасибо! Четко и понятно - приятно работать :)
Тогда следующий вопрос:
[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 соответственно. Т.о. базу данных тэгов перелопачивать не надо - ограничиваемся только переименованием узла.
Является ли правильным данный подход, или это можно делать как-то автоматически, или можно системными средствами переименовывать узлы, а не вручную?
Заранее спасибо! :)
|
Начну с конца - с траффика ControlNet. С его точки зрения совершенно безразлично, сколько и каких задач будет "крутиться" в процессоре. Что ему небезразлично - так это сколько рабочих станций будут одновременно запрашивать одни и те же тэги. Самой распространённой ошибкой является решение задачи "в лоб" простым распараллеливанием рабочих станций, что есть неправильно и неминуемо ведёт к проблемам с производительностью системы. Но это - другая тема.
Слава, простите, но обоснования, которые Вам приводят в качестве аргументов, я вряд ли могу назвать состоятельными.
[quote:4c5775b220]1. не будет риска повторного запуска задачи до того, как она завершится. [/quote:4c5775b220]
Такого риск в мультизадачных системах реального времени исключен по определению. Чкловек, утверждающий, что такой риск есть, попросту не вполне разбирается в предмете. Пусть он Вам объяснит, что он слышал об очередях задач и о реентерабельности исполняемого кода :).
[quote:4c5775b220]
2. обслуживание основных технологических задач должно осуществляться в фоновом режиме.
[/quote:4c5775b220]
Почему вдруг именно "должно", а не "могло бы"? Совершенно это, знаете ли, неочевидно и нелогично. Если уж основные функции системы должны выполняться в фоновом режиме, то какие же тогда функции должны выполняться на переднем плане?!
Смотрите: основная задача системы - это наиболее динамичная своевременная реакция на события во внешней среде. Поэтому-то мы и называем такие системы системами реального времени, что в них мы имеем возможность реагировать на события не тогда, когда сможем, а тогда, когда надо, совершенно точно зная, когда именно событие будет обслужено и точно планируя приоритетность процессов обслуживания.
Основные принципы таковы:
- если во внешней по отношению к системе среде происходят события различной степени важности и с различной критичностью ко времени обслуживания, то каждому такому событию (или классу событий) должна быть поставлена в соответствие задача, обслуживающая данное событие / класс событий. для этого в контроллере существует многозадачность.
- если события во внешней среде обладают различным приоритетом, то и задачи, обслуживающие данное событие, также должны иметь не одинаковый, а различный приоритетю. Так, формирование массива данных индикации, скажем, имеет более низкий приоритет, чем ПИД-регулирование, а оно - более низкий приоритет, чем обслуживание аварийных блокировок. Не так ли? Для этого в е контроллере ControlLogix и существует 15 уровней приоритета.
- если во внешней среде возникает ссобытие, которое должно быть обслужено немедленно, не дожидаясь, когда до обслуживающего его кода дойдёт "лестница" строчек (а кто сказал, кстати, что это время ожидания обслуживания в однозадачной систем всегда будет одно и то же?), то многозадачная система гарантирует возможность немедленного обслуживания такого события.
- я уж не говорю о том, что многозадачную систему легче писать, олаживать и сопровождать, т.к. куда легче иметь дело с относительно короткими обозримыми кусками кода, чем с одной очень длинной процедурой. Планирование вычислительного процесса тоже получается легче, проще и прияьнее.
- знаете, есть такое утверждение: любую логическую схему можно построить с помощью элементов 2И-НЕ. Действаительно, можно. Но зачем? Зачем строить триггер, а потом из них строить счётчики и сдвиговые регистры, когда естьготовые микросхемы?
Так и тут - зачем думать о последовательности выполнения задач, писать какие-то диспетчеры заданий или задач, вызывая их "руками" в нужный момент из одной в другую, когда такие вещи уже созданы в операционной системе?
А как Вы поступите с задачами, имеющими различную важность, например, с аварийными блокировками и расчётами расхода с коррекцией по температуре и давлению - что, все в очередь?
Ещё одно: как Вы добьётесь хорошего качества ПИД-Регулирования, если расчёт управляющего воздействия будет выполняться нерегулярно, а в зависимости от текущего времени скана, которое варьируется в некоторых пределах, а если задача одна и большая - то и в довольно широких преедлах может? Не проще ли посадить ПИД-инструкции в отдельную задачу, запускаемую в строго отмеренные интервалы времени?
[quote:4c5775b220]3. объем заложенной логики выполняется (в отсутствие других задач) достаточно быстро [/quote:4c5775b220]
Я вижу здесь противоречие. Простая арифметика показывает, что если задача будет одна, то её время скана будет в несколько раз больше, чем у одной из более коротких задач. А в многозадачной систем время выполнения каждой из задач значительно меньше, чем если их все "слепить" воедино.
Если же речь идёт о "накладных расходах", связанных с диспетчеризацией задач, то они:
- перенебрежимо малы
- аппаратно выполняются всё равно быстрее, чем реализованный программно некий самодельный диспетчер.
[quote:4c5775b220]фоновая задача - она и есть фоновая, её приносят в жертву всему остальному.[/quote:4c5775b220]
Слава, Вы абсолютно правы. Она именно поэтому так и называется.
Многозадачности бы не было придумано и реализовано, если бы она не была нужна. ControlLogix - это на сегодняшний день самое совершенное творение контроллеростроения, результат многолетнего опыта разработки и эксплуатации, квинтэссенция знаний и передовых технологий. И если мировой лидер в этой отрасли ушёл от однозадачности и реализовал в контроллере многозадачную среду реального времени с детерминизмом и распараллеливанием потоков, то это о чём-то всё-таки говорит.
[quote:4c5775b220]Как бы нам не поиметь проблем с учетом дальнейшего развития системы[/quote:4c5775b220]
Я думаю, что есть соединить все функции системы в одну задачу, то как раз тогда Вы проблемы и можете поиметь.
Простой вопрос: какую систему проще сопровождать: состоящую из одной необозримо длинной задачи или из разумного количества более коротких задач, имеющих вполне определённые функции?
В какую из этих систем проще в процессе добавлять функции - в качестве заплаток в одну длинную задачу там и сям, долго и нудно вылавливая нестыковки и перекрёстные ссылки, или добавить одну в достаточной степени автономную задачу?
Проще, надёжнее и приятнее - в многозадачную.
|
Здравствуйте, коллеги! Здравствуйте, Игорь Аркадьевич!
У нас возник принципиальный спор о программных способах реализации поставленных перед нами задач на базе RSLogix5000.
Есть непрерывный технологический процесс, несколько десятков управляемых электрозадвижек.
Нам предлагают поместить всё (сбор информации, управление, обслуживание SCADA) в циклическую задачу, обосновывая это тем, что:
1. не будет риска повторного запуска задачи до того, как она завершится.
2. обслуживание основных технологических задач должно осуществляться в фоновом режиме.
3. объем заложенной логики выполняется (в отсутствие других задач) достаточно быстро
Выскажите, пожалуйста свое мнение, поделитесь личным опытом построения систем, т.к. мне кажется, что фоновая задача - она и есть фоновая, её приносят в жертву всему остальному. Как бы нам не поиметь проблем с учетом дальнейшего развития системы (появлении периодических задач, которые будут прерывать фоновую, и т.д.). Да и иметь такой функционал, как у RSLogix5000, и не использовать его :? как то неправильно.
На сколько я знаю такой подход может плохо отразиться на трафике ControlNet, т.е. в SCADA возможны тормоза - правильно ли я думаю?
|
:)
Я рад, что Вам удалось в основном решить эту задчу. Эти характерные затыки обычно бывают не с ОРС и ControlNet, а с процессором, когда ему не дают достаточно времени на то, чтобы он занимался оптимизацией своей мультизадачности и оптимизацией коммуникаций. Периодическая задача как раз даёт процессору такую возможность, оставляет ему время для занятий собой.
Что касается помаргивания - это, скорее всего, с пропусной способностью канала не связано. Известны аппликации с куда бОльшим траффиком, и там ничего не моргает. Тут нужно проанализировать более детально.
Что именно моргает и как именно построено это отображение? Что откуда и когда приходит?
|
[quote:22dd915957]Вы не знаете где можно почитать про расположение тегов в памяти(может на примере SLC) и механизмам передачи данных по СontrolNet-у? . [/quote:22dd915957]
В SLC совершенно другой принцип организации памяти, там ничего оптимизировать не надо, там ведь статическое распределние памяти. А в ControlLogix - динамическое.
О принципах оптимизации много написано. Посмотрите, например, вот эти документы, там много полезных советов:
http://www.software.rockwell.com/download/comms/rslinx/controllogix%20data%20collection%20with%20rslinx.ppt
http://www.software.rockwell.com/download/comms/rslinx/clx_perf.zip
http://www.opcwebclient.com/Support/Documents/Performance___Optimization/performance___optimization.html
http://helpdesk.ingeardrivers.com/supportsuite/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=38
http://www.software.rockwell.com/download/comms/rslinx/controllogix%20data%20collection%20troubleshooting%20guide.doc
[quote:22dd915957]Сел, покопался, так пока и не нашел как эти классы к моим тегам прикрутить. [/quote:22dd915957]
Что можно попробовать, так это создать в RSLinx несколько топиков с разными тэгами по группам, а для каждого топика определить настолько болшой интервал сканирования, насколько возможно (для каждого топика в Data Collection определить различные интервалы Polled Messages. Это как бы разные классы сканирования.
[quote:22dd915957]Пока стараюсь настроить RSLinx Gateway, может вытащу одну машину из сегмента ControlNet.[/quote:22dd915957]
Это хорошее решение. У Вас сеть забита в основном unscheduled-тэгами. Надо что-то делать.
(Я включил пока возможность загрузки картинок на этот сервер, смотрите в меню в разделе "Новая информация" - "Добавить картинку")
|
[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.
|
Предыдущие результаты
Ещё результаты |
|
| |
|
