 | |
Предыдущие результаты
 Уважаемые коллеги,
на своем предприятии практически вся автоматизация выполнена с использованием AB Controllogix. До появления RSView SE в качестве SCADA-системы использовался Citect или RSView32, одна установка под Plantscape. Две последних построенных установки успешно автоматизировали, применив RSView SE.
Учитывая наилучшую совместимость SE с AB Controllogix и выдающиеся интеграционные возможности SE, было принято решение включения всех существующих автоматизированных участков в единое информационное пространство на базе RSView SE: на старых участках заменяем SCADA-системы на SE и включаем вновь созданные HMI-сервера в уже существующее приложение (Application) на базе общего Factory Talk-сервера.
Несмотря на очевидные выгоды такой реорганизации, у нее нашлись противники, аргументирующие свою позицию уязвимостью выделенного FT-сервера (то есть сбой в работе FT-сервера грозит остановкой всего предприятия, что естественно недопустимо).
Официальные источники Rockwell заявляют, что отказ основного FT-сервера должен привести к переключению каждого ПК в сети на локальный FT-сервер этого ПК, в котором прокеширована вся необходимая информация.
Встает вопрос: насколько надежен такой переход на локальные FT-сервера, насколько быстро этот переход происходит? Не испытывали ли Вы на собственном опыте подобные переключения?
Наш опыт показывает, что клиенты на рабочих станциях в момент выключения центрального FT-сервера "зависают" на некоторое время... Хорошо было бы понять, от чего зависит длителность этой паузы и можно ли от нее избавиться...
Как Вы считаете, можно ли доверить одному FT-приложению все предприятие?
|
День добрый.
60 соединений - это действительно многовато. Больше 64-х модуль не создаст в принципе.
Откуда они берутся: в первую очередь, соединения устанавливаются с каждым удаленным CNBR, а также с модулями ввода-вывода удаленных корзинах. Обратите внимание на параметр "Comm Format" в настройках удаленного модуля CNBR. По умолчанию для этого параметра предлагается значение "Rack Optimisation" - такой вид соединения нужно использовать, если в удаленной корзине находятся только дискретные модуля вв/выв, тогда для связи с удаленной корзиной будет устанавливаться только одно соединение. Если же в корзине установлены аналоговые модуля, то режим "Rack Optimisation" надо заменять на "None", чтобы не нагружать сеть лишним трафиком - в режиме "Rack Optimisation" в опрашивающий процессорный модуль приходит информация порядка нескольких слов от каждого слота в удаленной корзине, даже если эти слота пустые или заняты аналоговыми модулями.
Таким образом, для экономии "коннектов" группируйте все дискретные модуля в отдельные корзины и опрашивайте их в режиме "Rack Optimisation", а для корзин с аналоговыми модулями выставляйте Comm Format = "None".
Производимые и потребляемые теги также тебуют отдельных соединений, как и Messages, но в данном случае рекомендую по возможности не использовать несколько MSG, а пользоваться одним большим массивом в режиме производитель/потребитель.
Сам RSLinx также создает дополнительные соединения для связи с процессорными модулями: в настройках Linx'а в меню Communications\Configure CIP Options\Connection for Controllogix Processors можно посмотреть и изменить макс. количество коннектов с одним PLC, по умолчанию стоит 4. То есть, каждый ПК с установленным на нем RSLinx и SCADA-системой, может "съедать" при соединении то количество коннектов, что указанов данном параметре.
ПРи вызове меню "Module Configuration" для данного CNBR RSLinx также создает дополнительные соединения.
В моей практике загрузка ЦП CNBR'а достигала 100% при "подвисаниях" CNBR из-за внутреннего сбоя... Вылечивается выниманием модуля из корзины и установкой обратно....
Расскажите, что у вас за проект, сколько удаленных корзин и модулей ввода-вывода, какая SCADA-система используется и сколько серверов ввода-вывода в сети?
|
Можно ли как либо контролировать присутствие в сети ControlNet - PanelView550?
Панель подключена как Unscheduled. Процессор - ControLogix, диагностика на RSView.
|
А мне вот Triconex тоже очень понравился.
Хотя ничего плохого о ControlLogix сказать не могу. Им бы еще SCADA хорошую (мечтательно).
|
Приветствую всех!
Интересует вопрос диагностики сетевых соединений устройств, висящих на 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 соответственно. Т.о. базу данных тэгов перелопачивать не надо - ограничиваемся только переименованием узла.
Является ли правильным данный подход, или это можно делать как-то автоматически, или можно системными средствами переименовывать узлы, а не вручную?
Заранее спасибо! :)
|
[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] я уже привёл несколько важных документов.
|
Начну с конца - с траффика 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 возможны тормоза - правильно ли я думаю?
|
Было такое пару раз, на Contrologix 5555 с прошивкой 10-ой версии, при выключении питания стиралась программа (не всегда), несмотря на исправную батарейку. После смены прошивки пропало.
|
Предыдущие результаты
Ещё результаты |
|
| |
|
