PROFINET IO

[Автоматизатор]

С версии 4 CPU контроллеров S7-1200 поддерживают соединения с помощью функций PROFINET I-Device. Типа быстро, просто, надежно, современно.



По аналогии хочу соединить 4 контроллера в сеть.

Структурная схема.jpg

На структурной схеме показаны четыре контроллера S7-1200. Контроллер 1 - главный. Он управляет работой контроллеров 2 и 3. Контроллер 2 в свою очередь контролирует работу контроллера 4. Попробовать на практике подобную схему не могу, т.к. не имею нужного оборудования.

В одном из запросов техподдержка Сименса написала следующее:

С сетью здесь связана вторая важная вещь – обмен информацией между контроллерами по протоколу Profinet это коммуникации реального времени (в отличии от обмена информацией с рабочими станциями операторов). В связи с этим используемые Ethernet коммутаторы должны поддерживать Profinet и коммуникации реального времени – при выборе коммутаторов нужно проверить, водят ли конкретные модели в список одобренных для Profinet. За коммутаторы сторонних производителей мы не отвечаем, но можем гарантировать совместимость с Profinet коммутаторов серий SCALENCE X100 или SCALENCE X200. Серия SCALENCE X100 менее дорогая, но не поддерживает резервирование. Серия SCALENCE X200 более дорогая, но зато поддерживает кольцевое резервирование Ethernet сети.

Что то похожее видел только в документе PROFINET with STEP 7 V13 Function Manual, 12/2014, A5E03444486-AF

Коммутаторы CSM 1277 не подойдут? Что-то непонятно: вроде настраивается все просто. А вот как все работать будет?

[CHANt]

Лучше их же и спросить, в чем отличия скаланса и CSM 1277

[Михайло]

Встречный вопрос: а нужен ли этот самый реал-тайм? Ведь реал-тайм - это свойство системы обязательно дать отклик на запрос в течение заданного времени. TCP/IP обеспечит псевдо-реал-тайм.

[Автоматизатор]

TCP/IP обеспечит псевдо-реал-тайм

Я правильно понимаю, что возможно связь отпадет, а участники процесса об этом не узнают? Что значит "псевдо-реал-тайм"?

[Автоматизатор]

Можно попробовать использовать Modbus TCP. Только он гораздо сложнее в реализации.

[CHANt]

Я правильно понимаю, что возможно связь отпадет, а участники процесса об этом не узнают?

Это как обмен наладить. Способов много, есть возможность и контроль сделать. Только все ручками!

Что значит "псевдо-реал-тайм"?

А 1200 это все таки небольшой контроллер! У него цикл ОВ1 плавающий! Если нужно гарантированное время работы программы, обмена, тогда 1500 смотреть нужно.

[Михайло]

Что значит "псевдо-реал-тайм"?

Отклик не всегда будет происходить в течение X миллисекунд. В большинстве случае отклик будет, но гарантии нет.

[Михайло]

Существуют группы инструкций:
1. S7 communication: PUT, GET
2. Open User communication: TSEND_C, TRCV_C предназначены для создания коммуникационных соединений TCP или ISO-on-TCP
3. Open User communication: TCON, TDISCON, TSEND, TRCV предназначены для создания коммуникационных соединений TCP или ISO-on-TCP
4. Open User communication: TUSEND, TURCV через UDP
5. MODBUS TCP: MB_CLIENT, MB_SERVER

Судя по всему, все эти группы инструкций используют IP-адрес для определения коммуникационного партнера? То есть эти инструкции предназначены не для PROFINET RT? Modbus TCP явно базируется на протоколе TCP/IP...
Я себе пока так представляю: PROFINET RT - это когда партнера определяют по MAC-адресу. Для PROFINET IO допускается использование TCP/IP.

Надо снова смотреть вебинар о простом Профинете.

[Автоматизатор]

Надо снова смотреть вебинар о простом Профинете.

Удивительно нудные вебинары. Не разу не смог досмотреть до конца. Можно раз в 5 скорость увеличить, паузы между словами сократить.

Скорее всего говоруна надо более шустрого!!

А 1200 это все таки небольшой контроллер! У него цикл ОВ1 плавающий! Если нужно гарантированное время работы программы, обмена, тогда 1500 смотреть нужно.

Мое мнение: не столько критично плаванье времени цикла обмена, сколько бесконтрольное пропадение связи. Не знаю почему, но были случаи, когда пропадала связь между панелью оператора и контроллером. Контролировать обрыв

Способов много, есть возможность и контроль сделать. Только все ручками!

У нас в договоре прописано: связь между установками по Profibus через DP/DP Coupler. Но можно договориться сделать аналогично только через Profinet. Если суть не изменится.

