Segnetics

Вернуться   Segnetics > Форум Segnetics > Вопросы о SMH-2G(i)

Вопросы о SMH-2G(i) Здесь всё, что касается работы контроллера SMH-2G(i).

Ответ
 
Опции темы Поиск в этой теме Опции просмотра
Старый 07.08.2013, 12:07   #1
ATS
Senior Member
 
Регистрация: Aug 2013
Сообщения: 3 740
Благодарил(а): 12 раз(а)
Поблагодарили: 192 раз(а) в 188 сообщениях
По умолчанию Модбас через TCP

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

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

В чем может быть проблема?
ATS вне форума   Ответить с цитированием
Старый 07.08.2013, 13:04   #2
Arsie
Сотрудник Segnetics
 
Аватара для Arsie
 
Регистрация: Jan 2006
Адрес: Russia, SPb
Сообщения: 18 019
Благодарил(а): 15 раз(а)
Поблагодарили: 655 раз(а) в 599 сообщениях
По умолчанию Ответ: Модбас через TCP

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

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

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

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


__________________
Программа делает то что написал программист, а не то что он хотел.

Добро всегда побеждает зло. Кто победил - тот и добрый.
Arsie вне форума   Ответить с цитированием
Старый 07.08.2013, 14:14   #3
ATS
Senior Member
 
Регистрация: Aug 2013
Сообщения: 3 740
Благодарил(а): 12 раз(а)
Поблагодарили: 192 раз(а) в 188 сообщениях
По умолчанию Ответ: Модбас через TCP

Цитата:
Сообщение от Arsie Посмотреть сообщение
Думаю, проблема в "виртуальном СОМ порту".
Это исключено - с программой VSPE (Virtual Serial Ports Emulator) работаю давно. Да и устройство давно опробовано. И то и другое без проблем работают по TCP с MOXA DE-311.

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

Последний раз редактировалось Arsie, 07.08.2013 в 15:50
ATS вне форума   Ответить с цитированием
Старый 07.08.2013, 15:39   #4
Arsie
Сотрудник Segnetics
 
Аватара для Arsie
 
Регистрация: Jan 2006
Адрес: Russia, SPb
Сообщения: 18 019
Благодарил(а): 15 раз(а)
Поблагодарили: 655 раз(а) в 599 сообщениях
По умолчанию Ответ: Модбас через TCP

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

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


__________________
Программа делает то что написал программист, а не то что он хотел.

Добро всегда побеждает зло. Кто победил - тот и добрый.
Arsie вне форума   Ответить с цитированием
Старый 07.08.2013, 16:34   #5
ATS
Senior Member
 
Регистрация: Aug 2013
Сообщения: 3 740
Благодарил(а): 12 раз(а)
Поблагодарили: 192 раз(а) в 188 сообщениях
По умолчанию Ответ: Модбас через TCP

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

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

Должен ли контроллер работать в режиме Modbus через TCP?
Или наличие контрольной суммы в исходном пакете сбивает его с толку?
ATS вне форума   Ответить с цитированием
Старый 07.08.2013, 16:39   #6
Arsie
Сотрудник Segnetics
 
Аватара для Arsie
 
Регистрация: Jan 2006
Адрес: Russia, SPb
Сообщения: 18 019
Благодарил(а): 15 раз(а)
Поблагодарили: 655 раз(а) в 599 сообщениях
По умолчанию Ответ: Модбас через TCP

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

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

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


__________________
Программа делает то что написал программист, а не то что он хотел.

Добро всегда побеждает зло. Кто победил - тот и добрый.

Последний раз редактировалось Arsie, 07.08.2013 в 17:01
Arsie вне форума   Ответить с цитированием
Старый 07.08.2013, 17:32   #7
ATS
Senior Member
 
Регистрация: Aug 2013
Сообщения: 3 740
Благодарил(а): 12 раз(а)
Поблагодарили: 192 раз(а) в 188 сообщениях
По умолчанию Ответ: Модбас через TCP

