Оптимизация проекта для ControlLogix

[KPY]

Хотел спросить совета у опытных спецов. Вопросов, по сути несколько, но прежде чем их задать в общих чертах опишу ситуацию. Два контроллера L55M13 работающих в горячем резерве при помощи 1757-SRM. Сеть ControlNet, ввод/вывод удаленный, 3 17-х шасси, в каждой 15 модулей. Как оказалось синхронизация основного и резервного контроллеров занимает довольно прилично ресурсы оных.

По мануалу загрузка вроде как должна быть больше всего на 30%, но на мой субъективный взгляд на практике дело обстоит по другому. Тормоза у меня выражаются в подвисании RSLinx, диагностика драйвера показывает 2 пакета в секунду на прием и столько же на передачу. В режиме работы без резервного контроллера, диагностика показывает 10 пакетов, RSView работает, как положено, тормозов не наблюдается.

Теперь собственно вопросы.
1. Как лучше организовать задачи контроллера. Сделать больше задач содержащих меньше программ, или постараться выстроить процедуры управления так, чтобы задач было меньше, а программ внутри них больше. Вообще, что-нибудь от этого зависит или я не туда копаю?
2. Какие вообще есть способы оптимизации быстродействия?
3. Может дело быть в неправильных настройках ControlNet-а?
4. Сколько пакетов должна получать/отправлять рабочая станция для "нормального" обмена информацией по контролнету? Сетевые модули нагружены на 50% если судить по показаниям индикаторов.

[oldDad]

Хороший вопрос Сейчас попробую привести несколько общих соображений и рекомендаций.

Основное правило планирования вычислительной мощности мультизадачных проектов реального времени звучит так: „Don’t hog the CPU“, что означает «не заграбастывайте время процессора» Поэтому, чтобы минимизировать время скана, следует, в принципе, придерживаться следующих соображений:

1. Лучше использовать небольшое количество больших программ, чем большое количество маленьких. Чем больше задач, тем больше «накладных расходов», т.е. вычислительных ресурсов, требующихся процессору и операционной системе, чтобы отслеживать переключение задач, сохранения контекста, определения наиболее приоритетной готовой к выполнению задачи, сохранению контекста в стеки задачи, у которой система забирает процессор и т.п.

2. Если возможно, используйте только одну или как можно меньше задач.

3. Лучше использовать одну программу с вызовами подпрограмм (routines) чем несколько автономных задач со своими приоритетами, локальной областью данных и т.п.

4. Если Вам необходимо иметь в системе несколько задач с собственными приоритетами, то в каждой задаче лучше иметь только одну программу или пару программ.

5. Лучше применять «оборонительный» стиль планирования приоритетов и вычислительного процесса, чем «наступательный», т.е. присваивать задаче настолько маленький приоритет, насколько это возможно и имеет смысл, а не назначать каждой новой задаче (ещё) больший приоритет, чем предыдущей.

6. Старайтесь следовать следующей стратегии: задачи с относительно более высоким приоритетом должны обслуживать самые важные события во внешней среде, и быть настолько короткими, насколько это возможно. Чем выше приоритет, тем короче, лаконичнее и проще должна быть задача.

7. Поскольку резервированные процессоры постоянно заняты ещё и сравнением и выравниванием контекста, и это происходит с довольно высоким приоритетам (по вполне понятной причине – нужно постоянно быть наготове!) , очень критичным является время передачи массива данных (тэгов). Поэтому структурируйте данные так, чтобы иметь наименьшее количество тэгов. Это позволит уменьшить объём данных, передаваемых между основным и резервирующим процессором, а, следовательно, уменьшить время трансфера данных между контроллерами и увеличить быстродействие.

8. Удаляйте ненужные тэги. Поскольку они созданы, память под них отписана, и они участвуют в трансфере, т,к. Процессор не анализирует, используются ли они в действительности.

9. По этим же соображениям лучше использовать массивы тэгов вместо ряда индивидуальных тэгов. Каждый раз, когда Вы создаёте тэг BOOL, контроллер создаёт 4-байтовую структуру данных вместо 1 бита. Например, массив BOOL из 32 битов занимает 32 бита, т.е. 4 байта, а 3 независимых тэга типа BOOL занимают 3 тэга x 4 байта/тэг = 12 байт.