Существуют группы инструкций:

Надо разбираться для чего предназначены и в каких случаях их можно использовать.

[CHANt]

Для PROFINET IO самые простые инструкции - SFC14 и SFC15. У меня в подписи примеры связи с ПЧ, но, настройка их для обмена между ПЛК отличаться не будет. Заодно и диагностика связи показана. Кроме того - использовать можно:
SFB 52/53
SFC 58/59
Надо конкретно смотреть что поддерживает конкретный CPU 1200.

[Михайло]

А 1200 это все таки небольшой контроллер! У него цикл ОВ1 плавающий! Если нужно гарантированное время работы программы, обмена, тогда 1500 смотреть нужно.

Я думаю, что коммуникационным обменом занимается отдельный процессор. Вон даже Овен и то серьезно задумался об этом и вроде даже сделал на ПЛК110[М02].

[CHANt]

Отдельно и занимается, а вот если программа использующая эти данные в ОВ1, то и разговор об RT ни о чем)))

[Михайло]

Надо разбираться для чего предназначены и в каких случаях их можно использовать.

1. S7 communication. GET: Read data from a remote CPU (SFB14), PUT: Write data to a remote CPU (SFB15)
2. Open User communication. TSEND_C: Send data via Ethernet (FB1030), TRCV_C: Receive data via Ethernet (FB1031) - предназначены для создания коммуникационных соединений TCP или ISO-on-TCP
3. Open User communication. TSEND: Send data via communication connection (SFB100), TRCV: Receive data via communication connection (SFB101), TCON: Establish communication connection (SFB102), TDISCON: Terminate communication connection (SFB103) - предназначены для создания коммуникационных соединений TCP или ISO-on-TCP
4. Open User communication. TUSEND: Send data via Ethernet (UDP) (SFB100), TURCV: Receive data via Ethernet (UDP) (SFB101) - предназначены для создания коммуникационных соединений UDP
5. MODBUS TCP. MB_CLIENT: Communicating via PROFINET as a Modbus TCP client (FB1084), MB_SERVER: Communicating via PROFINET as a Modbus TCP server (FB1085)

Мне кажется, надо смотреть в сторону PUT/GET. Не зачем придумывать новые протоколы Эзернета или париться с Модбасом. У тебя все контроллеры из серии S7!

[Михайло]

Опять же вспомним, что дает функция I-Device? Посмотри в справке ТИА Портала по указателю: I-device, Proxy device.
Без функции I-Device пришлось бы для четырех контроллеров создать один единый проект. В твоем случае может не все так плохо, т.к. ты единственный разработчик. Но все же не так удобно. Включенная функция I-Device (надо включить галочку в настройках CPU) позволяет разбить проект на четыре отдельных и заниматься каждым контроллером по отдельности. Коммуникационные партнеры в таких проектах будут представлены как I-Device proxy (прокси-устройства) - коммуникационные "заглушки", т.е. как будто кабель PROFINET IO уходит куда-то там, не важно куда (на данном этапе разработки). Хотя за этой заглушкой подразумевается соседний контроллер со своим проектом, со своими модулями и со своими коммуникационными партнерами.

[Автоматизатор]

Мне кажется, надо смотреть в сторону PUT/GET.

Думаю, что этот вариант предпочтителен. по сравнению с 2..5

1. S7 communication. GET: Read data from a remote CPU (SFB14), PUT: Write data to a remote CPU (SFB15)

Тут не понимаю:
При использовании функции GET определяется партнер, области чтения/записи и пр.

что дает функция I-Device?

Тоже одной мышкой настраиваются области обмена, только никаких функций вызывать не надо. Обмен реализуется аппаратно? Так?


Надо попробовать соединить в лаборатории контроллеры с помощью "S7 communication: PUT, GET". Парочку-тройку CPU1214C v.3 найду. Тяжело виртуально разбираться. Надо проверить реакцию контроллеров:
1 Обрыв связи
2 Как будет работать один контроллер, если другой отключен.
3 На включение / отключение одного из участников обмена.
4 Скорость обмена

[CHANt]

Тоже одной мышкой настраиваются области обмена, только никаких функций вызывать не надо. Обмен реализуется аппаратно? Так?

Обмен да - аппаратно идет. Но, если пользоваться аппаратным обменом, тогда чтобы контролировать связь придется использовать возможности статусных слов диагностики ОВ83 или ОВ86 - надо смотреть что поддерживает конкретный CPU. На мой взгляд проще использовать профибасовские функции, они работают также с профинетом и диагностику с них и брать, она менее заумная )))

