Добавлено: Ср 03 Апр, 2013 15:13:11 Заголовок сообщения: Configure the Produced Tag и ограничения на multicast connec
Здравствуйте!
У меня есть сеть из 5 контроллеров L32E и панели оператора.
4 из них выступают в роли Slave, там сконфигурирован 21 produced тег в виде структуры, где-то по 128 байт на тег и 1 consumed тег на 128байт.
1 контроллер выступает в роли Main, который собирает данные со Slave.
В документе ENET-UM001 написано что у всех модулей есть ограничения в 32 мультикаст соединения на контроллер, при этом каждый produced тег забирает по 1 соединению (стр.69), и там же ниже приводится пример где передается 125 тегов от одного контроллера к другому, что противоречит выше сказанному.
Так же скачал программу "EtherNet/IP Capacity Tool" где можно сконфигурировать и проверить сетевой обмен. По этой программе также выходит, что я не вписываюсь с таким объемом тегов.
Меня еще вводит в смущение следующие, а как же панель оператора считывает с контроллера много тегов и не попадает под ограничение соединений.
Если я действительно попадаю под данное ограничение по передачи данных, можно ли как-то решить мою проблему?
Соединения занимают не тэги, а само продюссирование.
т.е. 1 продюссер - 1 соединение и не важно это один тэг, массив или структура.
Дальше действует ограничение на размер продюссера - он должен вписываться в один SIP-пакет (это около 500 байт).
Давайте пойдем от обратного.
Система работает. Описание, как правило, редко обманывает, даже переводная (но чаще чем оригинал на English). Следовательно, необходимо анализировать Ваши проекты БЕЗ ваших комментариев к ним - привозите, присылайте , будем поглядеть :о)). Возможно Вы что то не учитываете, или еще не все руководства прочитали ... и тд.
ps Все возможно, просто это все требует осмысления ... (с)
Попробую сформулировать вопрос по другому.
У меня есть 4 контроллера, которые производят 21(где-то на 2 килобайта) тег каждый, итого 4 килобайта данных.
Сможет ли все эти теги забрать 5ый контроллер, не упрусь ли я в какие-нибудь ограничения?
У меня есть сеть из 5 контроллеров L32E и панели оператора.
4 из них выступают в роли Slave, там сконфигурирован 21 produced тег в виде структуры, где-то по 128 байт на тег и 1 consumed тег на 128байт.
1 контроллер выступает в роли Main, который собирает данные со Slave.
4 контроллера требуют по 21+1 Connections из 32.
1 контроллер требует 21+1*4 Connections из 32.
Панель оператора использует Connections к каждому контроллеру.
Какая панель? Как настраивал связь scheduled или unscheduled, если PanelView Plus?
RSLogix 5000, вернее RSLinx, также использует Connections (по умолчанию 4).
Команды MSG - также используют Connections.
RSLogix 5000 Online Help писал(а):
Important: Producing a tag requires a connection for each consumer. Connections are a limited resource in the controller
Переделай свою структуру для 21 prodused tag со 128 байт на большее число байт (ориентир 500 байт), первым членом структуры поставь переменную предопределенной структуры CONNECTION_STATUS (много пользы принесет), правильно группируй типы данных.
Далее:
Liter писал(а):
...Следовательно, необходимо анализировать Ваши проекты БЕЗ ваших комментариев к ним - привозите, присылайте , будем поглядеть...
4 контроллера требуют по 21+1 Connections из 32.
1 контроллер требует 21+1*4 Connections из 32.
Вношу поправку в расчет для main_plc
8 Prodused + 84 (21*4) Consumed = 92 (явный перебор).
slave_plc:
21 Prodused, 0 Consumed.
Для кого 8 Prodused в main_plc?
Советов пока нет, разве, что Main сменить на 1756-L7*.
Придется копнуть программы (вернее данные для обмена) в глубину, что-то мне шепчет про неправильный подход.
Какие модули стоят в слотах 1, 2, 3?
У меня не определились - надо будет подтянуть нужные AOP.
4 контроллера требуют по 21+1 Connections из 32.
1 контроллер требует 21+1*4 Connections из 32.
Вношу поправку в расчет для main_plc
8 Prodused + 84 (21*4) Consumed = 92 (явный перебор).
slave_plc:
21 Prodused, 0 Consumed.
Для кого 8 Prodused в main_plc?
Советов пока нет, разве, что Main сменить на 1756-L7*.
Придется копнуть программы (вернее данные для обмена) в глубину, что-то мне шепчет про неправильный подход.
Какие модули стоят в слотах 1, 2, 3?
У меня не определились - надо будет подтянуть нужные AOP.
4 из этих 8 Produced будут забирать slave_plc (по 1 штуке на PLC), забыл привязать, а оставшиеся 4 штуки еще под вопросом, скорее всего исчезнут.
Контроллер сменить не могу, оборудование уже закуплено и собрано, проект собирался давно, тогда еще опыта работы с контроллерами Rockwell было мало, поэтому момент с передачей данных между PLC был упущен.
В 1,2 слотах стоят 1769sc-IF4IH, в 3 слоте MVI69.
Значит единственный вариант это переделать Produced теги похоже...
Просто панелька же как то считывает много тегов использую всего 5 Connections, я тогда думал что и обмен можно организовать на большое число тегов.
1. Советов пока нет, разве, что Main сменить на 1756-L7*.
....
2. Придется копнуть программы (вернее данные для обмена) в глубину, что-то мне шепчет про неправильный подход.
1. А почему L7х ... а если в среде Compact поискать ?
2. Счас оч.занят , но совершенно такая же мысль посетила :о))
ps
3. Есть вопрос по коммуникации - у Вас EtherNet/IP какую архитектуру имеет ? Какое оборудование ? Такие объемы данных перекачивать
1. Советов пока нет, разве, что Main сменить на 1756-L7*.
....
2. Придется копнуть программы (вернее данные для обмена) в глубину, что-то мне шепчет про неправильный подход.
1. А почему L7х ... а если в среде Compact поискать ?
2. Счас оч.занят , но совершенно такая же мысль посетила :о))
ps
3. Есть вопрос по коммуникации - у Вас EtherNet/IP какую архитектуру имеет ? Какое оборудование ? Такие объемы данных перекачивать
1. Замена контроллера отпадает, т.к. оборудование уже закуплено.
2. Можете копнуть...
3. Не совсем понял вопрос про архитектуру? Полные список оборудования:
- 5 PLC L32E объеденных в сеть по Ethernet, один из них главный собирает данные с остальных PLC;
- 1 HMI PanelView Plus в той же сети Ethernet, опрашивает все 5 PLC;
- АРМ оператора на SCADA InTouch'е, которая по Modbus RTU забирает данные с головного контроллера;
Т.к. наша фирма с Rockwell работать начала относительно недавно, то я всех тонкостей еще не знаю, но в сравнении с другими PLC с которыми мы работали, я бы не назвал этот объем данных таким уж и большим. Я думаю тут проблема скорее в том как я построил передачу данных.
У вас топология сети какая ? Объединяется все в свитчике ? .... Чьих будет свитчик ? ... и далее - вот что имелось ввиду.
И вопрос еще - передача информации обязательно привязывать ко времени ? ... может быть часть перебросить на не запланированную часть .. т.е. использовать инструкции MSG - коннекты поэкономить :о))
...
ps Извини - в офисе набегами :о()
Выход - уменьшать кол-во конекшинов. MSG на мой взгляд тоже вам не помогут.
Если лень оптимизировать передаваемые данные, тогда можно сделать так.
В слайвах оставить по одному Produced Тегу
этот тег должен быть струкурой примерно такого вида:
TagID INT идентификатор вашей структуры
ConnArray SINT[480]
sizeInByte INT
На стороне слайва в этот тег записывать поочереди Ваши структуры с помощью инструкций COP или CPS
cop(discrete_01_di_fb,ConnArraySINT[0],1);
на сторне майна востанавливать структуру из массива
cop(ConnArray[0],discrete_01_di_fb,sizeInBytet);
инструкции COP и CPS копируют данные по байтно, и не проверяют типы данных источника и получателя. Главное за границы массива и структуры не выходить, иначе получите MainFault
TagID и sizeInByte надеюсь что самосабой понятно зачем нужны.
А вообще для в следующий раз не используете продьюс/консьюмер связь для передачи данных на HMI, они для этого не предназначены. Этот тип связи используется для обмена управляющей информации, критической по времени. Система гарантирует доставку данных за RPI, т.е. время реакции контроллера на данные полученые из другого контроллера всегда известна.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
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.141 секунды
FAQ
Поиск
Группы
Профиль
Войти и проверить личные сообщения
Вход
