Модбас через TCP

[ATS]

Столкнулся с проблемой.
Не могу достучаться до SMH-2Gi через виртуальный COM порт подключенный к контроллеру по TCP.
Lectus Modbus OPC по modbus TCP читает данные с контроллера без проблем, но требуется опрос контроллера устройством именно через COM порт подключенный по RAW TCP.

При попытке в Лектусе выставить режим Modbus через TCP ответы контроллера также пропадают.

В чем может быть проблема?

[Arsie]

Цитата

Сообщение от ATS

Столкнулся с проблемой.
Не могу достучаться до SMH-2Gi через виртуальный COM порт подключенный к контроллеру по TCP.
Lectus Modbus OPC по modbus TCP читает данные с контроллера без проблем, но требуется опрос контроллера устройством именно через COM порт подключенный по RAW TCP.

При попытке в Лектусе выставить режим Modbus через TCP ответы контроллера также пропадают.

В чем может быть проблема?

Думаю, проблема в "виртуальном СОМ порту".

Расскажите мне, пожалуйста, что такое сырой TCP сокет?

[ATS]

Цитата:

Сообщение от Arsie

Думаю, проблема в "виртуальном СОМ порту".

Это исключено - с программой VSPE (Virtual Serial Ports Emulator) работаю давно. Да и устройство давно опробовано. И то и другое без проблем работают по TCP с MOXA DE-311.

Чтобы не перевирать..

[Arsie]

Цитата

Сообщение от ATS

Чтобы не перевирать..

Мне нужно видеть не ссылку на википедию, мне нужно видеть ваше понимание обсуждаемого вопроса.

Либо моё непонимание

[ATS]

Да Raw TCP вроде и не обсуждали...

Фактически имеем ТСР клиента, который подключается к контроллеру по заданному порту и IP адресу. Данные по протоколу Modbus RTU с заданным адресом передаются клиенту через виртуальный COM порт. Запросы уходят- ответов нет.

Должен ли контроллер работать в режиме Modbus через TCP?
Или наличие контрольной суммы в исходном пакете сбивает его с толку?

[Arsie]

Цитата

Сообщение от ATS

Фактически имеем ТСР клиента, который подключается к контроллеру по заданному порту и IP адресу. Данные по протоколу Modbus RTU с заданным адресом передаются клиенту через виртуальный COM порт. Запросы уходят- ответов нет.

Вижу, что не понимаете.

Тогда давайте так: TCP-слиент отсылает ЧТО контроллеру? Заодно неплохо бы рассказать о номере "заданного" порта и открыт ли этот порт в сетевом экране компьютера. Ещё неплохо бы присовокупить описание, насколько поддерживает RAW socket ваша операционная система.

Отмечу заранее, что TCP-клиент работает по протоколу TCP, поэтому он и называется TCP-клиентом, а не как-то иначе.

[ATS]

Цитата:

Сообщение от Arsie

Вижу, что не понимаете.

Тогда давайте так: TCP-слиент отсылает ЧТО контроллеру? Заодно неплохо бы рассказать о номере "заданного" порта и открыт ли этот порт в сетевом экране компьютера. Ещё неплохо бы присовокупить описание, насколько поддерживает RAW socket ваша операционная система.

Кажется если было сказано

Цитата

Lectus Modbus OPC по modbus TCP читает данные с контроллера без проблем

то вопросы о номере порта и сетевом экране излишни...

Raw TCP используется устройством которое должно считать данные с контроллера и к моей операционке отношения не имеет. Кстати, это устройство тоже может опрашиваться через TCP соединение по Modbus протоколу. И поверьте это не раз делалось с помощью того-же TCP клиента и виртуального COM порта (VSPE)

Конкретно - читаем 01 04 00 00 00 08 и с контрольной суммой F1 CC

Сейчас проверил и MasterOPC Universal Modbus Server читает все аналогично Лектусу и не читает при включении режима Modbus поверх TCP

[Arsie]

Цитата

Сообщение от ATS

Кажется если было сказано то вопросы о номере порта и сетевом экране излишни...

Т.е. порт 502, правильно?

