 | |
Предыдущие результаты
 [url=http://vdt-solutions.de/files/kb27160.pdf]Пожалуйста[/url].
|
У кого есть соответсвующий уровень доступа к технической информации на сайте Rockwell Automation Support Center
не могли бы вы опубликовать содержание статьи
https://rockwellautomation.custhelp.com/app/answers/detail/a_id/27160
|
[quote:a612ebcf6a="Liter"]У вас топология сети какая ? Объединяется все в свитчике ? .... Чьих будет свитчик ? ... и далее - вот что имелось ввиду.
И вопрос еще - передача информации обязательно привязывать ко времени ? ... может быть часть перебросить на не запланированную часть .. т.е. использовать инструкции MSG - коннекты поэкономить :о))
...
ps Извини - в офисе набегами :о()[/quote:a612ebcf6a]
Свитч будет от Moxa, там ничего навороченного, обычная железка.
По времени жестко привязаны должны быть только пара тегов. В данным случае мне все же придется перегруппировать данные, убрать менее важные параметры, оставить только самое необходимое, это будет самый менее болезненный вариант.
[quote:a612ebcf6a="avgaid"]Выход - уменьшать кол-во конекшинов. 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, т.е. время реакции контроллера на данные полученые из другого контроллера всегда известна.[/quote:a612ebcf6a]
Я тоже думал о таком варианте, но решил его оставить на крайний случай. Про гарантированную доставку времени я понял с самого начала. Просто меня в документации смутил пример в котором 2 контроллера обмениваются данными, при этом юзают 125 коннекшенов при ограничении в 32.
Всем спасибо за помощь, буду уменьшать объем передаваемых данных, это будет пока что менее болезненный вариант. Если заказчика не устроит такое количество данных, то буду использовать вариант предложенный avgaid.
|
Выход - уменьшать кол-во конекшинов. 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, т.е. время реакции контроллера на данные полученые из другого контроллера всегда известна.
|
У вас топология сети какая ? Объединяется все в свитчике ? .... Чьих будет свитчик ? ... и далее - вот что имелось ввиду.
И вопрос еще - передача информации обязательно привязывать ко времени ? ... может быть часть перебросить на не запланированную часть .. т.е. использовать инструкции MSG - коннекты поэкономить :о))
...
ps Извини - в офисе набегами :о()
|
[quote:d2b9004bbd="Liter"][quote:d2b9004bbd="dv"]
1. Советов пока нет, разве, что Main сменить на 1756-L7*.
....
2. Придется копнуть программы (вернее данные для обмена) в глубину, что-то мне шепчет про неправильный подход.
[/quote:d2b9004bbd]
1. А почему L7х ... а если в среде Compact поискать ?
2. Счас оч.занят , но совершенно такая же мысль посетила :о))
ps
3. Есть вопрос по коммуникации - у Вас EtherNet/IP какую архитектуру имеет ? Какое оборудование ? Такие объемы данных перекачивать 8O[/quote:d2b9004bbd]
1. Замена контроллера отпадает, т.к. оборудование уже закуплено.
2. Можете копнуть...
3. Не совсем понял вопрос про архитектуру? Полные список оборудования:
- 5 PLC L32E объеденных в сеть по Ethernet, один из них главный собирает данные с остальных PLC;
- 1 HMI PanelView Plus в той же сети Ethernet, опрашивает все 5 PLC;
- АРМ оператора на SCADA InTouch'е, которая по Modbus RTU забирает данные с головного контроллера;
Т.к. наша фирма с Rockwell работать начала относительно недавно, то я всех тонкостей еще не знаю, но в сравнении с другими PLC с которыми мы работали, я бы не назвал этот объем данных таким уж и большим. Я думаю тут проблема скорее в том как я построил передачу данных.
|
[quote:82fd940655="dv"]
1. Советов пока нет, разве, что Main сменить на 1756-L7*.
....
2. Придется копнуть программы (вернее данные для обмена) в глубину, что-то мне шепчет про неправильный подход.
[/quote:82fd940655]
1. А почему L7х ... а если в среде Compact поискать ?
2. Счас оч.занят , но совершенно такая же мысль посетила :о))
ps
3. Есть вопрос по коммуникации - у Вас EtherNet/IP какую архитектуру имеет ? Какое оборудование ? Такие объемы данных перекачивать 8O
|
[quote:c3c0feb9c8="dv_"][quote:c3c0feb9c8="dv_"]4 контроллера требуют по 21+1 Connections из 32.
1 контроллер требует 21+1*4 Connections из 32.[/quote:c3c0feb9c8]
Вношу поправку в расчет для [b:c3c0feb9c8]main_plc[/b:c3c0feb9c8]
8 Prodused + 84 (21*4) Consumed = 92 (явный перебор).
[b:c3c0feb9c8]slave_plc[/b:c3c0feb9c8]:
21 Prodused, 0 Consumed.
Для кого 8 Prodused в [b:c3c0feb9c8]main_plc[/b:c3c0feb9c8]?
Советов пока нет, разве, что Main сменить на 1756-L7*.
Придется копнуть программы (вернее данные для обмена) в глубину, что-то мне шепчет про неправильный подход.
Какие модули стоят в слотах 1, 2, 3?
У меня не определились - надо будет [i:c3c0feb9c8]подтянуть [/i:c3c0feb9c8]нужные AOP.[/quote:c3c0feb9c8]
4 из этих 8 Produced будут забирать slave_plc (по 1 штуке на PLC), забыл привязать, а оставшиеся 4 штуки еще под вопросом, скорее всего исчезнут.
Контроллер сменить не могу, оборудование уже закуплено и собрано, проект собирался давно, тогда еще опыта работы с контроллерами Rockwell было мало, поэтому момент с передачей данных между PLC был упущен.
В 1,2 слотах стоят 1769sc-IF4IH, в 3 слоте MVI69.
Значит единственный вариант это переделать Produced теги похоже...
Просто панелька же как то считывает много тегов использую всего 5 Connections, я тогда думал что и обмен можно организовать на большое число тегов.
|
[quote:0eff01ac30="dv_"]4 контроллера требуют по 21+1 Connections из 32.
1 контроллер требует 21+1*4 Connections из 32.[/quote:0eff01ac30]
Вношу поправку в расчет для [b:0eff01ac30]main_plc[/b:0eff01ac30]
8 Prodused + 84 (21*4) Consumed = 92 (явный перебор).
[b:0eff01ac30]slave_plc[/b:0eff01ac30]:
21 Prodused, 0 Consumed.
Для кого 8 Prodused в [b:0eff01ac30]main_plc[/b:0eff01ac30]?
Советов пока нет, разве, что Main сменить на 1756-L7*.
Придется копнуть программы (вернее данные для обмена) в глубину, что-то мне шепчет про неправильный подход.
Какие модули стоят в слотах 1, 2, 3?
У меня не определились - надо будет [i:0eff01ac30]подтянуть [/i:0eff01ac30]нужные AOP.
|
Новая)Данные пишутся-читаются с нее без проблем)Кстати,вопрос может для Вас показаться смешным,но с Роквелом дела раньше не имел.Само понятие прошивка-это восстановление ОС(в моем случае Windows CE) или только восстановление утилит для запуска файла проекта .mer?
|
Предыдущие результаты
Ещё результаты |
|
| |
|
