конвертер из Ethenet в Profibus

[chega]

Добрый день.
Есть локальный контроллер, который имеет выход по Ethenet.
Основная система управления использует Profibus.
Предполагаем установить конвертер из Ethenet в Profibus.
Скажите, кто-нибудь использовал подобные конвертеры? Может быть есть какие-нибудь отзывы, рекомендации?

[san]

Информация о Ethenet маловато будет. Нужно еще знать какие протоколы на верхнем уровне.

[chega]

сформулирую по другому.
есть локальный контроллер, который может осуществлять обмен по Ethenet.
Система управления верхнего уровня выполнена на основе Simatic, обмен с удаленной перифирией в данной системе управления выполнен на основе Profibus.
Стоит задача интегрировать данный локальный контроллер в общую систему управления.
Вот я и хочу использовать какой-нибудь конвертер из Ethenet в Profibus.

[Никита]

Так по какому протоколу контроллер умеет обмениваться посредством Ethernet? Или вообще протокола там нет и самому писать надо? У профибаса протокол регламентирован, а Ethernet - технология передачи (физика) и не более того. Мало физически подружить, надо научить их понимать друг друга а для этого надо знать формат телеграмм от контроллера.

[abbat81]

Еще не мешало бы марку "локального контроллера" и какой контроллер установлен в системе управления Simatic , имеет ли этот контроллер коммуникационный процессор Ethernet ?

[san]

Если у Вас контролер с открытой архитектурой, тогда пробуйте реализовать какой-то протокол, например Modbus TCP/IP, и покупайте шлюз Modbus TCP/IP на Profibus. Но проще и дешевле наверное будет добавить модуль с Ethernet в конфигурацию Симатика.

[Василий Иванович]

Мне тоже больше нравится прямое подключение через Ethernet: у Профибуса есть такая паскудная особенность, как максимальная длина кадра в 244 байт, т.е. много туда без танцев с бубном не впихнёшь. Да и медленно будет.
Надо докупить сименсовский CP343 или соответственно CP443 и довоткнуть его к контроллеру.
Но тут есть подводные камни, ибо Сименс по умолчанию поддерживает либо устаревшие, либо закрытые протоколы пользовательского уровня, а так там только голый TCP или UDP будет в наличии, поверх которых самому писать драйвер придётся.
Если делать Modbus-TCP, то можно докупить у Сименс уже готовый драйвер, стоит где-то тыщи полторы евро.

[san]

Так многие модули Сименс на Ethernet поддерживают старый добрый FETCH/WRITE на TCP/IP. В этом случае тогда придется только прописывать клиентскую сторону, а серверную только сконфигурить. А вобще, можно и AG_SEND/AG_RECV поюзать, тоже ничего страшного. Главное в S7 не лезть, он ведь вроде как не совсем открытый или совсем не открытый ;-).

[Василий Иванович]

Ну дык Fetch/Write тоже вроде как проприетарный протокол, или? А юзать Send/Receive - это по сути ведь писать с нуля новый протокол поверх TCP...

[san]

Fetch/Write хорошо описан. Ведь клиентскую сторону у Симатика 300 тоже ручками писать надо. А Send/Receive можно вобще без протокола, просто отправил в одной стороне данные, а с другой словил. Но ручками писать надо с обеих сторон, это минус.

[Василий Иванович]

ссылочкой на описание не поделитесь?
"просто отправил данные" - это уже в принципе простейший протокол, ибо надо знать сколько и когда послать и принять, а также определить структуру сообщения.

[san]

Есть такой документ "S7-CPs for Industrial Ethernet Configuring and Commissioning" C79000-G8976-C182-01 у меня релиз 2003 года. Могу скинуть, только скажите куда. Думаю, что он и на официальном сайте Сименс есть.

[Василий Иванович]

Нашёл, спасибо. В принципе да, это было бы удобным вариантом, при условии использования подходящего CP, а также DB с номерами не больше 255. Ещё минус - инициатором передачи данных в обе стороны всегда будет клиент, который должен будет постоянно, долго и нудно опрашивать Сименс на предмет новых данных.

[san]

так и есть, по этому можно использовать Send/Receive

[Василий Иванович]

Просто циклически Send/Receive на, скажем 200 байт, будет работать до потери первого байта при пересылке. Если вместо ожидаемых 200 байт придёт 199, то они осядут мёртвым грузом в буфере СР, и Receive-блок его не прочитает, пока не придут следующие 200 байт. И тогда в блоке данных на приёме данные лягут со смещением в этот один байт, и пользовательская программа получит не то, что хотела.
Используя голый TCP, мы не знаем где начало кадра, где конец.

[san]

Отловить конечно как-то можно (например дополнительные служебные байты). Сталкивался с такой проблемой т до сих пор не знаю как лечится, лечил перезагрузкой ПЛК. Кстати, Василий Иванович, как в Симатиках очищается входной буфер в этом случае?

[Василий Иванович]

Эти "дополнительные служебные байты" в протоколе называются "начало кадра", "длина области данных" и т.п. :D
А пока начало кадра не попалось, приходится вычитывать весь мусор побайтно (а не кусками по 200 байт). Байтик за байтиком - буфер и очистится.

[chega]

