День добрый форумчане. Подскажите, пожалуйста, варианты реализации передачи данных по Ethernet для UDEHCPU?
Состав: 3 PLC Q06UDEHCPU
Среда разработки: GX IEC Developer 7.03
Задача: передать массив данных от одного ПЛК другому по Ethernet
Причина: Сейчас в системе три ПЛК и три панели GOT GT1695M-XTBA. Каждая панель связывается со всеми тремя ПЛК. Хотелось бы это сделать примерно так: один ПЛК основной - он будет собирать все настройки с панелей, передавать и квитировать аварии. Два ПЛК связаны по ProfiBUS с полевыми устройствами - они принимают настройки и управляющие команды с основного ПЛК (сейчас они приминают напрямую с панелей) и передаю на основной ПЛК аварийные сообщения. Если бы проект был один, то существующая конфигурация вполне бы прокатила, но планируется серийное производство шкафов и для каждого объекта будет не выгодно перепривязывать панельку на другие ПЛК.
И вопрос номер 2 - можно ли смоделировать и проверить эту ситуацию на GX simulator, например?
Нашел варианты реализации, но они описаны только для отдельного модуля Ethernet, через FB, прокатит ли это для встроенного в ПЛК порта Ethernet?
Из вариантов реализации интересует: какую документацию можно прочитать по этому поводу, если не сложно, какие FB использовать и надо ли дололнительное ПО, например, какой нибудь GX Configurator?
Нарисуйте схему структуры проекта что как связано сейчас, и что желаете потом, включая полевые устройства.
И каким образом панели связаны со шкафами ?
1 вопрос-есть команды пересылки и приема данных (для ethernet),2вопрос - не получится на симуляторе смоделировать сеть.последнее-никакого ПО не надо его просто нет.Есть FB поищите по ссылкам в инете.Наконец зайдите на известный сайт там было обновление.Гимора у вас много.Одна машина будет нагружена сильно а 2 другие не очень да и собрать все в одну машину хлопотно.Сетка скажем прям не самая приятная для этих целей.Почитать можно мануалы по командам для кушки желательно последний релиз.Вот тут http://rapidshare.com/files/441159475/Manual.rar
сделайте профибас раз он уже есть.1 мастер а те что 2 отдельных уже можно слэйвами сделать .правда придется поменять блоки но в результате получится 1 в запасе.Имхо получится проще.ну ежели хочется эзернет поюзать то успехов.
Схема простая, в идеале, на мой взгляд, должно быть примерно так:
панельки (1,2 и 3) соединены только с PLC0.
PLC0 задачи:
- Задача первая - легкая - принять настройки в случае их изменения (ориентировочно раз пол года) и передать их для PLC1 и PLC2.
- Задача вторая: собрать аварийные состояния PLC1 и PLC2, сбор раз в секунду вполне устроит, можно даже раз в две секунды.
- Задача третья: передать управляющие команды на PLC1 и PLC2 (обмен устроит раз в сек.), но для этой задачи вполне можно и привязать часть кнопок панелек на PLC1 и PLC2, минуя PLC0.
Задачи для PLC1 и PLC2:
- управление полевыми устройствами (с PLC0 идет только команда ВКЛ/ОТКЛ, а все остальные алгоритмы управления будут на PLC1 и PLC2)
- прием команд и настроек от PLC0
- передача алармов PLC0
Сейчас сделано так:
- PLC0 - почти ничего не делает за исключением генерирования самых общих аварий (типа PLC0 в ошибке да и та не генерируется, а просто берется из MS) , т.е программного кода для него нет вообще.
- Панельки соединены с PLC1 и PLC2, для них они передают настройки и управляющие сигналы, и с них, напрямую, берут аварии.
Почему хочу переделать:
- в текущей схеме PLC0 не задействован - не экономно, надо или его вообще убрать или придумать что-то еще для него.
- проект для панелек содержит большое количество динамических объектов которые привязаны к двум PLC - если бы проект был один - проблем нет, а так как планируется серийный выпуск, встанет проблема перепривязки и смены адресов (схема достаточно сложная и какую-нибудь унифицированную адресацию я пока не придумал, поэтому придется для каждого нового проекта менять 200-300 тегов, грустно, но если что вполне решимо).
- на панельках много логики осталось (по синхронизации настроек между PLC1 и PLC2) - хочется ее перенести на PLC0
KAZAH - спасибо за документацию, я еще порылся на mitsubishi-automation.com, нашел и последние примеры и FB. Так что help рулит.
KAZAH - по поводу профибаса - в принципе, да это было бы одним из хороших решений, тем более что для PLC0 заложен модуль профибас. Пока проблема в том, что на существующих объектах дополнительное оборудование для профибас не предусмотрено, а покупать уже никто не будет. Зато для новых проектов - вполне приемлемо закупить еще преобразователи профибас-оптика и соединить PLC0 с PLC1 и PLC 2 по профибас. Оптика - потому что расстояния порядка 4-5км.
Ладно, завтра вылетаю на объект там попробую различные варианты.
Еще хочу добавить: проект планируется серийный, поэтому надо по максимуму его унифицировать, чтобы в дальнейшем не программировать PLC, а только лишь конфигурировать всю систему в целом.
у мицубиши нет модулей профибас на оптике.интересно что вы собрались покупать и как будете стыковать?а при больших расстояниях на оптике это тока MELSECNET или CC LINK IE.сие дорого.если профибас с репитерами то ваше расстояние как раз потянет.а зачем там еще модбас с RS485.нагородили канеш много и нерационально.интересно кто делал проект?буржуи или наши?все ваши полевые устройства можно было одно сеткой опросить и контроллер бы высвободился.не было бы гимора с синхронизацией контроллеров.а панели есть тоже с профибасом .так было бы все логично и красиво с точки зрения архитектуры.да вам понадобятся модули слэйвов для профибас ну и CONFIGURATOR DP.если конечно останетесь при мысли делать профибас.ну успехов вам.
да печально.а помер то от старости или от болезней?а что за функции возложены на систему если не секрет?
Итак, итог решения проблемы:
1. Передачу по Ethernet на версии GX IEC Developer 7.03 не удалось настроить, подошла только версия 7.04
2. Гемеройчик хоть и вышел, но не такой большой
3. Получилось вполне приемлемо, единственно что беспокоит отсутствие гарантированного времени доставки у Ethernet пришлось добавить несколько новых алармов.
Всем спасибо за помощь.
Интересно что такого нашлось в версии 7.04 по сравнению с 7.03 для реализации передачи данных по ETHERNET для вашего случая.
Русская версия Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)