Надо попробовать соединить в лаборатории контроллеры с помощью "S7 communication: PUT, GET".

Что-то обсуждение не в ту сторону пошло, это для обмена по TCP/IP, UDP ит.д., но это не Профинет))) Я перечислил функции выше

[Михайло]

Про свитч написано честно:

It is not possible to use the CSM 1277 switch in a redundant ring because it does not support redundancy.

По всей видимости речь идет о функционале Media Redundancy Protocol (MRP).

В конце концов, свитч CSM 1277 соединяет контроллеры, панели оператора и преобразователи частоты - и ничего, работает без тормозов.
При соединении контроллеров я бы учитывал, что порты гальванически изолированы парами: P1/P2 изолированы от P3/P4.

что дает функция I-Device?

Тоже одной мышкой настраиваются области обмена, только никаких функций вызывать не надо. Обмен реализуется аппаратно? Так?

Кстати говоря, связь можно настраивать графически (мышкой) и без всяких I-Device. Например, я всегда соединял контроллер с приводом без использования каких-либо функций в программе. А таких функций-то и нет! Есть только PUT/GET для связи между контроллерами.

Тут не понимаю:
При использовании функции GET определяется партнер, области чтения/записи и пр.

Я так понимаю, PUT/GET позволяет настраивать гибкое соединение, управлять активностью соединения и т.п.

Надо попробовать соединить в лаборатории контроллеры с помощью "S7 communication: PUT, GET". Парочку-тройку CPU1214C v.3 найду. Тяжело виртуально разбираться. Надо проверить реакцию контроллеров:
1 Обрыв связи
2 Как будет работать один контроллер, если другой отключен.
3 На включение / отключение одного из участников обмена.
4 Скорость обмена

Одно помню: если в течение 60 секунд (настраивается) после включения контроллера партнер не объявился, то ошибка и STOP. Партнер - частотник.

Что-то обсуждение не в ту сторону пошло, это для обмена по TCP/IP, UDP ит.д., но это не Профинет))) Я перечислил функции выше

Это функции для устаревшего контролера. Нынче это немодно.

[Автоматизатор]

Надо попробовать соединить в лаборатории контроллеры с помощью "S7 communication: PUT, GET".

Накидал программку обмена. Ерунда какая та. Ошибку связи выдает после 10 секунд обрыва кабеля! Может и где можно изменить значение, я не нашел.

Что-то обсуждение не в ту сторону пошло, это для обмена по TCP/IP, UDP ит.д., но это не Профинет))) Я перечислил функции выше

Попробуем разобраться

[Михайло]

В одной из статей Сименса про Профинет выудил следующую информацию: оказывается PROFINET IRT - это не специальная разновидность протокола PROFINET IO, а это способность оборудования поддерживать изохронный реал-тайм (IRT).
Отсюда я делаю следующий вывод: передача по протоколу PROFINET IO может производиться в режимах
1. "как попало" (время отклика до 10 секунд)
2. RT (время отклика от 10 мс)
3. IRT (время отклика до 1 мс)
Все зависит от оборудования:
1. Неспециальное оборудование третьего уровня модели OSI
2. Свитчи второго уровня (неуправляемые коммутаторы типа CSM 1277, бытовые неуправляемые свитчи)
3. Специализированное оборудование любого уровня (Scalance X-100 и выше)
Сами контроллеры S7-1200 поддерживают RT и IRT, есть соответствующие таблицы.

Смысл следующий: протокол PROFINET IO продуман так, что он для настройки соединения может использовать третий уровень модели OSI (Layer 3) и выше, а затем при циклической передаче данных ограничиться вторым уровнем (Layer 2). Таким образом циклическая передача данных может быть очень быстрой (режим RT). Однако проблема перегрузки сети не снята - достаточно поставить на перекачку несколько видео-файлов в такой сети и сеть начнет тормозить.
Режим IRT призван решить эту проблему за счет использования специальных маршрутизаторов, которые выделяют для пакетов данных PROFINET IO гарантированное время 50% и 50% для остального трафика. Конечно даже такую сеть (IRT) можно забить пакетами PROFINET IO, но эти пакеты циклические и легко вычислимые по трафику.
Вот такая имха.

[Автоматизатор]

Для PROFINET IO самые простые инструкции - SFC14 и SFC15.

У меня есть возможность отработать связь между двумя лабораторными ЦПУ: 214-1AE30-0XB0 (v2.2) и 214-1AG31-0XB0 (v3.0).

Как я понимаю: для использования SFC14 и SFC15 надо сформировать области данных для обмена. А это у меня никак не выходит. Скорее всего прошивки старые.