На многих операционках RAW socket на уровне стека запрещены или очень ограничены, поэтому у меня есть определённые сомнения в том, что они применяются в вашей программе. Ваше прямое сравнение RAW socket с Modbus-TCP лишь подтверждает мои сомнения.

Цитата

Сообщение от ATS

Raw TCP используется устройством которое должно считать данные с контроллера и к моей операционке отношения не имеет. Кстати, это устройство тоже может опрашиваться через TCP соединение по Modbus протоколу. И поверьте это не раз делалось с помощью того-же TCP клиента и виртуального COM порта (VSPE)

Конкретно - читаем 01 04 00 00 00 08 и с контрольной суммой F1 CC

Сейчас проверил и MasterOPC Universal Modbus Server читает все аналогично Лектусу и не читает при включении режима Modbus поверх TCP

Похоже указанный вами в первом сообщении "сырой сокет" не что иное, как обычный TCP-сокет, через который передаётся не менее обычный TCP-фрейм с полем данных "01 04 00 00 00 08 F1 CC", я всё правильно понимаю?

[ATS]

Цитата:

Сообщение от Arsie

Т.е. порт 502, правильно?

На многих операционках RAW socket на уровне стека запрещены или очень ограничены, поэтому у меня есть определённые сомнения в том, что они применяются в вашей программе. Ваше прямое сравнение RAW socket с Modbus-TCP лишь подтверждает мои сомнения.

Насколько помню в устройстве RT DOS

Цитата

Похоже указанный вами в первом сообщении "сырой сокет" не что иное, как обычный TCP-сокет, через который передаётся не менее обычный TCP-фрейм с полем данных "01 04 00 00 00 08 F1 CC", я всё правильно понимаю?

В настройках типа соединения называется именно RAW TCP

в поле данных
адрес slave | код функции | данные | контрольная сумма

[Arsie]

Цитата

Сообщение от ATS

Цитата

На многих операционках RAW socket на уровне стека запрещены или очень ограничены, поэтому у меня есть определённые сомнения в том, что они применяются в вашей программе. Ваше прямое сравнение RAW socket с Modbus-TCP лишь подтверждает мои сомнения.

Насколько помню в устройстве RT DOS

Цитата

Похоже указанный вами в первом сообщении "сырой сокет" не что иное, как обычный TCP-сокет, через который передаётся не менее обычный TCP-фрейм с полем данных "01 04 00 00 00 08 F1 CC", я всё правильно понимаю?

В настройках типа соединения называется именно RAW TCP

в поле данных
адрес slave | код функции | данные | контрольная сумма

Вы же сами приводили мне ссылку из википедии. Нет такого типа соединения, как RAW TCP. Что на самом деле означает это буквосочетание знает только тот человек, который писал софт для вашего устройства. Но что никакого отношения к RAW socket оно не имеет - это факт.


Теперь перейдём к SMH-2Gi. По 502 порту драйвер Modbus логично ожидает вполне конкретного пакета, по формату соответствующему Modbus-TCP. Ведь это порт Modbus-TCP, а не чего-либо иного.

Пакет данных "адрес slave | код функции | данные | контрольная сумма" соответствует пакету Modbus-TCP?

[ATS]

Цитата:

Сообщение от Arsie

Вы же сами приводили мне ссылку из википедии. Нет такого типа соединения, как RAW TCP. Что на самом деле означает это буквосочетание знает только тот человек, который писал софт для вашего устройства. Но что никакого отношения к RAW socket оно не имеет - это факт.

По дороге прочитал - Крис Касперски "Сырость не радость" Советую.

Понял что ничего страшного я не сказал.. И кстати из программ:

Цитата:

Сообщение от Arsie

Теперь перейдём к SMH-2Gi. По 502 порту драйвер Modbus логично ожидает вполне конкретного пакета, по формату соответствующему Modbus-TCP. Ведь это порт Modbus-TCP, а не чего-либо иного.

Пакет данных "адрес slave | код функции | данные | контрольная сумма" соответствует пакету Modbus-TCP?

Соответствует пакету Modbus RTU и Modbus поверх TCP

