А Вы вопрос читали? Вы ушли от темы.Цитата:
Сообщение от Lexx225
Вид для печати
А Вы вопрос читали? Вы ушли от темы.Цитата:
Сообщение от Lexx225
Я читаю из ПЛК110 через библиотеку UNM и точно определяю не только какой модуль отвалился за МКОН-ом, но и получаю все Modbus-ошибки от модуля. МКОН тупо преобразует пакет ModbusTCP в ModbusRTU и обратно.Цитата:
Сообщение от rediskus
Понять логику работы LastAddress и LastError в ветке Modbus (Мастер) не удалось.
Добрый день!
А правильно ли я понимаю, что с помощью МКОН можно не только опрашивать устройства, подключенные к нему по ModBus RTU, но и записывать данные (например, команды) в такие устройства?
Спасибо!
Правильно. Задача МКОН транслировать ModbusTCP в ModbusRTU и обратно без изменения исходного пакета.
При условии, что Вы не используете ведомого устройства с адресом 1 (этот адрес МКОН резервирует для себя).
Alex54321 с точки зрения процесса протокола команда опроса чем-то отличается от команды записи ?
Нет, не отличается.Цитата:
Сообщение от melky
Но встречал устройства, которые почему-то работали не со всеми функциями 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.Цитата:
Сообщение от capzap
Контроллеры одинаковые, регистры зеркальные (отопление/вентиляция). Один (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
При опросе bool регистров контроллера с адресом 246 ответ полноценный, например:
Packet: MODBUS Request (packet size: 8, data size: 4), 2025‐05‐22 16:25:37.602401 +0.000000
Mode: RTU Mode
Address: 246 (Slave)
Function: 2 (Read Discrete Inputs)
Starting Address: 4724
Quantity: 2
CRC: 61097 (OK)
Packet: MODBUS Response (packet size: 6, data size: 2), 2025‐05‐22 16:25:37.714816 +0.000000
Mode: RTU Mode
Address: 246 (Slave)
Function: 2 (Read Discrete Inputs)
Starting Address: 4724
Quantity: 8
Values: Input0: 0 Input1: 0 Input2: 0 Input3: 0 Input4: 0 Input5: 0 Input6: 0 Input7: 0
CRC: 64659 (OK)
При опросе bool регистров (по контуру ГВС) контроллера с адресом 247 ответ полноценный, например:
Packet: MODBUS Request (packet size: 8, data size: 4), 2025‐05‐22 16:33:21.138886 +0.000000
Mode: RTU Mode
Address: 247 (Slave)
Function: 2 (Read Discrete Inputs)
Starting Address: 4325
Quantity: 2
CRC: 27384 (OK)
Packet: MODBUS Response (packet size: 6, data size: 2), 2025‐05‐22 16:33:21.342707 +0.000000
Mode: RTU Mode
Address: 247 (Slave)
Function: 2 (Read Discrete Inputs)
Starting Address: 4325
Quantity: 8
Values: Input0: 1 Input1: 0 Input2: 0 Input3: 0 Input4: 0 Input5: 0 Input6: 0 Input7: 0
CRC: 49235 (OK)
А вот при опросе bool регистров (по контуру вентиляции) того же контроллера с адресом 247 ответ меньше на 1 байт (байт с данными), например:
Packet: MODBUS Request (packet size: 8, data size: 4), 2025‐05‐22 16:39:39.603747 +0.000000
Mode: RTU Mode
Address: 247 (Slave)
Function: 2 (Read Discrete Inputs)
Starting Address: 4911
Quantity: 1
CRC: 4504 (OK)
Packet: MODBUS Response (packet size: 5, data size: 1), 2025‐05‐22 16:39:39.780263 +0.000000
Mode: RTU Mode
Address: 247 (Slave)
Function: 2 (Read Discrete Inputs)
CRC: 37376 (OK)
Просмотр 485 через терминал - убедиться в одинаковом количестве байт в ответеЦитата:
Сообщение от capzap
Так как на предыдущем дампе (который с описанием) видно, что на 247 на некоторых регистрах на 1 байт меньше ответ. Т.е. по предположению тех.поддержки ОРС - скрипт Python также как и МКОН исчисляет СRC не дождавшись всего пакета и игнорирует последний нулевой байт
На дампе Modbus TCP - ответ тоже короче на 1 байт
Есть. Если эта модель МКОН поддерживает прозрачный режим, то попробовать переключиться на него. И на стороне OPC-сервера переключиться на Modbus RTU over TCP вместо Modbus TCP. На худой конец виртуальный COM-порт создать, там уж чистый RTU.Цитата:
Сообщение от vorobev22rus
Если нет, то приобрести адекватный шлюз вместо этого. Адекватный - это не про МКОН.
Вчитываться в выкладки по байтам с подсчётом CRC мне просто лень, извините.
проблема не в МКОНе а в слейве, 37376 получается от контрольной суммы 9200, а ответный пакет должен быть таким F7 02 01 00 92 00, что означает что сумма в DEC должна считаться от 0092, поэтому и ошибка. И как я говорил проверить такую же ошибкы можно было бы и в первом слейве по адресу 246Цитата:
Сообщение от vorobev22rus
Мкон так не умеет насколько я понимаю, он как раз преобразует Modbus RTU/Modbus TCP. Адекватный это какой? На старом предприятии МОХА была в приоритете (не помню проблем), на этом - бюджеты скромнееЦитата:
Сообщение от imaex
Вы про это:Цитата:
Сообщение от capzap
Packet: MODBUS Request (packet size: 8, data size: 4), 2025‐05‐22
16:25:37.602401 +0.000000
Mode: RTU Mode
Address: 246 (Slave)
Function: 2 (Read Discrete Inputs)
Starting Address: 4724
Quantity: 2
CRC: 61097 (OK)
Packet: MODBUS Response (packet size: 6, data size: 2), 2025‐05‐22
16:25:37.714816 +0.000000
Mode: RTU Mode
Address: 246 (Slave)
Function: 2 (Read Discrete Inputs)
Starting Address: 4724
Quantity: 8
Values:Input0: 0 Input1: 0 Input2: 0 Input3: 0 Input4: 0 Input5: 0 Input6: 0 Input7: 0
CRC: 64659 (OK)
Так ошибок нет
здесь опрашивается адрес 4911 по одной катушке, ответ в отличии от остальных не печатает ни Starting Address ни Quantity ни Values, сразу переходит к контрольной сумме которая не вернаяЦитата:
Сообщение от vorobev22rus
ЗЫ поставте адреса 4 и 5 и проблема должна уйти
Возможно я перепутал чего, но, вроде бы тут кто-то утверждал, что в новых версиях есть. Не буду спорить.Цитата:
Сообщение от vorobev22rus
Работающий и (желательно) дешевле МКОН. Тот же usr-iot посмотрите, если совсем дешёво (но работает). Или icp-das, тут в ту же цену, что и у МКОН, уложитесь.Цитата:
Сообщение от vorobev22rus
Во: https://docs.owen.ru/product/mkon/579/73003#topic-73013
Раздел "Режим прозрачного шлюза".
Так собственно об этом я и создал пост. Предположение Тех.поддержки ОРС - мне кажется верным: и это ПО (с расшифровкой) и МКОН одинаково видят контрольную сумму и считают, что пакет закончился. Терминал же показывает что количество байт одинаковое и на 247 и на 246. Когда опрашиваю через СОМ порт напрямую - ошибок нет. Вопрос как сделать чтобы Шлюз дожидался весь пакет. Почему контрольная сумма неверная?Цитата:
Сообщение от capzap
Вот это уже какое то дельное предложение. Попробую...Цитата:
Сообщение от imaex
сперва определяется что пакет закончил пересылаться по паузе в 3,5 символа, потом считается КС и сравнивается что пришло в КС в пакете, сколько байт данных всего прописано в третьем байте посылки, если программисты ошиблись и ошибочно воспроизвели этот алгоритм в мконе, третий раз предлагаю адрес 247 поменять на 5Цитата:
Сообщение от vorobev22rus
Вы думаете адрес может повлиять на итоговый пакет? Хорошо, попробую. И попробую совет imaex (объект удаленный, завтра/послезавтра доеду), по результату отпишусь.Цитата:
Сообщение от capzap
да, потому что этот адрес(247) может вносить причудливые формы в генерацию CRC, как на скринах в этом посте https://owen.ru/forum/showthread.php...l=1#post463458, потому что в этой теме изображения не добавляютсяЦитата:
Сообщение от vorobev22rus
Товарищи, все получилось!!! Imaex, Capzap, благодарю вас за неравнодушие, профессионализм и дельные советы. Проверил оба варианта: оба рабочие. Перепрошил МКОН, появились настройки для работы в режиме Ethernet/485. Modbus RTU поверх ТСР работает без проблем (в том числе с адресом 247), но отказался от этого варианта из-за возможных пауз и неверной интерпретации пакетов Modbus RTU (так как структура компонентов связи для Modbus RTU поверх ТСР не самая удачная на мой взгляд: ПЛК-шлюз-маршрутизатор-провайдер-маршрутизатор-ОРС). Изменил адреса на 2 и 3 все работает (действительно, именно с адресом 247 происходит совпадение содержимого пакета и CRC). Век живи век учись...