Цитата:
Сообщение от 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
ATS вне форума   Ответить с цитированием
Старый 07.08.2013, 17:38   #8
Arsie
Сотрудник Segnetics
 
Аватара для Arsie
 
Регистрация: Jan 2006
Адрес: Russia, SPb
Сообщения: 18 019
Благодарил(а): 15 раз(а)
Поблагодарили: 655 раз(а) в 599 сообщениях
По умолчанию Ответ: Модбас через TCP

Цитата
Сообщение от 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", я всё правильно понимаю?


__________________
Программа делает то что написал программист, а не то что он хотел.

Добро всегда побеждает зло. Кто победил - тот и добрый.
Arsie вне форума   Ответить с цитированием
Старый 07.08.2013, 17:56   #9
ATS
Senior Member
 
Регистрация: Aug 2013
Сообщения: 3 740
Благодарил(а): 12 раз(а)
Поблагодарили: 192 раз(а) в 188 сообщениях
По умолчанию Ответ: Модбас через TCP

Цитата:
Сообщение от Arsie Посмотреть сообщение
Т.е. порт 502, правильно?

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

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

в поле данных
адрес slave | код функции | данные | контрольная сумма
ATS вне форума   Ответить с цитированием
Старый 07.08.2013, 18:04   #10
Arsie
Сотрудник Segnetics
 
Аватара для Arsie
 
Регистрация: Jan 2006
Адрес: Russia, SPb
Сообщения: 18 019
Благодарил(а): 15 раз(а)
Поблагодарили: 655 раз(а) в 599 сообщениях
По умолчанию Ответ: Модбас через TCP

Цитата
Сообщение от 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?


__________________
Программа делает то что написал программист, а не то что он хотел.

Добро всегда побеждает зло. Кто победил - тот и добрый.
Arsie вне форума   Ответить с цитированием
Старый 08.08.2013, 00:21   #11
ATS
Senior Member
 
Регистрация: Aug 2013
Сообщения: 3 740
Благодарил(а): 12 раз(а)
Поблагодарили: 192 раз(а) в 188 сообщениях
По умолчанию Ответ: Модбас через TCP

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

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

Нажмите на картинку для увеличения

Название:  Untitled.png
Просмотров: 159
Размер:  3.6 Кбайт Нажмите на картинку для увеличения

Название:  Untitled1.png
Просмотров: 125
Размер:  2.6 Кбайт

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

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

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

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

Поле контрольной суммы в Modbus TCP отсутствует.
ATS вне форума   Ответить с цитированием
Старый 08.08.2013, 00:56   #12
ATS
Senior Member
 
Регистрация: Aug 2013
Сообщения: 3 740
Благодарил(а): 12 раз(а)
Поблагодарили: 192 раз(а) в 188 сообщениях
По умолчанию Ответ: Модбас через TCP

Итак

Соединимся с контроллером
Нажмите на картинку для увеличения

Название:  Untitled3.png
Просмотров: 219
Размер:  9.5 Кбайт (порт совсем не обязательно 502)

Запросим 01 04 00 02 00 10 с контрольной суммой
Нажмите на картинку для увеличения

Название:  Untitled2.png
Просмотров: 139
Размер:  12.1 Кбайт - нет ответа


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

Нажмите на картинку для увеличения

Название:  Untitled4.png
Просмотров: 156
Размер:  13.5 Кбайт и вот он ответик долгожданный

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

Последний раз редактировалось ATS, 08.08.2013 в 01:18
ATS вне форума   Ответить с цитированием
Старый 08.08.2013, 10:22   #13
Arsie
Сотрудник Segnetics
 
Аватара для Arsie
 
Регистрация: Jan 2006
Адрес: Russia, SPb
Сообщения: 18 019
Благодарил(а): 15 раз(а)
Поблагодарили: 655 раз(а) в 599 сообщениях
По умолчанию Ответ: Модбас через TCP

