Нужна помощь!!!

[LoginovAD]

Связь оказалась не самой трудной проблемой:)) Вот столкнулся довольно странной ситуацией, в документации к прибору приведен пример запроса по протоколу модбас аски: 3А 30 33 31 44 32 34 30 30 30 34 42 38 0D 0A. При попытки отправить этот запрос получаю ошибку кода функции, независимо какой прогой отправляю.
Вот расшифровка фрэйма аски: 1 символ старт; 2 символа адрес сегмента "1D"; 2 символа смещение сегмента, стартовый адрес данных "24"; 2 символасмещение в структыре данных; 2 символа сетчик байт; 2 символа контрольная сумма; и последние 2 символа конец. Ответ должен по идеи повторять часть запроса, согласно документации это старт, адрес, код функции, смещение и счетчик байт, дальше уже запрашиваемые данные. Так в примере запроса я что то не могу найти код функции или я не туда смотрю %)

[Ryzhij]

По-моему, Вы пытаетесь к посылку MODBUS-ASCII загнать в сеть MODBUS-RTU...

[MuadDib]

Связь оказалась не самой трудной проблемой:)) Вот столкнулся довольно странной ситуацией, в документации к прибору приведен пример запроса по протоколу модбас аски: 3А 30 33 31 44 32 34 30 30 30 34 42 38 0D 0A. При попытки отправить этот запрос получаю ошибку кода функции, независимо какой прогой отправляю.
Вот расшифровка фрэйма аски: 1 символ старт; 2 символа адрес сегмента "1D"; 2 символа смещение сегмента, стартовый адрес данных "24"; 2 символасмещение в структыре данных; 2 символа сетчик байт; 2 символа контрольная сумма; и последние 2 символа конец. Ответ должен по идеи повторять часть запроса, согласно документации это старт, адрес, код функции, смещение и счетчик байт, дальше уже запрашиваемые данные. Так в примере запроса я что то не могу найти код функции или я не туда смотрю %)

Вы неправильно интерпретируете код запроса. В виде строки он будет такой:

Код: Выделить всё

":031D240004B8\r\n"

Получается: 0х03 - адрес устройства (фиксированный адрес 3, как вы сообщали раньше), 0x1D - код функции, 0x2400 - адрес начального регистра, передаваемый начиная со старшего байта, 0x04 - количество регистров (соответственно, в ответе будет 8 байт данных, для передачи которых в ASCII потребуется 16 символов), 0xB8 - контрольная сумма, \r\n - завершающая последовательность из <CR> <LF>.

Расшифровку я привел формальную (по аналогии с функциями 0x03, 0x04), поскольку в стандарте функция 0x1D не описана. Видимо, именно поэтому вы получаете ошибку кода функции.

Рекомендую уточнить правильность приведенного в документации запроса: от производителя, выпускающего на рынок прибор, у которого нельзя менять адрес Modbus, можно ждать каких угодно косяков. Скорее всего, в запросе должна быть функция 0x03 или 0x04.

[LoginovAD]

Довольно интересная ситуация, что в девайсе применили не стандартный протокол, вот думаю использовать софтинку для сбора данных http://www.lectussoft.com/opcserver.html посмотрел что там можно запросы составлять самому, завтро попробую отпишусь.

[MuadDib]

Довольно интересная ситуация, что в девайсе применили не стандартный протокол, вот думаю использовать софтинку для сбора данных http://www.lectussoft.com/opcserver.html посмотрел что там можно запросы составлять самому, завтро попробую отпишусь.

Что дает вам основание полагать что производитель применил нестандартный протокол? Пример запроса из документации? Но вы же сами пишете, что в ответ на него вы получаете ошибку кода функции. Возможно, девайс ждет стандартной команды, а вы посылаете ему непонятную строку, включенную кем-то в инструкцию по пьяни :D У вас вообще есть предоставленная производителем карта адресов Modbus? В карте должны быть четко указаны и адреса регистров с данными, и код функции, который следует использовать. Вы пробовали читать обычные регистры (holding register, input register)?

[LoginovAD]

В том то и дело что я пытался считать обычные регистры стандартными функциями и получал ошибку.

