Непонятное поведение Mgate MB3480

[Guest Yan Zommer]

Добрый день.

Есть четерехпортовый преобразователь протоколов Mgate MB3480 и четыре 485 линии разной длинны и качества. На линиях приборы Satec, работающие по протоколу modbus rtu.

Перед установкой Mgate линии тестировались при помощи адаптера uport 1150, всё работало.

Подключили Mgate. Две самых коротких линии исправно работают, на двух других Mgate manager не находит устройств, и опрос через него тоже не идет. Подключаемся в ту же линию с помощью Uport - всё видим.

Может такое быть, что Uport "пробивает" длинную плохую линию, а Mgate - нет, и если может, то как с этим бороться?

[Komantsev]

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

Попробуйте переключить нагрузочные резисторы 485 в положение 1 КОм (переключатели 1 и 2 в положение ON).

Если это не поможет, попробуйте подключить терминальный резистор 120 Ом (переключатель 3 в положение ON).

Если и это не поможет, то дайте знать. Будем дальше решать проблему.

 

Во вложении - краткая документация, там описано как работать с упомянутыми переключателями.

MGate_MB3480_QIG_v4.pdf

[YanZommer]

Попробовали, никакое сочетание терминатора и pull-down не помогло. Снижение скорости с проектных 19200 до 4800 тоже не помогло.

Между делом обнаружилась совсем уже удивительная деталь - при подключении через uport мы до сих пор пробовали связь OPC сервером Kepware, и видели ответы приборов. Однако, когда мы попытались присоединиться к приборам их родной программой, это не удалось, пока не понизили скорость до 9600.

[Komantsev]

А по сколько устройств Satec "висят" на одной линии 485 (я имею ввиду некорректно работающие линии)? Есть ли какое-то "критическое" число устройств, начиная с которого связь перестает работать?

Также уточните по общей длине линии связи и по топологии (подключены ли все Satec цепочкой или применена какая-то более сложная топология)?

[YanZommer]

А по сколько устройств Satec "висят" на одной линии 485 (я имею ввиду некорректно работающие линии)? Есть ли какое-то "критическое" число устройств, начиная с которого связь перестает работать?

Также уточните по общей длине линии связи и по топологии (подключены ли все Satec цепочкой или применена какая-то более сложная топология)?

Обе линии - "чужая" медная пара. То есть, не мы их прокладывали, а дали нам что есть и сказали: пользуйтесь, другого не будет. Как проложено, сколько муфт по дороге - никто не знает. Мы бы может и задумались о какой-нибудь альтернативе, но перед началом работ на самую длинную линию поставили один прибор, и с другого конца его благополучно опросили uport'ом, и сочли линии рабочими.

 

Первая линия - четыре устройства, цепочкой в конце линии. длинна - предположительно метров 400-600

Вторая - метров 800, далее установлен повторитель TCC-120, за его выходом разветвляется на короткий 10-15 метровый хвост с двумя приборами и 300-400 метровую длинную линию с шестью приборами.

[Komantsev]

Добрый день!

Ну длина, конечно, не маленькая. Тут многое будет зависеть от качества кабеля.

Попробуйте на первой линии (которая без повторителя) на дальнем конце установить терминатор 120 Ом (если он не установлен)и поставить терминатор на соответствующем порту MGate.

На второй линии - за повторителем TCC-120 оставьте только один самый ближний прибор (остальные отключите) и посмотрите, будет ли он работать (это чтобы понять, теряется ли связь ДО повторителя TCC-120 или ПОСЛЕ).

 

Вообще UPort и MGate имеют немного разные выходные каскады интерфейса 485. На длинных линиях связи разница может чувствоваться.

Это не значит, что MGate сделан хуже, чем UPort. Многое зависит от характеристик подключенного к линии 485 оборудования, его нагрузочных характеристик и проч. В Вашем случае лучше с сигналом справляется, похоже, именно UPort.

[YanZommer]

Спасибо, будем пробовать в следующий выезд.

[Guest Менеджер проекта]

Спасибо, будем пробовать в следующий выезд.

В добавление к посту Яна: на этом проекте срочно нужен опытный пусконаладчик, способный решить

на объекте (район Лужников в Москве) в ближайшие дни (начало следующей недели)озвученные Яном

проблемы настройки моховских адаптеров.

+ есть аналогичная проблема с моховским медиаконвертором на том же объекте для преобразователя

RS485 в оптику (мультимод)

 

Жду предложений от специалистов. Достойная оплата гарантируется.

Писать можно мне в личку по адресу: spektor@hited.ru Борису.

[ыеыфь]

Такая же проблемма с MB3480 ( uport 1150 все читает), доходит до смешного, если начинаем опрашивать ветку которая не отвечает, то виснут все 3 рабочих ветки, терминирование и прочее не помогло. Кабель-витая пара 2х2 двойной экран, новый, даже бросили другой кабель, не помогло. Растояние до приборов порядка 100 метров м-ду приборами метра 2, приборов 8 штук. я так понял, если помехи прут по линии, то эта мокса не может прочитать устройства. Нужно подгонять терминатор на последнем приборе, или ставить 1-портовую моксу, или MB3480 переносить ближе к устройствам-это попробовали, MB3480 стала читать