Цитата
Сообщение от 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 пока не поддерживает
Этот же вывод можно было сделать просто прочитав описание контроллера


__________________
Программа делает то что написал программист, а не то что он хотел.

Добро всегда побеждает зло. Кто победил - тот и добрый.

Последний раз редактировалось Arsie, 08.08.2013 в 10:33
Arsie вне форума   Ответить с цитированием
Старый 08.08.2013, 11:32   #14
ATS
Senior Member
 
Регистрация: Aug 2013
Сообщения: 3 740
Благодарил(а): 12 раз(а)
Поблагодарили: 192 раз(а) в 188 сообщениях
По умолчанию Ответ: Модбас через TCP

Цитата:
Сообщение от 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.

Это однако будет продаваемо.
ATS вне форума   Ответить с цитированием
Старый 08.08.2013, 11:48   #15
Arsie
Сотрудник Segnetics
 
Аватара для Arsie
 
Регистрация: Jan 2006
Адрес: Russia, SPb
Сообщения: 18 019
Благодарил(а): 15 раз(а)
Поблагодарили: 655 раз(а) в 599 сообщениях
По умолчанию Ответ: Модбас через TCP

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

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

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

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

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


__________________
Программа делает то что написал программист, а не то что он хотел.

Добро всегда побеждает зло. Кто победил - тот и добрый.
Arsie вне форума   Ответить с цитированием
Старый 08.08.2013, 12:25   #16
ATS
Senior Member
 
Регистрация: Aug 2013
Сообщения: 3 740
Благодарил(а): 12 раз(а)
Поблагодарили: 192 раз(а) в 188 сообщениях
По умолчанию Ответ: Модбас через TCP

Цитата:
Сообщение от Arsie Посмотреть сообщение
Безусловно соглашусь с вашей задумкой, но совсем не соглашусь с простотой реализации. Универсальных драйверов "виртуального СОМ-порта" не существует. Те же драйверы для MOXA сначала проверяют, что на том конце MOXA, передают настройки последовательного порта и лишь затем начинают транслировать трафик.
Вот теперь я вижу что с MOXA Вы не сталкивалиcь.
Никаких драйверов. Настраивается она один раз отдельно (IP, Port, параметры внешнего интерфейса) либо при желании через Telnet. Далее требуется только IP и порт для доступа к ней.

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

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


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

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

Цитата:
Сообщение от Arsie Посмотреть сообщение
Т.е. всё равно реализация полноценного бриджа ради немногочисленных применений. Немногочисленных из-за отсутствия поддержки виртуального COM драйверами.
Совсем не соглашусь - возможны очень многочисленные.
ATS вне форума   Ответить с цитированием
Старый 08.08.2013, 12:32   #17
Arsie
Сотрудник Segnetics
 
Аватара для Arsie
 
Регистрация: Jan 2006
Адрес: Russia, SPb
Сообщения: 18 019
Благодарил(а): 15 раз(а)
Поблагодарили: 655 раз(а) в 599 сообщениях
По умолчанию Ответ: Модбас через TCP

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

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

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

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

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

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


__________________
Программа делает то что написал программист, а не то что он хотел.

Добро всегда побеждает зло. Кто победил - тот и добрый.
Arsie вне форума   Ответить с цитированием
Старый 08.08.2013, 13:20   #18
ATS
Senior Member
 
Регистрация: Aug 2013
Сообщения: 3 740
Благодарил(а): 12 раз(а)
Поблагодарили: 192 раз(а) в 188 сообщениях
По умолчанию Ответ: Модбас через TCP

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

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

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

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

Цитата:
Сообщение от Arsie Посмотреть сообщение
PS. Несколько MOXЛ (так на их коробках пишут - А без палки ) у меня на полке лежит. Разных
Уже верю.
У меня даже на столе лежат да и на объектах стоят.

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

И кстати деньги существенно экономятся.
ATS вне форума   Ответить с цитированием
Старый 08.08.2013, 13:24   #19
Arsie
Сотрудник Segnetics
 
