У вас топология сети какая ? Объединяется все в свитчике ? .... Чьих будет свитчик ? ... и далее - вот что имелось ввиду.
И вопрос еще - передача информации обязательно привязывать ко времени ? ... может быть часть перебросить на не запланированную часть .. т.е. использовать инструкции MSG - коннекты поэкономить :о))
...
ps Извини - в офисе набегами :о()
Свитч будет от Moxa, там ничего навороченного, обычная железка.
По времени жестко привязаны должны быть только пара тегов. В данным случае мне все же придется перегруппировать данные, убрать менее важные параметры, оставить только самое необходимое, это будет самый менее болезненный вариант.
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, т.е. время реакции контроллера на данные полученые из другого контроллера всегда известна.
Я тоже думал о таком варианте, но решил его оставить на крайний случай. Про гарантированную доставку времени я понял с самого начала. Просто меня в документации смутил пример в котором 2 контроллера обмениваются данными, при этом юзают 125 коннекшенов при ограничении в 32.
Всем спасибо за помощь, буду уменьшать объем передаваемых данных, это будет пока что менее болезненный вариант. Если заказчика не устроит такое количество данных, то буду использовать вариант предложенный avgaid.
1. Мне все равно кажется, что Вы путаете понятия коннекшн и объем передаваемого тэга (продюсер - консьюмера).
2. Еще раз настойчиво рекомендую взглянуть на MSG.
3. А вот Moxa Вам может и подложить .... камень за пазуху :о() с мультикастами то
4. А почему собственно мультикаст а не unicast в продюсерах - консьюмерах ? ... это что то пропустил я ...
Всем спасибо за помощь, буду уменьшать объем передаваемых данных, это будет пока что менее болезненный вариант.
Это правильно!
Зачем нужны в Main данные:
- discrete_01_di_hmi
- discrete_01_do_hmi
- ac_fr_hmi
- т.д.
В частности:
- discrete_01_di_hmi.cfg_delay_time_pos_arr
- discrete_01_di_hmi.cfg_delay_time_neg_arr
- ac_fr_hmi.in_x1
- ac_fr_hmi.in_x2
- ac_fr_hmi.in_y1
- ac_fr_hmi.in_y2
- и т.д. (много)
Убейте, но не понимаю их "нужности" в Main. Какие действия Main на основании этих данных?
Почти как:
Никита (http://asutpforum.ru) писал(а):
Опыт - это когда на смену вопросам: "Что? Где? Когда? Как? Почему?" приходит единственный вопрос: "Нахрена?"
clinklion писал(а):
Если заказчика не устроит такое количество данных ...
Всем спасибо за помощь, буду уменьшать объем передаваемых данных, это будет пока что менее болезненный вариант.
Это правильно!
Зачем нужны в Main данные:
- discrete_01_di_hmi
- discrete_01_do_hmi
- ac_fr_hmi
- т.д.
В частности:
- discrete_01_di_hmi.cfg_delay_time_pos_arr
- discrete_01_di_hmi.cfg_delay_time_neg_arr
- ac_fr_hmi.in_x1
- ac_fr_hmi.in_x2
- ac_fr_hmi.in_y1
- ac_fr_hmi.in_y2
- и т.д. (много)
Убейте, но не понимаю их "нужности" в Main. Какие действия Main на основании этих данных?
Почти как:
Никита (http://asutpforum.ru) писал(а):
Опыт - это когда на смену вопросам: "Что? Где? Когда? Как? Почему?" приходит единственный вопрос: "Нахрена?"
clinklion писал(а):
Если заказчика не устроит такое количество данных ...
Будь убедительнее
Это все настроечные данные, в случае если необходимо будет посмотреть/подкорректировать что-то с АРМ оператора
А вообще для в следующий раз не используете продьюс/консьюмер связь для передачи данных на HMI, они для этого не предназначены. Этот тип связи используется для обмена управляющей информации, критической по времени. Система гарантирует доставку данных за RPI, т.е. время реакции контроллера на данные полученые из другого контроллера всегда известна.
У него Scheduled для PanelViewPlus отсутствует (нет в дереве устройств проекта контроллера).
1. Мне все равно кажется, что Вы путаете понятия коннекшн и объем передаваемого тэга (продюсер - консьюмера).
2. Еще раз настойчиво рекомендую взглянуть на MSG.
3. А вот Moxa Вам может и подложить .... камень за пазуху :о() с мультикастами то
4. А почему собственно мультикаст а не unicast в продюсерах - консьюмерах ? ... это что то пропустил я ...
1. Не путаю, я в итоге решил сделать так, избавиться от кучи настроечных данных, создать 1-3 новых produced тега и перекидать туда только технологические параметра, в итоге выйдет 1-3 жирных produced тега, т.о. я съекономлю на коннекшенах.
2. Взгляну обязательно.
3. В чем может быть засада?
4. Вроде везде стоит настройка "Unicast connection - Yes", я так понимаю это никак не multicast настроен.
А вообще для в следующий раз не используете продьюс/консьюмер связь для передачи данных на HMI, они для этого не предназначены. Этот тип связи используется для обмена управляющей информации, критической по времени. Система гарантирует доставку данных за RPI, т.е. время реакции контроллера на данные полученые из другого контроллера всегда известна.
У него Scheduled для PanelViewPlus отсутствует (нет в дереве устройств проекта контроллера).
Да не про PanelView речь, а про то, что данные он собирает в один контроллер только затем, чтобы потом по модбасу передать на HMI, который на Интаче... Что мешало поставить OPC сервер (RSLinx или KEP server) на PC c интачем, и брать эти данные напрямую из слайвов по Ethernet? и мароки бы небыло с конекшинами.
Да не про PanelView речь, а про то, что данные он собирает в один контроллер только затем, чтобы потом по модбасу передать на HMI, который на Интаче... Что мешало поставить OPC сервер (RSLinx или KEP server) на PC c интачем, и брать эти данные напрямую из слайвов по Ethernet? и мароки бы небыло с конекшинами.
"Создаем себе трудности, чтобы их потом героически преодолевать" (С) из фильма.
Ему бы возможности маршрутизации NetLinx. Помечтаем (Modbus aka Ethernet I/P, ControlNet, DeviceNet), было бы - по Modbus входим на Main, с него на Ethernet I/P и далее к остальным.
Т.к. этого нет, но мечты приводят к ProLinx (например 4201-DFNT-MCM) от Prosoft-Technology. Получит функционал - в разы выше, чем с 1769-MCM.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
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.137 секунды
FAQ
Поиск
Группы
Профиль
Войти и проверить личные сообщения
Вход