Для протокола Modbus TCP выглядит следующим образом:
ид транзакции | ид протокола | длина пакета | адрес slave | код функции | данные

где
ид транзакции - два байта, обычно нули
ид протокола - два байта, нули
длина пакета - два байта - длина следующей за этим полем части пакета
адрес slave - адрес подчинённого устройства, к которому адресован запрос. Обычно игнорируется, если соединение установлено с конкретным устройством. Может использоваться, если соединение установлено с бриджом, который выводит нас, например, в сеть RS485.

Поле контрольной суммы в Modbus TCP отсутствует.

[ATS]

Итак

Соединимся с контроллером
(порт совсем не обязательно 502)

Запросим 01 04 00 02 00 10 с контрольной суммой
- нет ответа


Посылаем с преамбулой 00 00 00 00 00 06 01 04 00 02 00 10

и вот он ответик долгожданный

Ответ однозначный - контроллер Modbus поверх TCP пока не поддерживает.

[Arsie]

Цитата

Сообщение от ATS

Соответствует пакету Modbus RTU и Modbus поверх TCP

Modbus-RTU он не может соответствовать, т.к. поле данных обрамлено служебными полями TCP.

А вот "Modbus поверх TCP" - вполне. Т.к. налицо инкапсуляция.

Но тут нарушено главный принцип: устройства по оба конца провода должны играть по одним и тем же правилам. Контроллер ждёт Modbus-TCP и скармливать ему что-либо иное априори не имеет смысла.

Цитата

Сообщение от ATS

Для протокола Modbus TCP выглядит следующим образом:
ид транзакции | ид протокола | длина пакета | адрес slave | код функции | данные

где
ид транзакции - два байта, обычно нули
ид протокола - два байта, нули
длина пакета - два байта - длина следующей за этим полем части пакета
адрес slave - адрес подчинённого устройства, к которому адресован запрос. Обычно игнорируется, если соединение установлено с конкретным устройством. Может использоваться, если соединение установлено с бриджом, который выводит нас, например, в сеть RS485.

Поле контрольной суммы в Modbus TCP отсутствует.

Ну вот вы и разобрались. Осталось только понять, при чём тут виртуальный COM-порт и зачем было его упоминать в самом первом сообщении

Вы ставили в пример бридж MOXA DE-311, для которого (как и для других бриджей) "Modbus поверх TCP" и придуман Понятное дело, что в этом случае он становится "Виртуальным СОМ-портом", т.к. драйвер всё приходящее в себя тупо запихивает в пакет TCP, приняв который MOXA DE-311 не менее тупо его выпихивает себе на разъём безо всякой обработки.

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

Цитата

Сообщение от ATS

Ответ однозначный - контроллер Modbus поверх TCP пока не поддерживает

Этот же вывод можно было сделать просто прочитав описание контроллера

[ATS]

Цитата:

Сообщение от Arsie

Этот же вывод можно было сделать просто прочитав описание контроллера

Возможно не досмотрел - сегодня неделя как 2Gi на столе появился.
Пока впечатления очень положительные

Цитата:

Сообщение от Arsie

Осталось только понять, при чём тут виртуальный COM-порт и зачем было его упоминать в самом первом сообщении

Да это как раз тот самый COM2 созданный VSPE в скиншотах выше, который и использовался в терминалке

Цитата:

Сообщение от Arsie

Modbus-RTU он не может соответствовать, т.к. поле данных обрамлено служебными полями TCP.

А вот "Modbus поверх TCP" - вполне. Т.к. налицо инкапсуляция.

Но тут нарушено главный принцип: устройства по оба конца провода должны играть по одним и тем же правилам. Контроллер ждёт Modbus-TCP и скармливать ему что-либо иное априори не имеет смысла.

Ну почему? Дополнительный вариант чтения данных с контроллера устройствами не поддерживающими Modbus TCP может оказаться совсем не лишним. Тем боле что и в OPC серверах эта возможность предусмотрена.

Для программиста здесь задачка совсем простая - если в данных нет:

ид транзакции | ид протокола | длина пакета |

проверяем адрес slave и если это адрес контроллера обрабатываем запрос как обычно для COM и RS485.

