 | |
Предыдущие результаты
 [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 возможны тормоза - правильно ли я думаю?
|
Здравствуйте.
Получили на фирму инсталляционный диск RSLogix 500, и, на том же диске, в дистрибутиве - RSView32. Но в главном меню диска, в пункте "Try out other Rockwell software products" RSView32 обозначена как demonstration version . Можно ли использовать, при наличии ключей активации от наших ранний версий, эту инсталляцию как полноценный SCADA пакет или она всё таки является урезанной демо версией пром.образца ?
|
RSNetworx for Ethrenet/IP входит в Logix 5000 Professional, однозначно.
|
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]
|
Получите Вы вот что:
http://www.software.rockwell.com/rslogix/order.cfm
KEPServer - это ОРС-сервер для не-Алленбрэдлевских устройств:
http://www.kepware.com/Products/products_OPCServers.html
|
>Где бы узнать, что конкретно поставляеться по заказному номеру? >Какие диски, лицензии, документация? Интересует, что мы получим, >заказав, скажем, RSlogix 5000 Professional 9324-RLD700NXENE.
Есть документ 1756-sg0001f-en-p.pdf, типа Selection Guide для выбора всего по 56-ой серии, в том числе и по программному обеспечению. Там все написано, что входит в состав указанного каталожного номера Logix 5000. На самом деле, много всего включает, куча компактов в коробке (по-моему 10 штук).
Версия документа может есть уже и более свежая.
|
Где бы узнать, что конкретно поставляеться по заказному номеру? Какие диски, лицензии, документация? Интересует, что мы получим, заказав, скажем, RSlogix 5000 Professional 9324-RLD700NXENE.
И еще вопрос (лень начинать новую тему :) ):
Что за продукт: 9301-OPCSRVENE KEP Server Enterprise ?
Разве RSLinx Enterprise, входящий в поставку RSViewSE, не позволяет подключаться через OPC к контроллерам других фирм?
И входит ли RSlinx Gateway (9355-WABGWENE) в состав RSLinx Enterprise?
|
Было такое пару раз, на Contrologix 5555 с прошивкой 10-ой версии, при выключении питания стиралась программа (не всегда), несмотря на исправную батарейку. После смены прошивки пропало.
|
Предыдущие результаты
Ещё результаты |
|
| |
|