[Никита]

Что дает вам основание полагать что производитель применил нестандартный протокол?

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

[LoginovAD]

Все таки протокол был не стандартный, с помощью Lectus Modbus OPC/DDE сервера смог вытащить данные используя пример из документации. Большое всем спасибо!!! Никита, родного софта не было, все что имелось так это прибор и документация, от завода изготовителя ничего кроме руководства и совета прислать приборы к ним на прошивку ничего не добиться

[Naitek]

MuadDib как вы интересно перевели строку 3А 30 33 31 44 32 34 30 30 30 34 42 38 0D 0A в ":031D240004B8\r\n"? У меня видимо что-то со связью с прибором, поскольку отправляю эту строку прибору, а в ответ тишина

[Владимир Кузнецов]

MuadDib как вы интересно перевели строку 3А 30 33 31 44 32 34 30 30 30 34 42 38 0D 0A в ":031D240004B8\r\n"? У меня видимо что-то со связью с прибором, поскольку отправляю эту строку прибору, а в ответ тишина

В шестнадцатеричном виде отправляйте, \r и \n это спец символы.

[MuadDib]

MuadDib как вы интересно перевели строку 3А 30 33 31 44 32 34 30 30 30 34 42 38 0D 0A в ":031D240004B8\r\n"? У меня видимо что-то со связью с прибором, поскольку отправляю эту строку прибору, а в ответ тишина

Как уже подсказал Владимир, ":031D240004B8\r\n" - это строка ASCII-символов, представленная в виде литерала языка Си. '\r' - это символ "возврата каретки" (CR), численно равен 13 в десятичной системе, 0x0d - в шестнадцатеричной. '\n' - символ "новой строки" (LF), 10 в десятичной, 0x0a - в хексе. Если подходить к вопросу строго, Си-строка будет иметь один дополнительный символ в конце, равный нулю, но к данному топику эта особенность не имеет никакого отношения.

Еще раз повторю, что код функции 0x1d нестандартный и, видимо, реализован конкретно в приборе, с которым разбирался LoginovAD. Прежде чем копать дальше, убедитесь в следующем:
1. Прибор поддерживает функцию Модбас 0x1d.
2. Прибор имеет адрес Модбас, равный 0x03, и в сети модбас отсутствует другой прибор с таким же адресом
3. Прибор поддерживает Modbus ASCII. Большая часть Модбас-устройств по дефолту работают в режиме Modbus RTU, но некоторые могут работать и как Modbus ASCII после переключения из настроек прибора.
4. Настройки последовательного интерфейса (скорость, число бит, число стоп-бит, контроль четности) на мастере и на приборе совпадают.

[Naitek]

В том то и дело, что всё взято из инструкции к прибору и строка 3A 1D 24 00 04 B8 0D 0A приведена там в качестве примера как получить с него данные. Но только вот в ответ на эту строку прибор ничего не посылает.
Код функции я понимаю что нестандартный, уже работал с протоколами ModBus.
П.С.:прибор тот же, БОЗНА НОРД-Э3М.

[MuadDib]

В том то и дело, что всё взято из инструкции к прибору и строка 3A 1D 24 00 04 B8 0D 0A приведена там в качестве примера как получить с него данные. Но только вот в ответ на эту строку прибор ничего не посылает.
Код функции я понимаю что нестандартный, уже работал с протоколами ModBus.
П.С.:прибор тот же, БОЗНА НОРД-Э3М.

В таком случае вам следовало адресовать вопрос LoginovAD. В последнем сообщении здесь он указал, что связи добиться удалось, но подробностями не поделился.

[Naitek]

LoginovAD, адресую вопрос вам - огромная просьба подсказать как вы добились связи с прибором? Буду очень благодарен за помощь!

[LoginovAD]