Ответ формируем как для COM и RS485

Цитата:

Сообщение от Arsie

Вы ставили в пример бридж MOXA DE-311, для которого (как и для других бриджей) "Modbus поверх TCP" и придуман Понятное дело, что в этом случае он становится "Виртуальным СОМ-портом", т.к. драйвер всё приходящее в себя тупо запихивает в пакет TCP, приняв который MOXA DE-311 не менее тупо его выпихивает себе на разъём безо всякой обработки.

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

Главной выгоды не видим

А я бы советовал добавить в SMLogix для COM1 и COM2 кроме Slave еще и Bridge (естественно на выбор и возможно даже с другим Tcp портом) по которому любые данные из ТCP портов выпихиваются во внешние интерфейсы и полученные данные отправляются обратно (тупо как MOXA DE-311)

Пример:
Автоматизируем теплопункт при помощи 2Gi без использования слейвов.
Кроме автоматики имеем и приборы учета (это мне близко). При наличии режима бридж через 2Gi имеем доступ к приборам через Ethernet и через подключенные модемы GPRS да еще с возможностями Open VPN.

Это однако будет продаваемо.

[Arsie]

Цитата

Сообщение от ATS

А я бы советовал добавить в SMLogix для COM1 и COM2 кроме Slave еще и Bridge (естественно на выбор и возможно даже с другим Tcp портом) по которому любые данные из ТCP портов выпихиваются во внешние интерфейсы и полученные данные отправляются обратно (тупо как MOXA DE-311)

Пример:
Автоматизируем теплопункт при помощи 2Gi без использования слейвов.
Кроме автоматики имеем и приборы учета (это мне близко). При наличии режима бридж через 2Gi имеем доступ к приборам через Ethernet и через подключенные модемы GPRS да еще с возможностями Open VPN.

Это однако будет продаваемо.

Безусловно соглашусь с вашей задумкой, но совсем не соглашусь с простотой реализации. Универсальных драйверов "виртуального СОМ-порта" не существует. Те же драйверы для MOXA сначала проверяют, что на том конце MOXA, передают настройки последовательного порта и лишь затем начинают транслировать трафик.

В результате, с режимом "бридж" мы получаем бонус в виде поддержки драйверами всех операционных систем + несколько раз в год эти драйверы нужно тестировать и поддерживать из-за того, что очередная заплатка Микрософта или Касперского (Нортона, Есета, Веба и т.д.) закрывая очередную дыру в операционке блокировала работу какой-либо нужной драйверам функции.

Можно конечно кивнуть на OPC-сервер с его режимом "Modbus поверх TCP" или на ваше устройство, типа они без драйвера работают. Но тут встаёт необходимость конфигурации портов и их времянок. Т.е. всё равно реализация полноценного бриджа ради немногочисленных применений. Немногочисленных из-за отсутствия поддержки виртуального COM драйверами.

[ATS]

Цитата:

Сообщение от Arsie

Безусловно соглашусь с вашей задумкой, но совсем не соглашусь с простотой реализации. Универсальных драйверов "виртуального СОМ-порта" не существует. Те же драйверы для MOXA сначала проверяют, что на том конце MOXA, передают настройки последовательного порта и лишь затем начинают транслировать трафик.

Вот теперь я вижу что с MOXA Вы не сталкивалиcь.
Никаких драйверов. Настраивается она один раз отдельно (IP, Port, параметры внешнего интерфейса) либо при желании через Telnet. Далее требуется только IP и порт для доступа к ней.

Все это реализовано во многих системах диспетчеризации.
И для доступа к приборам - только IP и порт.

Уж поверьте...

Цитата:

Сообщение от Arsie

В результате, с режимом "бридж" мы получаем бонус в виде поддержки драйверами всех операционных систем + несколько раз в год эти драйверы нужно тестировать и поддерживать из-за того, что очередная заплатка Микрософта или Касперского (Нортона, Есета, Веба и т.д.) закрывая очередную дыру в операционке блокировала работу какой-либо нужной драйверам функции.