10. Старайтесь использовать биты в слове, а не отдельные битовые тэги. Если Вам необходимы тэги различного типа, то лучше создавать польовательские структуры данных, состоящие из тэгов и массивов разных типов, чем просто большое количество тэгов. Напирмер, структура может состоять из тэгов SINT, INT, DINT, REAL, COUNTER, TIMER. Менеджер памяти оптимизирует такие структуры, макчимально упаковывая данные вплотную друг к другу.

11. Если уж Вы создаёте единичные тэги, то лучше создавайте альянсы (aliases) к компонентам массивов.

12. Минимизируйте код программы, насколько это возможно. Если по какому-нибудь условия выполняются различные действия, то избегайте множественных проверок этого условия в разных строках программы, а лучше для всех этих действий используйте ветвление во второй половине строки проверки учловия.

13. По этой же причине минимизируйте применение конструкций вида «проверил условие – установил флажок – во многих местах пользуюсь этим флажком». Лучше избегать флажков и помещать инструкции выполнения впараллель в строчке проверки условия непосредственно после проверки этого условия.

14. Не выполняйте строчки программы, если это не нужно. Выполняйте действия только тогда, когда это действительно необходимо. Например, выполнение сложения после проверки необходимости сложения лучше, чем безусловное выполнение сложения без проверки этого условия.

15. При передаче данных между партнёрами-контроллерами данные делятся на пакеты по 256 байт. Каждый раз, когда производится запись, скажем, в 1 (один) бит, т.е. тэг типа BOOL, между контроллерами передаётся целый блок из 256 байт. Поэтому лучше осмысленно группировать данные таким образом, чтобы передавалось только то, что нужно, а не, например, одни и те же константы в одном и том же блоке. Иными словами, лучше располагать константы в одном блоке, медленно меняющиеся значения в другом, быстроменяющиеся – в третьем и т.п. в этом смысле.

16. Лучше использовать DINT, чем SINT или INT. Поскольку контроллер имеет 32-битную шину данных, его естественным форматом является именно DINT. Все остальные Ваши форматы контроллер вынужден перед использованием сперва преобразовывать в DINT, а потом снова в Ваш формат. Это занимает время.

17. Не нужно явно в программе преобразовывать SINT или INT в DINT. Контроллер делает это автоматически. В противном случае это занимает лишнее время.

18. При планировании Вашей системы пожалуйста не пренебрегайте всеми рекомендациями документа 1756-um523_-en-p.pdf.


Настройки ControlNet тоже нужно оптимизировать с помощью RSNetworx for ControlNet.
- Можно поварьировать NUT.
- Очень часто недостаточная производительность сети связана с некачественным механическим её исполнением, например, нехорошим контактом в разъёме. Посмотрите в Station Diagnostics в RSLinx, нет ли плохих пакетов, "шума", ошибок?
- Лучше располагать адреса в сети подряд, без промежутков.
- Хорошо бы проверить в RSNetworx, корректно ли указаны максимальные сетевые адреса Max Scheduled и Max Unscheduled.
- Если у Вас резервированная сеть, проверьте, установлено ли в Media Redundancy, что передача идёт по кабелям А и В.
- Посмотрите, сколько реально байтов в секунду пропускает Ваша сеть в фазе unscheduled. Не получается ли так, что NUT слишком мал, чтобы пропустить все байты за один такт? Не слишком ли велик бесполезный запас?
- Посмотрите характер загрузки сети: Average and Peak Scheduled Band Network. Чем ближе эти значения к 100%, тем тяжелее загружена сеть.


Сколько у Вас рабочих станций в данном сегменте ControlNet? Что Вы используете - RSView32 или RSViewSE?

Успехов!
_________________
Обращайтесь к профессионалам.

[KPY]

oldDad
Спасибо большое за столь объемный, содержательный и полезный ответ! Перевариваю полученную информацию. К сожалению пока на практике проверить не могу, но обещаю как только окончатся праздники проверить все Ваши гипотезы. Обязательно отчитаюсь о результатах.
Еще раз огромное спасибо!

Р.S. Рабочих станции 3, используем RSView32.

[KPY]

