 | |
Предыдущие результаты
 Причины вот:
[url=http://domino.automation.rockwell.com/applications%5Ckb%5CRAKB.nsf/0/34DB2B4D8220715B85257116004D29AD?OpenDocument]G146332600 - On the Minor Faults tab in RSLogix 5000 you get a fault Type = 6 Code = 4, this is shown as an unknown fault[/url]
Вот тут ещё можно почитать:
[url=http://domino.automation.rockwell.com/applications%5Ckb%5CRAKB.nsf/0/F9B184C328ED342F85256AFB00706279?OpenDocument]G19983 - Handling Minor Faults in a ControlLogix Processor[/url]
|
[quote:b8c557fdcd="oldDad"]Доменная печь - это агрегат непрерывного действия. Печи работают непрерывно и круглосуточно.[/quote:b8c557fdcd]
Температурный режим поддерживается круглосуточно, а плавка?
Большинство автоматики в перерывах между плавками бездействует ( ну хотя бы на электросталеплавильных печах), разве не так?
[quote:b8c557fdcd]
А вот SFC для непрерывных процессов подходит плохо, я бы сказал, это - вообще не тот язык, который здесь нужен. SFC, как Вы знаете, был разработан впервые для автомобильной промышленности и машиностроения, где объект проходит ряд последовательных технологических операций.[/quote:b8c557fdcd]
Чтобы обеспечить непрерывность осушки сырья и водорода, на нашей установке Изомеризации задействовано две линии осушителей - когда один осушает, второй находится на регенерации. Автоматизация регенерации выполнена именно на SFC, пока еще средствами Plantscape, поэтому и интересен опыт применения SFC на CL.
[quote:b8c557fdcd]
Будут добавлены новые инструкции - ALMD и ALMA - алармы, соответственно, цифровые и аналоговые с LL,L,H,HH, Rate of Change, с опциями Delay Time, Latched or continuous, Automatic acknowledge.
[/quote:b8c557fdcd]
Тогда можно подвести следующие итоги: для автоматизации непрерывных процессов средствами Rockwell на данный момент оптимальным решением станет
- контроллер AB Controllogix,
- ввод-вывод серии 1756 или 1794,
- вторичная обработка сигналов ввода/вывода и реализация логики упрвления на языке FBD,
- генерация алармов на уровне контроллера с помощью инструкций ALM, ALMA и ALMD,
- RSViewSE на уровне управления тех.процессами,
- RSBizWare на уровне управления производством.
[quote:b8c557fdcd]Так за чем дело стало? :) Прошу Вас, чувствуйте себя, как дома, форум - для Вас :)[/quote:b8c557fdcd]
Кто-нибудь пробовал генерировать логику обработки сигналов ввода/вывода и ПИД-регулирования в формате файлов *.L5K?
|
Уважаемые коллеги,
на своем предприятии практически вся автоматизация выполнена с использованием 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-система используется и сколько серверов ввода-вывода в сети?
|
А мне вот Triconex тоже очень понравился.
Хотя ничего плохого о ControlLogix сказать не могу. Им бы еще SCADA хорошую (мечтательно).
|
[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 возможны тормоза - правильно ли я думаю?
|
Сталкивался с подобной проблемой на ControlLogix, но на этапе наладки, поэтому дело темное (слишком много людей занято).
Также сталкивался с подобной проблемой на SLC 5/05 c EtherNet.
Сначала при наладке 3 года назад, потом недавно 3 месяца назад - после 2 лет нормальной работы.
Поставил Flash. :?
Во втором случае шкаф был закрыт и никто ничего не делал =(
Но в целом контроллерами доволен, т.к. за 5 лет понаставил уже штук 50.
Вспомнил, были такие проблемы с FlexLogix, в котором 64 kb памяти. Этот контроллер использует свой процессор и память и для модулей, и для программы, и для сетевого обмена. Если оставить в нем мало свободной памяти (значение не помню), то он больше недели не работает. :evil:
Видимо происходят коллизии при передаче данных, что требует дополнительной памяти и ... память обнуляется.
|
[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-тэгами. Надо что-то делать.
(Я включил пока возможность загрузки картинок на этот сервер, смотрите в меню в разделе "Новая информация" - "Добавить картинку")
|
Предыдущие результаты
Ещё результаты |
|
| |
|