Можно конечно кивнуть на OPC-сервер с его режимом "Modbus поверх TCP" или на ваше устройство, типа они без драйвера работают. Но тут встаёт необходимость конфигурации портов и их времянок.

Это таким образом отпадает...

Цитата:

Сообщение от Arsie

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

Совсем не соглашусь - возможны очень многочисленные.

[Arsie]

Цитата

Сообщение от ATS

Вот теперь я вижу что с MOXA Вы не сталкивалиcь.
Никаких драйверов. Настраивается она один раз отдельно (IP, Port, параметры внешнего интерфейса) либо при желании через Telnet. Далее требуется только IP и порт для доступа к ней.

Все это реализовано во многих системах диспетчеризации.
И для доступа к приборам - только IP и порт.

Уж поверьте...

Если говорить о серверах, то там как правило нет проблем выбрать нормальный Modbus-TCP. Или выбрать сервер.

Если нужен доступ ко внешнему устройству Modbus-RTU: выбрать нормальный Modbus-TCP и средствами FBD переправить поток на один или оба встроенных COM-порта, попутно получив наши штатные фенечки, которые не умеет ни один бридж - независимые скорости и форматы кадра для каждого отдельного устройства.

В итоге получаем, что бридж нужен только там, где он действительно нужен - в виртуализации СОМ-портов. Ну и в помощи устройствам, где программисты зачем-то "забыли" встроить нативный Modbus-TCP, но почему-то не забыли об инкапсуляции.

PS. Несколько MOXЛ (так на их коробках пишут - А без палки ) у меня на полке лежит. Разных

[ATS]

Цитата:

Сообщение от Arsie

Если говорить о серверах, то там как правило нет проблем выбрать нормальный Modbus-TCP. Или выбрать сервер.

Если нужен доступ ко внешнему устройству Modbus-RTU: выбрать нормальный Modbus-TCP и средствами FBD переправить поток на один или оба встроенных COM-порта, попутно получив наши штатные фенечки, которые не умеет ни один бридж - независимые скорости и форматы кадра для каждого отдельного устройства.

Это как раз замечательно!
Но это только для Modbus насколько я понимаю

Если бы все пользовались только им...

Цитата:

Сообщение от Arsie

В итоге получаем, что бридж нужен только там, где он действительно нужен - в виртуализации СОМ-портов. Ну и в помощи устройствам, где программисты зачем-то "забыли" встроить нативный Modbus-TCP, но почему-то не забыли об инкапсуляции.

К этим устройствам относятся практически все теплосчетчики.

Цитата:

Сообщение от Arsie

PS. Несколько MOXЛ (так на их коробках пишут - А без палки ) у меня на полке лежит. Разных

Уже верю.
У меня даже на столе лежат да и на объектах стоят.

Вот и хотелось заменить их и устройства с аналоговыми и дискретными входами (с Modbus) в дальнейшем на SMH 2Gi. При этом добавив за счет дисплея и обработки данных дополнительные полезняшки для заказчика.

И кстати деньги существенно экономятся.

[Arsie]

Цитата

Сообщение от ATS

К этим устройствам относятся практически все теплосчетчики.

Давайте заостримся на этой задаче.

Какие именно теплосчётчики (модели, из очень распространённых), по каким протоколам они работают и с каким софтом и как они работают?

[ATS]

Из используемых у нас:

Интелприбор - МКТС
ТБН Энерго - РМ-5, КМ-5 всех модификаций
Логика - СПТ961.2 СПГ761
Теплоком - ВКТ7

Интерфейсы RS 232 и RS485 а вот протоколы - кто во что горазд...

[Arsie]

Цитата

Сообщение от ATS

Из используемых у нас:

Интелприбор - МКТС
ТБН Энерго - РМ-5, КМ-5 всех модификаций
Логика - СПТ961.2 СПГ761
Теплоком - ВКТ7

Интерфейсы RS 232 и RS485 а вот протоколы - кто во что горазд...

Софт?

[ATS]

Цитата:

Сообщение от Arsie

Софт?

Конкретнее, что интересует. И кстати мы от темы совсем отошли

[Arsie]

Цитата

Сообщение от ATS