Постарался исправить проект в соответствии с Вашими замечаниями и рекомендациями указанного Вами документа. Все у меня заработало, но я рано радовался. Появились новые непонятки, я уже голову сломал, поэтому обращаюсь к Вам как к высшей инстанции. Опишу проблему:
Без резервного контроллера все 3 рабочих станции работают отлично, тормозов не наблюдается. (Тормозами я называю реакцию на кнопку включения конура управления) При включении резервного контроллера, рабочие станции вообще перестают управлять процессом. Нормальной работы удалось добиться только при использовании одной машины, то есть как только я запускаю проект на второй, система встает «колом».
NUT 5мс, при использовании других значений, у меня перестает синхронизироваться резервный контроллер. PRI = 160 для всех шасси, выбирал из условий что у меня NUT будет 10. Не знаю уже что бы и придумать. Куда копать, то ли дальше программу оптимизировать, то ли с ControlNet-oм бороться. Задам еще вопросы, может глупые, не судите строго:
1. Передача данных рабочим станциям идет как незапланированные данные? Таким образом, нельзя гарантировать, что измененное значение тега обязательно в реалтайме будет замечено контроллером? Может можно их, каким-то образом запланировать? В проект Logix-а например добавить.
2. В RSLinx окромя создания драйвера и ОРС-топика еще нужно что-то настраивать?
3. После переконфигурации сети RSNetWorx-ом RSLinx надо перезапускать?
4. Непонятна связь системы резервирования и NUT. ИМХО должно же быть наоборот, чем больше время обновления сети, тем больше времени можно уделить синхронизации.

[oldDad]

Ну, нормальный процесс отладки

Так у Вас резервированный контроллер? С 1757-SRM?

Вот это Вы, безусловно, в точности соблюдвете?

Не зная точной структуры системы, объёма данных и траффика, довольно трудно давать советы по оптимизации, но на вопросы постараюсь ответить.

[KPY]

[oldDad]

[oldDad]

Ну, раз у Вас только 2 рабочие станции, то смысла применять сервер, тем более резервированный, нет.

Если Вы уже оптимизировали расположение тэгов в памяти контроллера, поигрались со скан-классами в RSView32 ("быстрые" тэги часто, но по возможности реже, а "медленные"- настолько редко, насколько вообще возможно) и поигрались с NUT (а если его увелисить до 15? или больще?), и т.д., то "терапия! оказлась неэффективной.

Тогда нужно радикальное решение, "хирургия". Я думаю, что Вам нужно "отцепить" рабочие станции от шины ControlNet и посадить на отдельный сегмент сети (Ethernet достаточно, но можно и ControlNet). А для этого нужно вставить соответствующие модули в каждое из шасси контроллеров.
_________________
Обращайтесь к профессионалам.

[KPY]

[oldDad]

[KPY]

oldDad
Спасибо большое за советы и ссылки, правда я пока обошелся без советов изложенных в данных материалах.

Перетащил все программы в периодическую задачу, получилась каша, но зато "глюки" с тормозами на реакцию нажатия кнопки пропали. Кнопки нажимаются со всех 3х машин и контроллер своевременно отрабатывает нажатие. Вы можете меня покритиковать за то. что мол давно уже мне советовали это сделать, извиняюсь было страшно перелопачивать весь проект с нуля, до последнего момента с глубокой уверенностью считал, что у меня проблемы с ОРС и Контролнетом.

Правда не все так хорошо, одна машина у меня теперь "помаргивает" анимацией завязанной на теги контроллера. Странно как то. Если опять это связанно с малой пропускной способностью канала почему раньше не моргала, когда связи с контроллером совсем не было, а если нет то тогда почему, не пойму

[oldDad]

Я рад, что Вам удалось в основном решить эту задчу. Эти характерные затыки обычно бывают не с ОРС и ControlNet, а с процессором, когда ему не дают достаточно времени на то, чтобы он занимался оптимизацией своей мультизадачности и оптимизацией коммуникаций. Периодическая задача как раз даёт процессору такую возможность, оставляет ему время для занятий собой.

Что касается помаргивания - это, скорее всего, с пропусной способностью канала не связано. Известны аппликации с куда бОльшим траффиком, и там ничего не моргает. Тут нужно проанализировать более детально.

Что именно моргает и как именно построено это отображение? Что откуда и когда приходит?
_________________
Обращайтесь к профессионалам.

[KPY]

[oldDad]

Ну что можно сказать... Оптимизируйте дальше
_________________
Обращайтесь к профессионалам.