[PKB]

Такая же проблемма с MB3480 ( uport 1150 все читает), доходит до смешного, если начинаем опрашивать ветку которая не отвечает, то виснут все 3 рабочих ветки, терминирование и прочее не помогло. Кабель-витая пара 2х2 двойной экран, новый, даже бросили другой кабель, не помогло. Растояние до приборов порядка 100 метров м-ду приборами метра 2, приборов 8 штук. я так понял, если помехи прут по линии, то эта мокса не может прочитать устройства. Нужно подгонять терминатор на последнем приборе, или ставить 1-портовую моксу, или MB3480 переносить ближе к устройствам-это попробовали, MB3480 стала читать

Аналогичная проблема: при обрыве связи с одним устройством (на одном порту), пропадает связь и с другим устройством (на другом порту).

Прошивка последняя v2.3. Есть какое-нибудь решение?

[PKB]

Разобрались, при пропадании связи с одним из устройств Moxa не формирует TCP Response по остальным устройствам.

 

Для эксперимента доступна только 1-портовая Moxa, к которой подключены слэйвы с адресами 2 и 3. Имитируем обрыв связи с 3-м слэйвом, видим, что со 2-м слэйвом по com-у исправно идет обмен: TCP Req, RTU Req, RTU Resp, а TCP Resp отсутствует (скриншот 1).

 

Если опрашивать слэйвы 2 и 3 разными программами, то TCP Resp для 2-го слэйва формируется правильно, в мониторе видно, что используются разные исходящие tcp-порты (скриншот 2).

 

Еще одно возможное решение: в конфигурации Moxa на вкладке Modbus поставить галочку Modbus TCP Exception, теперь для 2-го слэйва формируется правильный TCP Resp, а для 3-го вместо молчания отправляется exception response (скриншот 03).

 

Но эти решения, к сожалению, применимы не для всех TCP-клиентов.. в итоге операторская панель не может корректно отобразить, с каким именно слэйвом нет связи, какие данные недостоверны..

Можно считать этот пост официальным обращением в техподдержку Moxa?

[Незнайка]

Здравствуйте!

 

Я 3 раза прочитал. Пока непонятно. Давайте по пунктам:

Для эксперимента доступна только 1-портовая Moxa, к которой подключены слэйвы с адресами 2 и 3. Имитируем обрыв связи с 3-м слэйвом, видим, что со 2-м слэйвом по com-у исправно идет обмен: TCP Req, RTU Req, RTU Resp, а TCP Resp отсутствует (скриншот 1).

Скриншот 1 - это что? первая слева картинка или Безымянный01.png? В любом случае, TCP Response для slave 2 есть и там и там. Ещё уточню - он есть на всех 3х картинках.

 

Если опрашивать слэйвы 2 и 3 разными программами, то TCP Resp для 2-го слэйва формируется правильно, в мониторе видно, что используются разные исходящие tcp-порты (скриншот 2).

Ну как бы для slave 2 он и не пропадал.. Логично, что он остался.

 

Еще одно возможное решение: в конфигурации Moxa на вкладке Modbus поставить галочку Modbus TCP Exception, теперь для 2-го слэйва формируется правильный TCP Resp, а для 3-го вместо молчания отправляется exception response (скриншот 03).

Согласен - абсолютно нормальное поведение.

 

Но эти решения, к сожалению, применимы не для всех TCP-клиентов.. в итоге операторская панель не может корректно отобразить, с каким именно слэйвом нет связи, какие данные недостоверны..

Можно считать этот пост официальным обращением в техподдержку Moxa?

Я пока не не увидел, что же тут не работает. Попробуйте прочитать запрос сами, а потом переформулируйте его, пожалуйста, таким образом, что бы описанная проблема была видна.

[PKB]

Приветствую!

Скриншот 1 - это Безымянный01 (как я ни пытался, не получилось разместить их в правильном порядке - форум переворачивает порядок вложенных файлов).

На этом скриншоте 1 (Безымянный01) строка 288 - последний TCP Resp. После этого произошел обрыв связи с slave 3. Больше TCP Resp вообще нет, хотя RTU Resp от slave 2 есть (строки 292,299,304).

Так понятнее?

[Незнайка]

Добрый день!

Да, так понятнее. То есть, пока всё было нормально - были TCP Resp от slave 2 и slave 3, как только slave 3 оторвался - пропали все TCP Resp?Тогда можно попросить сделать 2 снимка, 1 - режим нормальной работы (slave 2,3 подключены, есть TCP Resp от slave 2 и slave 3), и второй снимок (slave 3 отключен, TCP Resp нет вообще)?

 

Немного дополню:

Еще одно возможное решение: в конфигурации Moxa на вкладке Modbus поставить галочку Modbus TCP Exception, теперь для 2-го слэйва формируется правильный TCP Resp, а для 3-го вместо молчания отправляется exception response (скриншот 03).

То есть в оконцовке удалось получить TCP Resp для подключенного и не получить его для отключенного, я правильно понял?

Это и было целью? Тогда, получается, что она - достигнута?