А Вы вопрос читали? Вы ушли от темы.Сообщение от Lexx225
А Вы вопрос читали? Вы ушли от темы.
Я читаю из ПЛК110 через библиотеку UNM и точно определяю не только какой модуль отвалился за МКОН-ом, но и получаю все Modbus-ошибки от модуля. МКОН тупо преобразует пакет ModbusTCP в ModbusRTU и обратно.
Понять логику работы LastAddress и LastError в ветке Modbus (Мастер) не удалось.
Последний раз редактировалось EFrol; 15.12.2024 в 12:13.
Добрый день!
А правильно ли я понимаю, что с помощью МКОН можно не только опрашивать устройства, подключенные к нему по ModBus RTU, но и записывать данные (например, команды) в такие устройства?
Спасибо!
Правильно. Задача МКОН транслировать ModbusTCP в ModbusRTU и обратно без изменения исходного пакета.
При условии, что Вы не используете ведомого устройства с адресом 1 (этот адрес МКОН резервирует для себя).
Alex54321 с точки зрения процесса протокола команда опроса чем-то отличается от команды записи ?
Нет, не отличается.
Но встречал устройства, которые почему-то работали не со всеми функциями ModBus (вполне распространенными, что-то вроде 16-ой, уже не помню).
Лучше лишний раз уточнить.
Добрый день! Опрашиваю через МКОН два ПЛК "Ридан" один с адресом 246 - с него все считывается правильно, на втором с адресом 247 проблемы с единичными bool регистрами. Физические изменения все поперепробовал (пересаживал на другой порт ПЛК; менял шлюз; выставлял/убирал терминаторы; выставлял/убирал подтягивающие резисторы). Пробовал анализировать пакеты Modbus, но не силен в них. Видно только что на этих регистрах на один байт информации меньше (Modbus TCP) - соответственно качество тега становится в BAD. На пакетах Modbus RTU - вроде все нормально.
Данные по Modbus RTU терминалом (адрес 246)
11:23:55 RX : [HEX] 3f 2 12 74 0 2 3f 3f - запрос, а RX маркер т.к. порт был на прослушке
11:23:55 RX : [HEX] 3f 2 1 0 3f 3f - ответ
Пакет по Modbus TCP с ОРС сервера (адр 246)
27.05.2025 11:23:55.845;TC_Loco_MKON;10.4.15.26:502;SEND;12;8 E 00 00 00 00 06 F6 02 12 74 00 02
27.05.2025 11:23:55.876;TC_Loco_MKON;10.4.15.26:502;REC;10;8E 00 00 00 00 04 F6 02 01 00
Данные по Modbus RTU терминалом (адрес 247)
11:14:25 RX : [HEX] 3f 2 12 3f 0 1 3f c - запрос, а RX маркер т.к. порт был на прослушке
11:14:25 RX : [HEX] 3f 2 1 0 3f 0 - ответ
Пакет по Modbus TCP с ОРС сервера (адр 247)
27.05.2025 11:14:25.235;TC_Loco_MKON;10.4.15.26:502;SEND;12;7 7 00 00 00 00 06 F7 02 13 2F 00 01
27.05.2025 11:14:25.283;TC_Loco_MKON;10.4.15.26:502;REC;9;77 00 00 00 00 03 F7 02 01
и ошибка
27.05.2025 11:14:25.299;APPLICATION;Устройство "ITP_Loco_A2": Несовпадение количества бит в ответе..
Писал до этого в техподдержку ОРС сервера, ребята предположили, что весь подвох в контрольной сумме на этих регистрах(CRC). Цитирую:
""Судя по обмену, по 485 интерфейсу всё хорошо.
11:14:25 RX : [HEX] 3f 2 12 74 0 2 3f 3f - запрос от OPC сервера через шлюз
11:14:25 RX : [HEX] 3f 2 1 0 3f 0 - ответ от прибора
Видно, ответ полноценный, четыре байта пакета и два контрольная сумма.
По факту на линии вот такие данные:
F7 02 12 74 00 02 A8 3F - запрос от OPC сервера через шлюз
F7 02 01 00 92 00 - ответ от прибора
Хитрость здесь в контрольной сумме.
CRC для последовательности F7 02 01 00 = 92 00
CRC для последовательности F7 02 01 = 00 92
При получении ответа от прибора шлюз формирует следующий пакет:
00 00 00 00 00 03 F7 02 01
А должно быть
00 00 00 00 00 04 F7 02 01 00 Т.е. он отбрасывает крайний байт.
Причина здесь в том, что CRC пакета шлюз высчитывает по мере поступления байт с 485 линии, на лету, до тех пор пока не совпадет контрольная сумма, как только она совпала, он формирует Modbus TCP
пакет и, с чистой совестью, отправляет его OPC серверу. Но, по факту, произошло ложное совпадение контрольной суммы, на не принятом до конца пакете.
Таким же образом работает и та тестовая программа, которой вы проверяли в первый раз.""
На причину почему на одном контроллере все хорошо, а на втором качество тегов плохое сообщили следующее. Цитирую
""Дело в контрольной сумме.Если брать пакет с 246
Полный пакет будет F6 02 01 00 93 FC, где 93 FC это CRC
Если рассчитать для неполного F6 02 01, то CRC = 51 52
Последовательности цифр 51 52 в исходном пакете нет, поэтому он рассчитывает до конца, а там CRC совпадает.""
Если брать пакет с 247 Полный пакет будет F7 02 01 00 92 00, где 92 00 это CRC
Если рассчитать для неполного F7 02 01, то CRC = 00 92
Последовательность цифр 00 92 в исходном пакете идет сразу после 01, шлюз принимает это за совпадение CRC и останавливается, игнорируя крайний байт.""
Есть какие нибудь мысли?
первая мысль, а зачем этот выпендреж с неиспользованием с 1-245 адресов?
Второе где настройки ОРС который инициирует запросы, по пакетам видно что ОРС запрашивает с разных устройств разную информацию, возможно если с первого запросить тоже самое что не получается со второго, там такие же проблемы будут
Во первых 1 - за самим МКОН зарезервирована. Во вторых это не выпендреж, а лень: на обоих контроллерах по умолчанию адрес 247. Поэтому на втором просто снизил адрес на 1.
Контроллеры одинаковые, регистры зеркальные (отопление/вентиляция). Один (246): отопление, второй(247): на систему вентиляции +подпитка и ГВС
На 246 регистры только для чтения 4724 4725 4737 читаются верно, на 247 переменные в регистрах 4724 4725 4737 + 4911 4741 (подпитка) - нет.
Настройки канала связи ОРС (arOPC):
Таймаут 1000 мс;
Межбайтовый интервал 10 мс;
Задержка 0мс
значит стоит найти нормальный просмотрщик RS485, потому что
11:23:55 RX : [HEX] 3f 2 12 74 0 2 3f 3f
и
11:14:25 RX : [HEX] 3f 2 12 3f 0 1 3f c
как бы Вы не писали что обращение к разным адресам, в лог пишется как будто идет обращение на один и тот же адрес 3f что не верно как по сути обмена двух слейвов, так и по контрольным суммам
PS и не поленится, сменить адреса слейвов на первый десяток
Последний раз редактировалось capzap; 27.05.2025 в 12:26.
Ваши права
Ответить с цитированием