Аватара для Arsie
 
Регистрация: Jan 2006
Адрес: Russia, SPb
Сообщения: 18 019
Благодарил(а): 15 раз(а)
Поблагодарили: 655 раз(а) в 599 сообщениях
По умолчанию Ответ: Модбас через TCP

Цитата
Сообщение от ATS Посмотреть сообщение
К этим устройствам относятся практически все теплосчетчики.
Давайте заостримся на этой задаче.

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


__________________
Программа делает то что написал программист, а не то что он хотел.

Добро всегда побеждает зло. Кто победил - тот и добрый.
Arsie вне форума   Ответить с цитированием
Старый 08.08.2013, 13:33   #20
ATS
Senior Member
 
Регистрация: Aug 2013
Сообщения: 3 740
Благодарил(а): 12 раз(а)
Поблагодарили: 192 раз(а) в 188 сообщениях
По умолчанию Ответ: Модбас через TCP

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

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

Интерфейсы RS 232 и RS485 а вот протоколы - кто во что горазд...
ATS вне форума   Ответить с цитированием
Старый 08.08.2013, 13:40   #21
Arsie
Сотрудник Segnetics
 
Аватара для Arsie
 
Регистрация: Jan 2006
Адрес: Russia, SPb
Сообщения: 18 019
Благодарил(а): 15 раз(а)
Поблагодарили: 655 раз(а) в 599 сообщениях
По умолчанию Ответ: Модбас через TCP

Цитата
Сообщение от ATS Посмотреть сообщение
Из используемых у нас:

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

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


__________________
Программа делает то что написал программист, а не то что он хотел.

Добро всегда побеждает зло. Кто победил - тот и добрый.
Arsie вне форума   Ответить с цитированием
Старый 08.08.2013, 13:53   #22
ATS
Senior Member
 
Регистрация: Aug 2013
Сообщения: 3 740
Благодарил(а): 12 раз(а)
Поблагодарили: 192 раз(а) в 188 сообщениях
По умолчанию Ответ: Модбас через TCP

Цитата:
Сообщение от Arsie Посмотреть сообщение
Софт?
Конкретнее, что интересует. И кстати мы от темы совсем отошли
ATS вне форума   Ответить с цитированием
Старый 08.08.2013, 13:57   #23
Arsie
Сотрудник Segnetics
 
Аватара для Arsie
 
Регистрация: Jan 2006
Адрес: Russia, SPb
Сообщения: 18 019
Благодарил(а): 15 раз(а)
Поблагодарили: 655 раз(а) в 599 сообщениях
По умолчанию Ответ: Модбас через TCP

Цитата
Сообщение от ATS Посмотреть сообщение
Конкретнее, что интересует. И кстати мы от темы совсем отошли
Как софт осуществляет доступ к этим теплосчётчикам?


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


__________________
Программа делает то что написал программист, а не то что он хотел.

Добро всегда побеждает зло. Кто победил - тот и добрый.
Arsie вне форума   Ответить с цитированием
Старый 08.08.2013, 15:30   #24
ATS
Senior Member
 
Регистрация: Aug 2013
Сообщения: 3 740
Благодарил(а): 12 раз(а)
Поблагодарили: 192 раз(а) в 188 сообщениях
По умолчанию Ответ: Модбас через TCP

Пока по CSD. Часть по сети через Моксы.
ATS вне форума   Ответить с цитированием
Старый 08.08.2013, 15:55   #25
Arsie
Сотрудник Segnetics
 
Аватара для Arsie
 
Регистрация: Jan 2006
Адрес: Russia, SPb
Сообщения: 18 019
Благодарил(а): 15 раз(а)
Поблагодарили: 655 раз(а) в 599 сообщениях
По умолчанию Ответ: Модбас через TCP

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

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


__________________
Программа делает то что написал программист, а не то что он хотел.

