Вход на форум 
В начало e-Mail

Форум

Ресурсы Rockwell

Product Directory

Essential Components

Literature Library

Knowledge Base

Electronic News&Magazines

Блог

Encompass Program

Product Certification

  


Предыдущие результаты



Предыдущие результаты



Предыдущие результаты

 Даниил, [u:fa7c6fc373][color=darkblue:fa7c6fc373][url=http://vdt-solutions.de/files/linx_gateway.pdf]в этом файле[/url][/color:fa7c6fc373][/u:fa7c6fc373] описывается, как настраивать RSLinx Gateway. Там локальная машина связана с контроллером не по ControlNet, а по DataHighway+, но, думаю, разберётесь по аналогии. Успехов! Расскажите потом pls, получилось ли.

 Здравствуйте! Имеется следующее соединение: PLC <-----ControlNet-----> WS1 <-----Ethernet-----> WS2 На WS1 стоит RSLinx Gateway, на WS2 - RSLinx Professional. Я не могу настроить соединение на WS2 :oops: Может быть кто-то знает как это сделать, если в таком варианте это вообще возможно? Где можно взять подробную документацию по RSLinx (желательно на русском)? Спасибо за внимание!

 Хороший вопрос :) Сейчас попробую привести несколько общих соображений и рекомендаций. Основное правило планирования вычислительной мощности мультизадачных проектов реального времени звучит так: „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. При планировании Вашей системы пожалуйста не пренебрегайте всеми рекомендациями документа [url=http://literature.rockwellautomation.com/idc/groups/literature/documents/um/1756-um523_-en-p.pdf]1756-um523_-en-p.pdf[/url]. Настройки 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? Успехов! :)

 Хотел спросить совета у опытных спецов. Вопросов, по сути несколько, но прежде чем их задать в общих чертах опишу ситуацию. Два контроллера L55M13 работающих в горячем резерве при помощи 1757-SRM. Сеть ControlNet, ввод/вывод удаленный, 3 17-х шасси, в каждой 15 модулей. Как оказалось синхронизация основного и резервного контроллеров занимает довольно прилично ресурсы оных. По мануалу загрузка вроде как должна быть больше всего на 30%, но на мой субъективный взгляд на практике дело обстоит по другому. Тормоза у меня выражаются в подвисании RSLinx, диагностика драйвера показывает 2 пакета в секунду на прием и столько же на передачу. В режиме работы без резервного контроллера, диагностика показывает 10 пакетов, RSView работает, как положено, тормозов не наблюдается. Теперь собственно вопросы. 1. Как лучше организовать задачи контроллера. Сделать больше задач содержащих меньше программ, или постараться выстроить процедуры управления так, чтобы задач было меньше, а программ внутри них больше. Вообще, что-нибудь от этого зависит или я не туда копаю? 2. Какие вообще есть способы оптимизации быстродействия? 3. Может дело быть в неправильных настройках ControlNet-а? 4. Сколько пакетов должна получать/отправлять рабочая станция для "нормального" обмена информацией по контролнету? Сетевые модули нагружены на 50% если судить по показаниям индикаторов.

 Здравствуйте! Ответ на Ваш вопрос зависит от того, как много информации Вы собираетесь передавать по сети ControlNet и как часто. Не могли бы Вы более подробно рассказать о структуре системы? Как я понимаю, Вы хотите замкнуть контур положения через контроллер ControlLogix, а абсолютный датчик положения "повесить" на ControlNet? Какая мощность двигателя? Какой привод? Как он общается с контроллером? Какова разрешающпая способность датчика? Сколько импульсов на миллиметр? Какова максимальная скорость изменения кода датчика? На сколько импульсов датчика изменяется код в секунду?

 [quote:aecc895a6e="oldDad"]Alex, этот человек в командировке. Пока что давайте выясним следующее: Давайте-ка сюда в студию следующие данные: 1. Что работает на клиентском компьютере - RSViewME? Клиент RSVIewSE ? 2. Какой клиентский компьютер ? Это PanelView Plus? VersaView под Windows 2K/XP? VersaView под WindowsCE? Другой РС под Windows 2K/XP? 3. Какой сетью этот компьютер связан с контроллером? ControlNet? Ethernet/IP/ DF1? RS-232? Другие сети? Пожалуйста уточните. Пока что, на всякий случай, почитайте вот здесь: [color=blue:aecc895a6e][u:aecc895a6e][url=http://domino.automation.rockwell.com/applications%5Ckb%5CRAKB.nsf/0/BCAFB440E2BB197185256D11006CCDFB?OpenDocument] Q43456884[/url][/color:aecc895a6e] [/u:aecc895a6e]Может быть это как раз Ваш случай?[/quote:aecc895a6e] 1. На компьютере RsView ME. 2. Это PanelView Plus 400 и 600. 3. Ethernet. Случай не мой. Данную проблему я бы решил с помошью CompactFlash. У меня проблема в параметрировании истинного пути RSlinx от панели к контроллеру в офлайне и подключении файлов из проекта контроллера.

 Alex, этот человек в командировке. Пока что давайте выясним следующее: Давайте-ка сюда в студию следующие данные: 1. Что работает на клиентском компьютере - RSViewME? Клиент RSVIewSE ? 2. Какой клиентский компьютер ? Это PanelView Plus? VersaView под Windows 2K/XP? VersaView под WindowsCE? Другой РС под Windows 2K/XP? 3. Какой сетью этот компьютер связан с контроллером? ControlNet? Ethernet/IP/ DF1? RS-232? Другие сети? Пожалуйста уточните. Пока что, на всякий случай, почитайте вот здесь: [color=blue:40986c2a8b][u:40986c2a8b][url=http://domino.automation.rockwell.com/applications%5Ckb%5CRAKB.nsf/0/BCAFB440E2BB197185256D11006CCDFB?OpenDocument] Q43456884[/url][/color:40986c2a8b] [/u:40986c2a8b]Может быть это как раз Ваш случай?

 К DriveLogix можно подключать локальные модули FlexI/O. Кроме того, с помощью коммуникационных карт поддерживаются DeviceNet, ControlNet and EtherNet/IP, так что можно работать с любыми удалёнными модулями, подключенными с помощью адаптеров этих сетей. DriveLogix поддерживает до 8 задач (1 фоновую + 7 периодических). Объём памяти: 1.5Mb и слот CompactFlash для энергонезависимого хранения. Дальнейшая информация здесь: http://www.ab.com/drives/powerflex/700s/drivelogix.html



Предыдущие результаты



Предыдущие результаты



Предыдущие результаты



Предыдущие результаты



Предыдущие результаты




  
RA & VDT GmbH


Облако тэгов
Automation Fatal Error RSLogix ControlLogix sound FTView Control Logix MVI56-104S 1734-AENTR Altivar Add-on Instruction MVI46MCM Ethernet PLC-5 SLC-500 1757-SRM Firmware ComactLogixL32E 1756-L75 1756-RM2 Controlnet cable Promass Client Memory 1769-L32E execution minutes seconds Windows Build 00000d5c Unspecified terminate geehrter automatisch

Яндекс цитирования

Smart Solutions VDT GmbH | Friedrich-List-Allee 38, D-41844 Wegberg-Wildenrath, Germany
Tel.: +49 2432 933 57 83 | e-Mail: office@vdt-solutions.de
Все товарные знаки и торговые марки являются собственностью их владельцев.
При использовании материалов сайта ссылка на данный сайт обязательна.
Открытие страницы: 0.167 секунды