Диагностика сети RS-485 дубль 3

[Kaskad11]

Всем добра!
Что б не плодить темы напишу здесь, вопрос как раз по диагностике сети.
Имеем 3 слейва и мастер. Сеть на столе, расстояние между устройствами 30-40 см., Modbus RTU 19200. Все устройства "сидят" непосредственно на шине, никаких отводов.
Условно назовём слейвы А=01, В=02, С=03. Мастер их опрашивает, но отвечает только А. Была идея, что по какой то причине мастер не выдает для остальных запросы. Менял адреса, без толку, всё равно отвечает только А. Отключаю мастер, подключаюсь к шине через переходник USB-RS485 - все слейвы отвечают. Что может быть?

[Ryzhij]

Отключаю мастер, подключаюсь к шине через переходник USB-RS485 - все слейвы отвечают. Что может быть?

Вангую, что мастер слишком часто шлёт свои запросы. Дело может быть в настройках времени паузы и ожидания.

[Sergey_P]

Соберите сеть с мастером, подключитесь к ней параллельно через преобразователь RS485/USB и запустите на компьютере программу из этой темы:
viewtopic.php?f=250&t=14510
Покажите лог и я уверен, что мы найдем причину.

[Kaskad11]

Ryzhij, мастер не имеет настроек связи. Они установлены программно и не меняются.
Sergey_P, сейчас попробую. По указанной схеме я подключался программой ComRead но она, почему то, писала только ответы от слейва, запросов мастера не показывает.

Отправлено спустя 23 минуты 47 секунд:
Вот лог.

[Sergey_P]

Kaskad11, над логами мне нужно еще немного поразмышлять, а пока вопросы:

1) С настройками контроля четности все правильно? На компьютере задано EVEN, в мастере и слейвах так-же?

2) Должен ли мастер слать этот запрос:

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

01 03 02 01 3b f8 07

это чтение HR начиная с адреса 513 (0x201), количество 59 (0x3b)

Этот запрос правильный (CRC совпадает), но sniffer его почему-то считает неправильным (Unknown data). Я попытаюсь понять, почему так.

В логах я не увидел ответов от слейвов. На самом деле они что-то отвечали?

[Kaskad11]

Sergey_P, я на понедельник подготовлю все ответы и дам логи опросов другими программами и пояснения. Сейчас немного занят.

Отправлено спустя 10 минут 40 секунд:
При таких настройках на экран ничего не показывает, а лог пишет.

Отправлено спустя 2 минуты 47 секунд:
А как остановить работу скрипта? Просто закрываем командную строку?

Отправлено спустя 18 минут 52 секунды:
Вот уставки слейва.

Отправлено спустя 2 минуты 53 секунды:
Все слейвы одинаковые.

[Jackson]

мастер не имеет настроек связи. Они установлены программно и не меняются

Это проблемы мастера.

[Sergey_P]

Насколько я понял, в мастер "зашиты" настройки 19200-8-EVEN-1 и эти-же настройки заданы в слейвах.
Т.е. вроде-бы все правильно.

Пока по логам видно, что мастер ведет себя "странно". Он многократно шлет неправильный запрос (01 03 02 01 3a 39 c7) и каждый раз ждет ответа примерно по 700 мс (это нормальный таймаут).
В этом запросе не хватает одного байта. Количество запрашиваемых регистров (0x3a) задано одним байтом, а должно быть два.
Поэтому и sniffer этот запрос трактует как мусор.
При этом удивительно, что контрольная сумма совпадает. Т.е. запрос изначально сформирован неправильно где-то в прикладной программе мастера. Совпадение контрольной суммы меня сбило с толку.

Потом в логе появляется правильный запрос:
03 03 00 0a 00 01 a5 ea
Это - чтение регистра 10 (температура) из слейва № 3.
Но ответа на этот запрос мастер ждет всего 60 мс и потом шлет следующий запрос. Слейвы ничего ответить не успевают.
Я думаю, надо для начала увеличить таймаут в мастере (минимум 300 мс) и понять откуда берется неправильный запрос.

Хотелось бы знать, что там за мастер. Может, это натолкнет на какие-то идеи.

Отправлено спустя 39 минут 18 секунд:
Кстати есть классная онлайн-утилита для проверки modbus-пакетов. Незаменимая вещь, если нужно убедить программиста, что его творение формирует неправильные запросы
http://rapidscada.net/modbus/ModbusParser.aspx

[Kaskad11]

Вот опрос слейвов програмой ModbusPoll. Всё ОК. Файл Adres123.txt

