Незнайка

Интересный вопрос. Наверное может повесить. Всё в этой жизни может произойти -) Но скорее проблема в неправильной конфигурации или в изначально некорректном построении сети.

Можно, например, в руководстве по отказоустойчивости - http://www.moxa.com/doc/man/Communication_Redundancy_Users_Manual_v4.pdf

Это не совсем так. Действительно, up-status портов резервного линка проверяется. Однако пакеты Turbo Ring 2 (так называемые BPDU), передаваемые по резервному линку в случае его исправного состояния служат не для проверки его работоспособности, а для распространения информации о конфигурации в целом. Если предположить, что резервный линк повреждён таким образом, что статус портов у коммутаторов, обслуживающих его - UP, а на самом деле передача трафика через этот линк невозможна (на самом деле относительно часто встречающаяся неисправность, возникает в случае замыкания проводников в медном кабеле, например) - то в случае отказа основного линка будет предпринята попытка перехода на неработоспособный резервный линк. И сигнализация в таком случае не исправит ситуацию, т.к. аналогично работает на основании статусов портов, а не состояния линка в целом.

Вам бы тот сервер, MXView на котором, подключить бы напрямую к коммутатору кольца, убрав переход moxa-cisco... Тогда в следующий раз можно получить более подробную картину -)

На самом деле смотрите что видно: Сначала упали 156 и 157 устройства. Через 8 секунд появились обратно. Ещё через 22 секунды упали 154, 155, 156,157. И через 8 секунд отвалился 164 (значит, дальше уже можно не смотреть). Такое ощущение, что где то произошёл обрыв (пропадание питания) и RSTP не очень корректно (и не очень быстро) стал перестраивать схему. Turbo Ring 2 - вполне себе надёжный, а главное - гораздо более быстрый и ориентированный именно на MOXA промышленный протокол.

Тогда всё, что я могу сказать по этим данным - так это то, что cisco "отцепилась" от 164 свича (event ID 533 и далее), и что происходило собственно в самом кольце - тайна, покрытая мраком. Почему бы не перейти от RSTP на Turbo Ring применительно к этому кольцу?

Здравствуйте! А добавьте, пожалуйста, на приведённую схему саму машину с MXView, ту, которая 192.168.151.22?

Нет, целостность резервной ветки не контролируется, насколько я понимаю. Ситуация с попыткой включения оборванной резервной линии, в случае использования Turbo Ring вполне возможна.

Здравствуйте! 1. Сам коммутатор; 2. Заглушки для неиспользуемых слотов; 3. Крепёж для 19" конструктива (2 шт) ; 4. CD-диск с документацией и ПО; 5. Руководство по монтажу; 6. Гарантийная памятка.

Здравствуйте, видимо Вы где-то ошиблись в настройках. Разница в адресных пространствах роли не играет. Тут 2 пути: 1. Найти ошибку и заставить кольцо работать; 2. Восстановить предыдущую (рабочую) конфигурацию чёрного кольца, и добавить к нему сегмент 5, n, 4 с использованием технологии Turbo Chain.

Добрый день! И в чём было дело?

Здравствуйте! Попробовал на своей EDS-316. При подключении обоих входов PWR1 и PWR2 FAULT переходит в замкнутое состояние и находится в нём до пропадания любого из питающих напряжений. При выборе порта DIP-переключателем (PWR1 и PWR2 подключены), FAULT переходит в замкнутое состояние и находится в нём до пропадания любого из питающих напряжений или до пропадания Link на выбранном порту. Во всех остальных случаях FAULT в замкнутое состояние не переходит.

Здравствуйте! Дал бы кто TPM попользоваться.. Мы бы попробовали решить тогда.

Чудеса, да и только...

Добрый день! Держите.

А утилита NPort Administrator при этом работает? Находит NPort, позволяет его конфигурировать?

vanos, да нет, вроде нормальная у Вас версия прошивки. Версия IPSerial.lib тоже нормальная. Ещё уточню. Вы пишете, что nsio_init проходит. А nsio_checkalive работает, или уже нет?

K42J, здравствуйте! Какая версия прошивки у E2242?

Здравствуйте! Слушайте, я конечно не особо специалист в микроконтроллерах, но что то я не нашёл у Atmega 2650 сразу прям 485 интерфейса. Каким образом подключаетесь?

Вообще, если предположить что за AWK1121 будет находится клиент, который будет запрашивать данные с Компьютера1, то всё будет работать. Т.е. поставьте за AWK1121 компьютер, который, например, будет постоянно пинговать Компьютер1? В этом случае таблицы bridge должны обновиться.

Доброе утро, Анатолий! Вообще, теоретически должно. По второму вопросу - похоже на то, что не успевают обновляться таблицы bridge. Причём если попробовать пигновать клиента с AP2 после перехода - то всё должно получиться. Так же, скорее всего, всё получится, если после перехода на AP2 перезагрузить DSL-модемы. Zyxel пишет, что таблица bridge обновляется раз в 2 дня. Почему не происходит динамическое обновление - непонятно.

Кабель, по идее, правильный.. Должно работать. А если на время отойти от TCP сервера/клиента, переключить NPort в RealCOM, создать на компьютере виртуальный COM порт и попробовать пообщаться так? Будет ли ответ от АТС?

Давайте будем последовательны: Как я все таки понимаю, MasterSCADA установлена на неком компьютере. Логично предположить, что данный компьютер оснащён беспроводным интерфейсом, я верно предполагаю? Если Вы хотите начать решать задачу стразу с беспроводной связки - то переведите беспроводной интерфейс компьютера и W2150 в режим работы Ad-Hoc, и собственно попробуйте установить взаимодействие.

Здравствуйте! У NPort какой режим работы установлен? TCP сервер? Или клиент? А если Вы пишете, что проверяли настройки COM порта на ПК - то тогда откуда он взялся? Может, NPort надо установить в RealCOM? ПК принимает данные или запрашивает их? ПО приёма (запроса) данных куда обращается? В COM порт, или к TCP серверу?

Доброе утро! А можно схемку, для наглядности?