Добро всегда побеждает зло. Кто победил - тот и добрый.
Arsie вне форума   Ответить с цитированием
Старый 09.08.2013, 13:39   #26
ATS
Senior Member
 
Регистрация: Aug 2013
Сообщения: 3 740
Благодарил(а): 12 раз(а)
Поблагодарили: 192 раз(а) в 188 сообщениях
По умолчанию Ответ: Модбас через TCP

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

Цитата:
Сообщение от Arsie Посмотреть сообщение
Меня больше интересует, как софт физически хочет работать со счётчиками.
Не понял. Интересуют конкретные примеры протоколов?
ATS вне форума   Ответить с цитированием
Старый 09.08.2013, 14:14   #27
Arsie
Сотрудник Segnetics
 
Аватара для Arsie
 
Регистрация: Jan 2006
Адрес: Russia, SPb
Сообщения: 18 019
Благодарил(а): 15 раз(а)
Поблагодарили: 655 раз(а) в 599 сообщениях
По умолчанию Ответ: Модбас через TCP

Цитата
Сообщение от ATS Посмотреть сообщение
Извиняюсь, работой загрузили.



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

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

Вариант2:

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

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


__________________
Программа делает то что написал программист, а не то что он хотел.

Добро всегда побеждает зло. Кто победил - тот и добрый.
Arsie вне форума   Ответить с цитированием
Старый 09.08.2013, 15:13   #28
ATS
Senior Member
 
Регистрация: Aug 2013
Сообщения: 3 740
Благодарил(а): 12 раз(а)
Поблагодарили: 192 раз(а) в 188 сообщениях
По умолчанию Ответ: Модбас через TCP

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

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

FF FF 00 03 3F FB 00 00 39 FE

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

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

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

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


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

Последний раз редактировалось ATS, 09.08.2013 в 15:34
ATS вне форума   Ответить с цитированием
Старый 09.08.2013, 15:49   #29
Arsie
Сотрудник Segnetics
 
Аватара для Arsie
 
Регистрация: Jan 2006
Адрес: Russia, SPb
Сообщения: 18 019
Благодарил(а): 15 раз(а)
Поблагодарили: 655 раз(а) в 599 сообщениях
По умолчанию Ответ: Модбас через TCP

Цитата
Сообщение от 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

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

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


__________________
Программа делает то что написал программист, а не то что он хотел.

Добро всегда побеждает зло. Кто победил - тот и добрый.
Arsie вне форума   Ответить с цитированием
Старый 09.08.2013, 16:32   #30
ATS
Senior Member
 
Регистрация: Aug 2013
Сообщения: 3 740
Благодарил(а): 12 раз(а)
Поблагодарили: 192 раз(а) в 188 сообщениях
По умолчанию Ответ: Модбас через TCP

Цитата:
Сообщение от Arsie Посмотреть сообщение
Драйвер вы под все операционки напишете и сопровоздать его тоже вы будете?
Мы говорим про ХХХ в ТСР? Этого добра сколько угодно...
Или желаем перекодировать в Modbus TCP?


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

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

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

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать темы
Вы не можете отвечать на сообщения
Вы не можете прикреплять файлы
Вы не можете редактировать свои сообщения

BB code is Вкл.
[IMG] код Вкл.
HTML код Выкл.


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Ошибка связи по TCP Modbus через интернет АндрейЛ Связь с внешним миром 1 25.12.2015 09:24
SMH-2Gi as a TCP server / TCP client sensei Вопросы о SMH-2G(i) 2 12.02.2015 15:03
Modbus TCP alexay_1985 Связь с внешним миром 1 03.04.2014 10:48
Загрузка программ через RS-485. Почему может быть неустойчивой или невозможной Arsie Библиотека 1 10.07.2013 09:57
Работа Пикселя в Модбас на больших расстояниях Рерих Связь с внешним миром 5 28.05.2009 20:46


Часовой пояс GMT +4, время: 23:50.


Версия vBulletin: 3.8.3
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Segnetics 2005 - 2023