Отправлено спустя 39 минут 59 секунд:
В лог-файлы записал комментарии, может так будет проще. ID:1-4 - только опрос, ID:5-8 - опрос и запись.
Только сейчас пришла в голову мысль - а что, если БП гонит помеху по питанию и мастер начинает дурить? В понедельник надо будет от аккумуляторов питание подать, что б уже наверняка.

[Sergey_P]

С ModbusPoll все работает потому, что он шлет правильные запросы.

А вот с мастером явно что-то не так.
Блок питания здесь не при чем. Если бы он давал помехи, то в логах были бы случайные байты. А там повторяющаяся последовательность одних и тех-же пакетов.

Я не могу понять: если питание выключили, то кто шлет запросы?
Вот кусок из файла modbus1-log.txt:

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

...
00:00:29.590 - Unknown data: 01     <-- Это неправильный запрос с правильной контрольной суммой (запросов было много)
00:00:29.590 - Unknown data: 03
00:00:29.590 - Unknown data: 02
00:00:29.590 - Unknown data: 01
00:00:29.590 - Unknown data: 3b
00:00:29.590 - Unknown data: f8
00:00:29.590 - Unknown data: 07

Выключил питание схемы!!!!!

00:00:30.054 - Request: 08 04 d0 10 00 01 08 56                                     <--  Откуда эти запросы?
00:00:30.054 - ID: 8, Fn: 4 (Read IR), addr: 53264, count: 1, CRC: 0x5608

00:00:30.118 - Request: 08 06 d0 01 00 00 e0 53
00:00:30.118 - ID: 8, Fn: 6 (Write Single HR), addr: 53249, value: 0, CRC: 0x53e0
...

После выключения питания как раз и начинают идти правильные запросы. Только промежуток времени между ними маленький слишком. Мастер посылает новый запрос, подождав всего 70 мс.

Натравите мастера на симулятор https://sourceforge.net/projects/modrssim2/files/ через RS485/USB (компьютер будет в роли слейвов). Там в правом нижнем углу есть кнопка Comms - она откроет закладку с логом пакетов.

[Kaskad11]

Много неправильных запросов - это при включенном питании.
Когда БП выключается напряжение проседает но какое то время ещё есть (разряд выходных конденсаторов). Именно в этот момент мастер и шлёт правильные запросы. Чертовщина какая то.
В понедельник возьму другой мастер и попробую с ним работать.

[Sergey_P]

Так что там за мастер все-таки?

Если это какой-то общедоступный контроллер, то сообщите его модель. Может и другие сталкивались с такими проблемами.

Если мастер самодельный, то могу дать два совета:
1) Сигнал "включение передачи" на приемопередатчике RS485 должен быть подтянут к логическому нулю при выключенном процессоре. Если этого не сделать - при включении устройства оно будет "мусорить" в сеть пока процессор не инициализируется.
Вот тут в пункте 6 это описано: https://www.ivtechno.ru/articles-one?id=19
2) Не складывайте пакеты в очередь для передачи. Очередной запрос должен отправляться только после получения ответа или после достаточно большого таймаута. По моему опыту 500 мс обычно достаточно. Если меньше 100 мс - почти гарантированные проблемы. В официальной спецификации (https://modbus.org/docs/Modbus_over_ser ... _V1_02.pdf) все подробно описано.
Вот тут еще много полезного из первых рук: https://modbus.org/tech.php

[Kaskad11]

Мастер там вот такой.

Отправлено спустя 3 минуты 3 секунды:
Так он выглядит внутри.

Отправлено спустя 13 минут 33 секунды:
По поводу остальных рекомендаций - мастер к нам приходит в составе аппарата охлаждения уже запрограммированным. Что либо менять и настраивать в нём нет возможности. Разве что проверить и подпаять резистор на вход разрешения приемника.

[Sergey_P]

Мастер там вот такой.

Что либо менять и настраивать в нём нет возможности.

Получается, что производитель жестко запрограммировал свое устройство (МКУ) на работу с конкретными Modbus-устройствами (преобразователями ПИУ), но по факту МКУ работает некорректно? Ведь он явно шлет не те запросы. Это однозначно проблемы в программе мастера и повод обратиться к производителю. Кроме него Вам никто не поможет.
Все-таки тут что-то не так. Ведь они должны были проверить работоспособность перед отправкой заказчику?

Разве что проверить и подпаять резистор на вход разрешения приемника.

Резистор может и избавит от мусора при старте, но он не исправит некорректную программу.

[Kaskad11]

Да...
Какие строгости. Вроде и по правилам всё делал, а всё равно хоть кому то а не угодил. Неприятно.
Как будь-то в чашку кофе нассали. И не смертельно, а пить не хочется.

[Jackson]

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

С чего Вы взяли? :)
Если бы так всегда делалось - многочисленные службы техподдержки сидели бы без работы.