Конкретнее, что интересует. И кстати мы от темы совсем отошли

Как софт осуществляет доступ к этим теплосчётчикам?


PS. С темой я потом разберусь

[ATS]

Пока по CSD. Часть по сети через Моксы.

[Arsie]

Цитата

Сообщение от ATS

Пока по CSD. Часть по сети через Моксы.

CSD и Моксы - это всего лишь каналы передачи данных. Причём в случае CSD я так понимаю, что с двойной или тройной инкапсуляцией.

Меня больше интересует, как софт физически хочет работать со счётчиками.

[ATS]

Извиняюсь, работой загрузили.

Цитата:

Сообщение от Arsie

Меня больше интересует, как софт физически хочет работать со счётчиками.

Не понял. Интересуют конкретные примеры протоколов?

[Arsie]

Цитата

Сообщение от ATS

Извиняюсь, работой загрузили.



Не понял. Интересуют конкретные примеры протоколов?

Например:

Софт для счётчика рассчитан на работу с COM-портом, протокол ХХХ. Следовательно нужен драйвер, инкапсулирующий ХХХ в TCP и тогда связка Софт + драйвер + 2Gi + Теплосчётчик оказывается рабочей.

Вариант2:

Софт уже умеет отправлять XXX, инкапсулированный в протокол TCP и поэтому драйвер не нужен.

Для второго варианта нужна статистика - сколько такого софта существует и для каждого ли теплосчётчика.

[ATS]

Интересно бы найти определение этому XXX

Пример запроса текущего времени для ВКТ-7:

FF FF 00 03 3F FB 00 00 39 FE

Ну вроде совсем модбас - вот только два байта FF картинку портят, хотя и не входят в контрольную сумму

Инкапсулировать в протокол TCP может бОльшая часть софта да и драйвер не проблема.

Цитата

Если нужен доступ ко внешнему устройству Modbus-RTU: выбрать нормальный Modbus-TCP и средствами FBD переправить поток на один или оба встроенных COM-порта, попутно получив наши штатные фенечки, которые не умеет ни один бридж - независимые скорости и форматы кадра для каждого отдельного устройства.

Если можно об этом подробнее... Для начинающего.

особено в этой части: средствами FBD переправить поток на один или оба встроенных COM-порта


P.S. виноват подтормаживаю - работу никто не отменял

[Arsie]

Цитата

Сообщение от ATS

Интересно бы найти определение этому XXX

Пример запроса текущего времени для ВКТ-7:

FF FF 00 03 3F FB 00 00 39 FE

Ну вроде совсем модбас - вот только два байта FF картинку портят, хотя и не входят в контрольную сумму

Инкапсулировать в протокол TCP может бОльшая часть софта да и драйвер не проблема.

Пожалуйста, приведите примеры широко распространённого софта.

Драйвер вы под все операционки напишете и сопровоздать его тоже вы будете?

Цитата

Сообщение от ATS

Если можно об этом подробнее... Для начинающего.

особено в этой части: средствами FBD переправить поток на один или оба встроенных COM-порта


P.S. виноват подтормаживаю - работу никто не отменял

Справка - http://dl.segnetics.com/WebHelp/SMLo...ve_project.htm

Всё то же самое, только на стороне слейва вместо аппаратных входов-выходов ставите программные, т.е. переменные.

Грубо говоря, у вас получится два мастера и две сети.

[ATS]

Цитата:

Сообщение от Arsie

Драйвер вы под все операционки напишете и сопровоздать его тоже вы будете?

Мы говорим про ХХХ в ТСР? Этого добра сколько угодно...
Или желаем перекодировать в Modbus TCP?

Цитата

Справка - http://dl.segnetics.com/WebHelp/SMLo...ve_project.htm

Всё то же самое, только на стороне слейва вместо аппаратных входов-выходов ставите программные, т.е. переменные.

Грубо говоря, у вас получится два мастера и две сети.

Зто же не перенаправление потока - просто передача в обе стороны заданного числа переменных. Даже если в теплосчетчике стандартный
модбас счет переменных может идти на сотни. А зачастую просто неизвестно какие данные может запросить стандартный софт.