Сделал уточнения к первоначальному вопросу, т.к. в первые разы сформулировал, мягко говоря, некорректно...
У локальных контроллеров интерфейс Ethernet, протокол Modbus/TCP.
Система управления всего объекта выполнена на основе S7-414H и распределенной периферии ET200M (связь по Profibus-DP, резервированная). У меня задача интегрировать локальный контроллер в эту общую систему управления. Пока остановился на следующем варианте:
1. Подключаю локальный контроллер к конвертеру типа Anybus X-gateway (Probus Slave – Modbus TCP), заказной номер AB7634. (http://www.industrialnets.ru/index/?int ... t&node=329)
2. И подключаю этот преобразователь к модулю Y-Link (для обеспечения подключения к резервированной периферии).
Данная схема будет работоспособной? В чем ее недостатки? Какие еще возможны варианты?

[san]

Эти "дополнительные служебные байты" в протоколе называются "начало кадра", "длина области данных" и т.п. :D
А пока начало кадра не попалось, приходится вычитывать весь мусор побайтно (а не кусками по 200 байт). Байтик за байтиком - буфер и очистится.

Ну этот механизм само сабо разумеещееся. А разве нет каких то SFC или еще че-то там для очистки входного буфера? Я думал это просто моя неграмотность, а тут получается откровенный баг. Или это считается нормой? Я вобще тяжело сейчас понимаю, как это на TCP могут не дойти байты. Это ж надежный протокол. Если байты теряются в Ethernet, так там тоже свои механизмы. Судя по всему, это где то вышеTCP, так тогда это вобще абсурд. Тогда, при реализации, это были ПЛК Випа (Сименс совместимые) и чесно говоря, думал, что это их баг. На форуме Сименс даже не поднимал эту проблему по этой причине. А коазывается это и Симатиков проблемы.

[san]

Сделал уточнения к первоначальному вопросу, т.к. в первые разы сформулировал, мягко говоря, некорректно...
У локальных контроллеров интерфейс Ethernet, протокол Modbus/TCP.
Система управления всего объекта выполнена на основе S7-414H и распределенной периферии ET200M (связь по Profibus-DP, резервированная). У меня задача интегрировать локальный контроллер в эту общую систему управления. Пока остановился на следующем варианте:
1. Подключаю локальный контроллер к конвертеру типа Anybus X-gateway (Probus Slave – Modbus TCP), заказной номер AB7634. Здесь ссылка на сайт Anybus.
2. И подключаю этот преобразователь к модулю Y-Link (для обеспечения подключения к резервированной периферии).
Данная схема будет работоспособной? В чем ее недостатки? Какие еще возможны варианты?

Тут наверное проблемы не так с преобразованием, как с резервированием. Как это повлияет на резервирование? Как должен себя вести "локальный контролер" (какой все таки? Вы так и не назвали) при переходе на резервный ПЛК S7-414H?

[chega]

При переходе на резервный ПЛК S7-414H продолжить передавать информацию о состоянии процесса на локальном участке. S7-414H осуществляет только сбор информации с локального контроллера. Какие преобразователи протоколов, каких фирм, для подобной схемы использовались в практике присутствующих?

[Василий Иванович]

Конфигурация со шлюзом должна будет работать. Ещё раз повторюсь, что проблема будет, если нужно будет слать много данных: ширина кадра Профибус даст знать о себе. В этом случае придётся мультиплексировать, и быстрой передачи данных добиться не удастся. Если подключать через Y-link, то с резервированием проблем не будет никаких. Н-система сама будет переключать линию Профибуса, и Anybus ничего не заметит. Помимо программирования шлюза (процесс несложный, за пару дней можно разобраться), нужно будет ещё озаботиться контролем состояния этого самого шлюза путём опроса его контрольных регистров, т.к. он в принципе способен подвиснуть. Неприятным моментом является необходимость складирования запчастей, а также программирование по последовательному порту (хотя может быть эта версия может заливаться и по Ethernet).
Если локальный PLС может работать сервером ModbusTCP, то можно будет вполне элегантно подключится напрямую через Ethernet. Тогда для H-системы нужно будет купить ModbusTCP-лицензию с поддержкой резервирования (я стопроцентно не уверен, но вроде бы есть такая) и опрашивать данные с активной Сименс-CPU. При переключении мастера опрашивать станет другая CPU, что для локального PLC должно быть фиолетово, ибо он - сервер и может отдать информацию любому клиенту.

[san]

Эти "дополнительные служебные байты" в протоколе называются "начало кадра", "длина области данных" и т.п. :D
А пока начало кадра не попалось, приходится вычитывать весь мусор побайтно (а не кусками по 200 байт). Байтик за байтиком - буфер и очистится.

Ну этот механизм само сабо разумеещееся. А разве нет каких то SFC или еще че-то там для очистки входного буфера? Я думал это просто моя неграмотность, а тут получается откровенный баг. Или это считается нормой? Я вобще тяжело сейчас понимаю, как это на TCP могут не дойти байты. Это ж надежный протокол. Если байты теряются в Ethernet, так там тоже свои механизмы. Судя по всему, это где то вышеTCP, так тогда это вобще абсурд. Тогда, при реализации, это были ПЛК Випа (Сименс совместимые) и чесно говоря, думал, что это их баг. На форуме Сименс даже не поднимал эту проблему по этой причине. А коазывается это и Симатиков проблемы.

Васлий Иванович. Опять поднимаю эту тему. Как на счет борьбы с эти нюансом?

[Василий Иванович]

я не забыл, просто некогда посмотреть

[Василий Иванович]

Можно попробовать сбросить соединение вызовом AG_CNTRL (FC10). При этом происходит отключение и реинициализация соединения. Подробности в той же документации, где и Fetch/Write описан. Я использовал C79000-G8900-C182-04.