Ну если все настройки COM-порта верны и установлен рабочий преобразователь интерфейса, то ответ должен идти, проблема может быть в железе тупо. И еще есть один момент - какой софт используете если не секрет? Мне пришлось еще не много покапаться в настройках софта Lectus ModBus OPC я брал такую программулинку.
Вот как я делал настройку: В связи с тем что в устройстве применен был не стандартный протокол модбас, пришлось применить не стандартный сервер OPC-ModBus. Посоветую использовать Lectus Modbus OPC-DDE server, в данной проге имеется возможность построения свободного модбас запроса для устройства.
В запросе указать адрес 03, команда чтения 1D, дальше адрес данных в соответствии с картой памяти из РЭ 24 00(для мгновенного расхода) 24 04(для накопленного объема) если мне память не изменяет, в конце запроса идет счетчик байт 04.
получаем запрос :03 1D 24 00 04 двоеточие это старт передачи в формате ASCII его не нужно в принципе ставить, софт сам это сделает.
Еще необходимо правильно настроить софт, то есть поставить протокол ASCII, и когда создаешь переменные с произвольным запросом обязательно указать стартовый байт данных на примере ответ будет выглядеть так 03 1D 24 00 04 05 30 05... то есть данные начинаются с 05...
Ну вроде как все. Будут еще вопросы рад буду помочь.

[Naitek]

У нас есть такое устройство NPORT 5150, так вот с его помощью я создал виртуальный COM-порт, при этом работающий по интерфейсу RS485. Потестировал его на устройстве, работающим по протоколу Modbus RTU, т.е. брал и прогой отправлял обычный запрос на чтение, прибор нормально отвечал.
Подключил НОРД. Отправляю этой прогой запрос приведенный в паспорте - то есть 3A 1D 24 00 04 B8 0D 0A. В ответ - тишина. Вот сижу и не понимаю в чем может быть дело.

[LoginovAD]

А не пробовал отправлять запрос без контрольной сумм, может твоя прога ставит КС сама, тогда прибор может не понять запрос. Я сталкивался с такой фигней у меня не получалось получить ответ используя трайком, хотя софтинка позволяет отправлять произвольные запросы. Сейчас вернусь на работу и посмотрю как у меня там сделано, на память уже не помню, но какие то нюансы были. Если не секрет какой прогой пользуешься?

[LoginovAD]

Посмотрел сейчас конфигурации у себя, команды на чтение :03 1D 24 00 04 и :03 1D 24 04 04 контрольную сумму выставляет софт. Тип данных Single Float 4 байта.
На мой взгляд проблема заключается в том что софт не понимает команду 1D как получилось у меня в трайкоме, либо в запросе прописана КС как в документации и плюс на все это добро софт еще свою КС добавляет. Но это пока только мои мысли. Хотелось бы посмотреть скриншоты запросов. А настройки самого порта оставил стандартные. Если один девайс отвечал с настройками как у БОЗНЫ, то проблема в софте.

[Naitek]

Буду очень благодарен, если вы скинете мне файлик конфигурации Config.cfg для Lectus Modbus OPC/DDE Server. Найти его можно нажав Конфигурация->Открыть. Нет, у БОЗНЫ протокол измененный Modbus ASCII, а у того прибора Modbus RTU, поэтому я и не могу понять в чем причина :(
Для связи с приборами использовал программку MBTest http://cedarlab.ru/software.html.

[LoginovAD]

Ммм... MbTest работает с RTU а ASCII не понимает, поэтому ничего не получается. Куда отправить файл конфигурации?

[Naitek]

Отправьте на

[+]

[email protected]

[LoginovAD]

naitek, файлег отправил. Будут вопросы пиши

[Naitek]

Огромное спасибо за помощь! Все отлично читается)))

[Kayon]

Ммм... MbTest работает с RTU а ASCII не понимает, поэтому ничего не получается. Куда отправить файл конфигурации?

Являюсь разработчиком MBTest'a. ASCII устройств под рукой не было, но можно реализовать поддержку. Если есть возможность и желание, смогу выслать потестировать вариант с поддержкой ASCII.

[LoginovAD]

Ммм... MbTest работает с RTU а ASCII не понимает, поэтому ничего не получается. Куда отправить файл конфигурации?

Являюсь разработчиком MBTest'a. ASCII устройств под рукой не было, но можно реализовать поддержку. Если есть возможность и желание, смогу выслать потестировать вариант с поддержкой ASCII.

Желание есть, возможность тоже есть...
отправляйте на [email protected]