- Обязательно представиться на русском языке кириллицей (заполнить поле "Имя").
- Фиктивные имена мы не приветствуем. Ивановых и Пупкиных здесь уже достаточно.
- Не писать свой вопрос в первую попавшуюся тему - вместо этого создать новую тему.
- За поиск, предложение и обсуждение пиратского ПО и средств взлома - бан без предупреждения.
- Рекламу и частные объявления "куплю/продам/есть халтура" мы не размещаем ни на каких условиях.
- Перед тем как что-то написать - читать здесь и здесь, а студентам - обязательно здесь.
- Не надо писать в ЛС администраторам свои технические вопросы. Администраторы форума отлично знают как работает форум, а не все-все контроллеры, о которых тут пишут.
Передача данных через VPN канал.
-
- администратор
- Сообщения: 4735
- Зарегистрирован: 25 июл 2008, 07:12
- Имя: Диев Александр Васильевич
- Страна: Россия
- город/регион: г. Сегежа, Карелия
- Благодарил (а): 225 раз
- Поблагодарили: 396 раз
Передача данных через VPN канал.
Приветствую, коллеги.
Вопрос чисто теоретический (по крайней мере, пока). Допустим есть две системы управления на базе симатиков, расположенные в разных цехах. Данные из одной системы нужны в другой (а также наоборот, количество данных небольшое). Каждая из систем через маршрутизатор/файрвол с поддержкой VPN подключена к общей сети, примерно как на рисунке, с той лишь разницей, что это два отдельных проекта, общего проекта соединения нет (я просто для примера нарисовал): Вопрос в следующем: можно ли настроить VPN-канал между роутерами и через него гонять данные? И если можно, что для этого надо? Ссылка на мануал очень желательна.
Вопрос чисто теоретический (по крайней мере, пока). Допустим есть две системы управления на базе симатиков, расположенные в разных цехах. Данные из одной системы нужны в другой (а также наоборот, количество данных небольшое). Каждая из систем через маршрутизатор/файрвол с поддержкой VPN подключена к общей сети, примерно как на рисунке, с той лишь разницей, что это два отдельных проекта, общего проекта соединения нет (я просто для примера нарисовал): Вопрос в следующем: можно ли настроить VPN-канал между роутерами и через него гонять данные? И если можно, что для этого надо? Ссылка на мануал очень желательна.
У вас нет необходимых прав для просмотра вложений в этом сообщении.
Повторное использование кода не отменяет повторного использования мозга при его повторном использовании.
-
- почётный участник форума
- Сообщения: 3576
- Зарегистрирован: 10 ноя 2009, 04:58
- Имя: Толмачев Михаил Алексеевич
- город/регион: г. Чехов, МО
- Благодарил (а): 6 раз
- Поблагодарили: 271 раз
Передача данных через VPN канал.
На всякий случай сообщу, что если активировать Profinet-функцию iDevice, то обмен данными между контроллерами в двух разных проектах станет организовать намного проще. Я только не пробовал.
Почитай эту тему, про iDevice. Кури мануал " I-Device in a standard environment".
Это никак не связано с VPN и Security, но тоже нужно.
Почитай эту тему, про iDevice. Кури мануал " I-Device in a standard environment".
Это никак не связано с VPN и Security, но тоже нужно.
-
- администратор
- Сообщения: 4735
- Зарегистрирован: 25 июл 2008, 07:12
- Имя: Диев Александр Васильевич
- Страна: Россия
- город/регион: г. Сегежа, Карелия
- Благодарил (а): 225 раз
- Поблагодарили: 396 раз
Передача данных через VPN канал.
Спасибо, посмотрю обязательно.
Повторное использование кода не отменяет повторного использования мозга при его повторном использовании.
-
- администратор
- Сообщения: 4735
- Зарегистрирован: 25 июл 2008, 07:12
- Имя: Диев Александр Васильевич
- Страна: Россия
- город/регион: г. Сегежа, Карелия
- Благодарил (а): 225 раз
- Поблагодарили: 396 раз
Передача данных через VPN канал.
Этот I-Device - штука, безусловно, интересная, но...
Чойто я как-то не вник в эту тему. Делаю пример по мануалу, п.3.2, где в качестве I-Device выступает CP343-1 Lean. Всё создаётся и конфигурится, всё ОК. Делаю аналогичную (на мой взгляд :) ) конфигурацию на 1500-том контроллере. Беру контроллер, ставлю ему коммуникационник CP1543-1, пытаюсь в нём настроить IO-Device - а фигу... разрешает его сделать только IO-controller'ом. Зато позволяет настроить режим IO device у дублированных интерфейсов контроллера, которые сами по себе так и напрашиваются, чтобы свой ввод-вывод к ним подключать.
Отправлено спустя 1 минуту 19 секунд:
Возвращаясь к первоначальному вопросу: а Profinet вообще сквозь маршрутизаторы ходит или только в одноранговой сети?
Чойто я как-то не вник в эту тему. Делаю пример по мануалу, п.3.2, где в качестве I-Device выступает CP343-1 Lean. Всё создаётся и конфигурится, всё ОК. Делаю аналогичную (на мой взгляд :) ) конфигурацию на 1500-том контроллере. Беру контроллер, ставлю ему коммуникационник CP1543-1, пытаюсь в нём настроить IO-Device - а фигу... разрешает его сделать только IO-controller'ом. Зато позволяет настроить режим IO device у дублированных интерфейсов контроллера, которые сами по себе так и напрашиваются, чтобы свой ввод-вывод к ним подключать.
Отправлено спустя 1 минуту 19 секунд:
Возвращаясь к первоначальному вопросу: а Profinet вообще сквозь маршрутизаторы ходит или только в одноранговой сети?
Повторное использование кода не отменяет повторного использования мозга при его повторном использовании.
-
- администратор
- Сообщения: 4735
- Зарегистрирован: 25 июл 2008, 07:12
- Имя: Диев Александр Васильевич
- Страна: Россия
- город/регион: г. Сегежа, Карелия
- Благодарил (а): 225 раз
- Поблагодарили: 396 раз
Передача данных через VPN канал.
А в TIA Portal V14 с CM1542 всё получилось :)
Повторное использование кода не отменяет повторного использования мозга при его повторном использовании.
-
- администратор
- Сообщения: 4735
- Зарегистрирован: 25 июл 2008, 07:12
- Имя: Диев Александр Васильевич
- Страна: Россия
- город/регион: г. Сегежа, Карелия
- Благодарил (а): 225 раз
- Поблагодарили: 396 раз
Передача данных через VPN канал.
Ну, не то, чтобы совсем всё - получилось сделать I-Device на базе контроллера из серии S7-1500 и коммуникационника CM1542. А как именно - смогу описать только в понедельник, на домашней виртуалке у меня только 13-я версия есть. Впрочем, там получилось всё по мануалу. По памяти - примерно так:
1. Вставил в проект контроллер из 1500-й серии (кстати, выбор таких в 14-й версии намного больше).
2. В Device View прицепил к нему CM1542-1
3. Выбрал на нём PROFINET interface, в параметрах зашёл в Ethernet addresses, добавил подсеть и выставил IP-адрес. После этого в пункте Operating mode появилась возможность выбрать IO Device. Вот как раз сейчас проверяю - в 13-й версии такой для возможности CM1542-1 нет (для контроллера - есть).
Ну и дальше в Operating mode появился подпункт I-device communications, в котором можно задать Transfer area и откуда после компиляции hardware можно экспортировать GSD.
Под вопросом осталась правильность конфигурирования Media redundancy - когда в конфигурации нет Manager, нет возможности сделать его клиентом. Поставил Manager(auto), я думаю, это единственный способ сделать конфигурацию, которая потом оживёт при физическом соединении с аналогичными кусками из других проектов.
Ну а возможность распространения profinet за роутер также осталась под вопросом. Не посылает меня руководство на курсы по profinet :(.
1. Вставил в проект контроллер из 1500-й серии (кстати, выбор таких в 14-й версии намного больше).
2. В Device View прицепил к нему CM1542-1
3. Выбрал на нём PROFINET interface, в параметрах зашёл в Ethernet addresses, добавил подсеть и выставил IP-адрес. После этого в пункте Operating mode появилась возможность выбрать IO Device. Вот как раз сейчас проверяю - в 13-й версии такой для возможности CM1542-1 нет (для контроллера - есть).
Ну и дальше в Operating mode появился подпункт I-device communications, в котором можно задать Transfer area и откуда после компиляции hardware можно экспортировать GSD.
Под вопросом осталась правильность конфигурирования Media redundancy - когда в конфигурации нет Manager, нет возможности сделать его клиентом. Поставил Manager(auto), я думаю, это единственный способ сделать конфигурацию, которая потом оживёт при физическом соединении с аналогичными кусками из других проектов.
Ну а возможность распространения profinet за роутер также осталась под вопросом. Не посылает меня руководство на курсы по profinet :(.
Повторное использование кода не отменяет повторного использования мозга при его повторном использовании.
-
- освоился
- Сообщения: 248
- Зарегистрирован: 31 янв 2017, 08:44
- Имя: Маркушин Андрей Геннадьевич
- Страна: Россия
- город/регион: Нижегородская обл., Выкса
- Благодарил (а): 19 раз
- Поблагодарили: 64 раза
Передача данных через VPN канал.
По профинету за роутером... Вопрос - какой PROFINET? Если RT (realtime) - PROFINET IO, IRT - не нужен, то вполне себе пройдёт, стандарт PROFINET поддерживает стандартные TCP-UDP.
Если нужно RT прокинуть за маршрутизатор, то этот маршрутизатор должен "понимать" PROFINET IO/IRT. И если на уровне распределения вроде бы всё нормально должно быть, то на уровне маршрутизации - попечальнее, IP-то поддерживается, а остальные верхнеуровневые навороты "оптимизировали" (как эйчары персонал предприятия :)). В следствие чего "обычный" маршрутизатор может не понять, например, к какому VPN относится пакет PROFINET IO, и что с этим пакетом делать. В общем, нужно смаршрутизировать PROFINET IO - используйте специализированное оборудование.
Или не используйте PROFINET IO вообще - для передачи данных между цехами с задержкой в сотню-другую миллисекунд (если с сетями всё плохо, обычно - десятки миллисекунд) вполне хватит TCP соединения и нормально настроенного сетевого оборудования.
Если нужно RT прокинуть за маршрутизатор, то этот маршрутизатор должен "понимать" PROFINET IO/IRT. И если на уровне распределения вроде бы всё нормально должно быть, то на уровне маршрутизации - попечальнее, IP-то поддерживается, а остальные верхнеуровневые навороты "оптимизировали" (как эйчары персонал предприятия :)). В следствие чего "обычный" маршрутизатор может не понять, например, к какому VPN относится пакет PROFINET IO, и что с этим пакетом делать. В общем, нужно смаршрутизировать PROFINET IO - используйте специализированное оборудование.
Или не используйте PROFINET IO вообще - для передачи данных между цехами с задержкой в сотню-другую миллисекунд (если с сетями всё плохо, обычно - десятки миллисекунд) вполне хватит TCP соединения и нормально настроенного сетевого оборудования.
-
- администратор
- Сообщения: 4735
- Зарегистрирован: 25 июл 2008, 07:12
- Имя: Диев Александр Васильевич
- Страна: Россия
- город/регион: г. Сегежа, Карелия
- Благодарил (а): 225 раз
- Поблагодарили: 396 раз
Передача данных через VPN канал.
Насчёт специализированного оборудования - я как раз и смотрю на Scalance (впрочем, всё это пока что - теоретические изыскания и попытка компенсировать то, что меня на курсы по сименсовским сетям не отправляют). И отказаться от Profinet IO - тоже вариант. Тот же Modbus TCP прекрасно пройдёт через все VPN и роутеры. Но с Profinet IO разобраться всё-таки хочется...
Повторное использование кода не отменяет повторного использования мозга при его повторном использовании.
-
- освоился
- Сообщения: 248
- Зарегистрирован: 31 янв 2017, 08:44
- Имя: Маркушин Андрей Геннадьевич
- Страна: Россия
- город/регион: Нижегородская обл., Выкса
- Благодарил (а): 19 раз
- Поблагодарили: 64 раза
Передача данных через VPN канал.
Да тут скорее вопрос - зачем нужен PROFINET IO в данной ситуации? Высокая производительность и детерминированность доставки данных нужна больше на полевом уровне, где сети и строятся на специализированном (ну или на неуправляемом) оборудовании. Передача данных между производственными участками - уже немного другой уровень автоматизации, там обычно требования к реалтайму пониже. Я вообще не принимаю прямой выход полевых сетей на цеховой уровень - для этого и нужен Скаланс 6хх серии, правда я с ним не работал - стараюсь использовать CPU через отдельный коммуникационный интерфейс как шлюз в общую сеть для устройств контроллера. А там уже "сетевики" раскидывают оборудование по VLANам...
Отказываться от PROFINET в пользу MODBUS - менять шило на мыло, проще использовать TCP-соединение на уровне контроллера - сконфигурировать соответствующее одностороннее S7-соединение и через него работать.
Трудоёмкость:
1. Добавить 1 Unspecified S7-соединение, указав адрес шлюза.
2. Проработать протокол (в данном случае - выделить место под обмен, чаще всего в блоках данных)
3. Вызвать соответствующий коммуникационный блок (PUT, GET)
Всё. Из затрат - желательно использовать отдельный CP для подключения к внешней сети.
VPN-канал всё равно роутер обеспечивать будет, если допинговаться получиться, связь будет
Отказываться от PROFINET в пользу MODBUS - менять шило на мыло, проще использовать TCP-соединение на уровне контроллера - сконфигурировать соответствующее одностороннее S7-соединение и через него работать.
Трудоёмкость:
1. Добавить 1 Unspecified S7-соединение, указав адрес шлюза.
2. Проработать протокол (в данном случае - выделить место под обмен, чаще всего в блоках данных)
3. Вызвать соответствующий коммуникационный блок (PUT, GET)
Всё. Из затрат - желательно использовать отдельный CP для подключения к внешней сети.
VPN-канал всё равно роутер обеспечивать будет, если допинговаться получиться, связь будет
-
- администратор
- Сообщения: 4735
- Зарегистрирован: 25 июл 2008, 07:12
- Имя: Диев Александр Васильевич
- Страна: Россия
- город/регион: г. Сегежа, Карелия
- Благодарил (а): 225 раз
- Поблагодарили: 396 раз
Передача данных через VPN канал.
Вот тут тема уже ближе к практике, с такой задачей я сталкивался и решалось это более геморным способом (прокидыванием кабелей из цеха в цех с риском получить проблемы из-за раздельных контуров заземления). Технология такая: конвейер подаёт сыпучий материал из одного цеха в другой. Исполнительный механизм - шнек с частотником в первом цехе, входит в его систему управления и проектируется первым пректировщиком. Измерение уровня в приёмном бункере - во втором цехе, соответственно - вторая система управления и второй проектировщик. Проекты, соответственно, разные. Из измерения и исполнительного механизма надо сделать контур управления. Вот на такой случай я и смотрю в сторону перекидывания данных от системы к системе.
Я правильно понимаю, что стороны этого S7-соедниения можно сконфигурить в разных проектах и заставить работать вместе? Можно ссылочку на мануал? И, кстати, как оно диагностируется? Нужно ведь предусмотреть сценарий на случай обрыва связи...
Повторное использование кода не отменяет повторного использования мозга при его повторном использовании.
-
- освоился
- Сообщения: 248
- Зарегистрирован: 31 янв 2017, 08:44
- Имя: Маркушин Андрей Геннадьевич
- Страна: Россия
- город/регион: Нижегородская обл., Выкса
- Благодарил (а): 19 раз
- Поблагодарили: 64 раза
Передача данных через VPN канал.
Для контуров управления надежнее использовать всё-таки соединение через полевые шины, PN-PN Coupler, например. Зависимость производства от сетей общего назначения - мне не очень нравится, но при необходимости... Диагностика на уровне программных блоков - есть. А если совсем по-хорошему - только хардкор, только сети АСУТП (ну или телеуправления) :) Могу порекомендовать PN/PN Coupler - объём данных небольшой, обмен - быстрый, надёжность - высокая. Отдельный кабель сетевой тянуть придётся, конечно, но электрическая изоляция сетей в документации https://cache.industry.siemens.com/dl/ ... _en-US.pdf обозначена.
При работе через S7-соединение, его можно сконфигурировать и выполнять операции чтения-записи данных только на одном контроллере. Мануал сейчас не найду, но ссылка встречалась в теме: viewtopic.php?f=152&t=10016
-
- администратор
- Сообщения: 4735
- Зарегистрирован: 25 июл 2008, 07:12
- Имя: Диев Александр Васильевич
- Страна: Россия
- город/регион: г. Сегежа, Карелия
- Благодарил (а): 225 раз
- Поблагодарили: 396 раз
Передача данных через VPN канал.
Тут речь не идёт о сетях общего назначения. Скорее - своя сеть для нужд АСУТП, через которую, в частности, внешняя система сбора данных собирает информацию с OPC-серверов и нет штатного доступа для иных пользователей. Ну и ещё одно из применений - обмен данными между системами. На 2-3-4 системах такое решение будет дороже отдельного кабеля, а дальше - уже не факт.
А вот тут возникает вопрос безопасности. Читается/пишется всё просто и легко, но для этого надо будет открывать доступ для S7 к контроллеру, а это чревато появлением злоумышленника... Хотелось бы иметь возможность ограничить объем доступных данных и тип доступа - только для чтения.
Повторное использование кода не отменяет повторного использования мозга при его повторном использовании.
-
- освоился
- Сообщения: 248
- Зарегистрирован: 31 янв 2017, 08:44
- Имя: Маркушин Андрей Геннадьевич
- Страна: Россия
- город/регион: Нижегородская обл., Выкса
- Благодарил (а): 19 раз
- Поблагодарили: 64 раза
Передача данных через VPN канал.
Тогда можно использовать обычное Unspecified TCP соединение (AG_SEND/RECEIVE для СP, TSEND/TRECEIVE для встроенных интерфейсов). Если сети - свои, то риски падения сети можно считать приемлемыми. И S7-соединение не используется. При недостатке скорости, можно и UDP соединение замутить, в протокол обмена ввести подтверждение приёма телеграммы.
-
- осмотрелся
- Сообщения: 192
- Зарегистрирован: 16 дек 2011, 15:13
- Имя: Алексей
- Страна: Россия
- Благодарил (а): 65 раз
- Поблагодарили: 46 раз
Передача данных через VPN канал.
S7 соединения: функцияVADR писал(а): ↑15 янв 2018, 13:38И, кстати, как оно диагностируется?
Код: Выделить всё
C_CNTRL(EN_R := true // IN: BOOL
,ID := IdConn// IN: WORD
,RETVAL := RetVal // OUT: INT
,ERROR := Error// OUT: BOOL
,STATUS := Status// OUT: WORD
,C_CONN := Connected// OUT: BOOL
,C_STATUS := ConnStatus// OUT: WORD
); // VOID
TCP соединения через CP модуль: функция
Код: Выделить всё
AG_CNTRL(ACT := true // IN: BOOL
,ID := 0 // IN: INT
,LADDR := WORD_TO_BLOCK_DB(_pt.DBNr).DW[Adr + 2] // IN: WORD
,CMD := CtrlCmd// IN: INT
,DONE := CtrlDone// OUT: BOOL
,ERROR := CtrlError// OUT: BOOL
,STATUS := CtrlStatus // OUT: WORD
,RESULT1 := CntrlRes1 // OUT: DWORD
,RESULT2 := CntrlRes2 // OUT: DWORD
); // VOID
в RESULT1 содержится инфа 0..31 bits = ID 1 - ID 32 connection (0 - connection terminated/not configured, 1 - connection established)
в RESULT2 содержится инфа 32..64 bits = ID 33 - ID 64 connection (0 - connection terminated/not configured, 1 - connection established)
Сконфигурированные в NetPro соединения через CP устанавливаются автоматически (причем есть значение CMD, которое позволяет разорвать принудительно соединение).
TCP соединения через "бошку" (T блоки - T_CON, T_SEND, T_RECV, T_DISCON): читать, что возвращают функции (Open Communication via Industrial Ethernet)