Диагностика ошибки связи Modbus TCP

[Lexx225]

Доброе время суток!

Никаких неисправностей разумеется нет, может кто-то подскажет решение задачи. Есть панель СП307. К ней подключено 6 датчиков ПВТ110. Но - через шлюз. Если отрубить любой из датчиков, появляется ошибка в контрольном бите PSB54. Что в общем-то логично, патамушта МКОН - это Modbus TCP Slave 1. Он там первый и единственный. А вот как-то распознать, отказ какого из 6 модулей привел к этой ошибке? Ну кроме очевидного - организовать макросом опрос всех шести по очереди? Или все-таки только так?

[kondor3000]

Доброе время суток!

Никаких неисправностей разумеется нет, может кто-то подскажет решение задачи. Есть панель СП307. К ней подключено 6 датчиков ПВТ110. Но - через шлюз. Если отрубить любой из датчиков, появляется ошибка в контрольном бите PSB54. Что в общем-то логично, патамушта МКОН - это Modbus TCP Slave 1. Он там первый и единственный. А вот как-то распознать, отказ какого из 6 модулей привел к этой ошибке? Ну кроме очевидного - организовать макросом опрос всех шести по очереди? Или все-таки только так?

Выкинуть МКОН и сделать опрос 6 датчиков отдельно, но макросы всё равно писать надо будет.

[Lexx225]

Это великолепный совет, спасибо)))) Я ждал чего-то именно такого)))))) Вот только выкинуть МКОН не получится скорее всего. Не буду же я тянуть из-за этого RS485 между зданиями.

[kondor3000]

Это великолепный совет, спасибо)))) Я ждал чего-то именно такого)))))) Вот только выкинуть МКОН не получится скорее всего. Не буду же я тянуть из-за этого RS485 между зданиями.

Какой вопрос, такой и ответ)))

[In_Da_Cher_A]

А вот как-то распознать, отказ какого из 6 модулей привел к этой ошибке? во-первых - какая в дупу разница, на каком датчике трабл, если всё равно надо идти туда и разбираться с датчиком?
во-вторых - а что у вас с показаниями будет, если датчик отвалился? наверное они как-то либо уйдут в зашкал, либо во фриз, в зависимости от вида проблем на датчике
наверное проблема с показаниями сразу скажет вам какой датчик неисправен?
не знаю чего там ещё вы ждёте, мой совет просто подумать немного

[Lexx225]

Хм, а как эта штука вообще работает-то? Если убрать патч-корд от МКОН до коммутатора или от коммутатора до панели - никакой ошибки не вылезает, просто останавливается опрос. А если вернуть патч-корды и от МКОНа отсоединить гирлянду ПВТ-шек, то в 54 бите вылезает ошибка. И если снять питание с ЛЮБОГО из шести устройств - опять вылезает ошибка в 54 бите. Получается, что панель как-то анализирует именно физическое состояние слэйвов, а не связь с МКОН. И если она через шлюз любой из шести как-то видит как одно и то же, то не может ли она видеть их как-нибудь нормально? По отдельности? Посылает какой-то широковещательный запрос? Почему тогда не появляется ошибка если разомкнуть Ethernet-соединение? Есть может где почитать про это, никто не в курсе?

[Lexx225]

Я подумал немного и даже макрос написал уже. Просто сама ситуация в голове не складывается пока в логичную картину.

[kondor3000]

Хм, а как эта штука вообще работает-то? Если убрать патч-корд от МКОН до коммутатора или от коммутатора до панели - никакой ошибки не вылезает, просто останавливается опрос. А если вернуть патч-корды и от МКОНа отсоединить гирлянду ПВТ-шек, то в 54 бите вылезает ошибка. И если снять питание с ЛЮБОГО из шести устройств - опять вылезает ошибка в 54 бите. Получается, что панель как-то анализирует именно физическое состояние слэйвов, а не связь с МКОН. И если она через шлюз любой из шести как-то видит как одно и то же, то не может ли она видеть их как-нибудь нормально? По отдельности? Посылает какой-то широковещательный запрос? Почему тогда не появляется ошибка если разомкнуть Ethernet-соединение? Есть может где почитать про это, никто не в курсе?
Очевидно МКОН передаёт ошибку, что отвалился один или все датчики. Если разрываете Ethernet-соединение, ошибку передавать некому.
МКОН мастер же?
И даже если панель мастер, она будет долбится постоянно, будет тормозить, а ошибку может не показать.

[Lexx225]

Ну как мастер... Панель мастер, ПВТ-слейвы. Шлюз настроен мастер в сети Ethernet, слэйвы - в сети Modbus. Хм. А поскольку шлюз НЕ ЗНАЕТ, сколько у него ПВТ, то как он определяет, один отвалился, два или все?

[imaex]

Если отрубить любой из датчиков, появляется ошибка в контрольном бите PSB54. Что в общем-то логично, патамушта МКОН - это Modbus TCP Slave 1. Он там первый и единственный.

Если честно, то я пока не вижу в этом ничего логичного. Я так понимаю, что это бит в СПК, так? Если так, то это СПК определяет, что кто-то отвалился за шлюзом. Сильно сомневаюсь, что МКОН что-то там сообщает - его номер в этой схеме 16-ый.
Во всяком случае в его служебных регистрах ничего не увидел связанного со статусом связи с ведомыми устройствами - да было бы и удивительно, ведь он ведомые по своей инициативе не опрашивает. Сам МКОН ведь не отвалился, "первый и единственный", как Вы выразились. А СПК сам МКОН и не опрашивает, он опрашивает устр-ва за ним, с отличными от 1-цы ID. Во всяком случае я так думаю.

Т.ч. скорее всего какая-то внутренняя логика СПК выставляет этот бит по таймауту с одним из опрашиваемых устройств.


А поскольку шлюз НЕ ЗНАЕТ, сколько у него ПВТ, то как он определяет, один отвалился, два или все?

Да никак он этого не определяет - не его дело.

[In_Da_Cher_A]

Панель мастер, ПВТ-слейвы. Шлюз настроен мастер в сети Ethernet, слэйвы - в сети Modbus. эээээээ не многовато-ли мастеров в в сети Ethernet?

[EFrol]

В макросах СП3хх есть функции чтения регистров ведомых устройств, которые возвращают true, если чтение произведено удачно.
Соответственно, нет связи с МКОН или нет с ведомым уже за МКОН-ом - результат чтения false. Это единственный способ диагностировать, какой SlaveID не доступен.
При этом связь с самим МКОН-ом можно проверить путем чтения регистра устройства с SlaveID = 1, который МКОН резервирует под хранение Modbus-таблицы c параметрами подключений (см. РЭ).

Необходимо понимать, что false будет возвращен также и при наличии связи с устройством, но при запросе не существующего регистра!!!

[Lexx225]

В макросах СП3хх есть функции чтения регистров ведомых устройств, которые возвращают true, если чтение произведено удачно.
Соответственно, нет связи с МКОН или нет с ведомым уже за МКОН-ом - результат чтения false. Это единственный способ диагностировать, какой SlaveID не доступен.
При этом связь с самим МКОН-ом можно проверить путем чтения регистра устройства с SlaveID = 1, который МКОН резервирует под хранение Modbus-таблицы c параметрами подключений (см. РЭ).

Необходимо понимать, что false будет возвращен также и при наличии связи с устройством, но при запросе не существующего регистра!!!


Спасибо!!!