Незнайка

Марат, давайте поподробнее. Какая цепочка, где не работает? Каковы настройки NPort'ов?

Здравствуйте! Попробовал "поймать" проблему долговременным тестированием - используя модуль ввода-вывода разрывал Ethernet - соединение каждые 30 секунд и через 5 секунд восстанавливал обратно (размыкая-замыкая проводники). Данные передаю по RS-232 (генератором случайного набора символов, в одну сторону, от модема к компьютеру), режим работы - Reverse RealCOM. Результат пока никакой - с понедельника всё работает корректно. К сожалению, дальше продолжить наблюдение нет возможности. Про стек TCP- Вы были правы - дело не в нём. Обдумывал поведенческую модель, и вот что придумал: 1. Сменить TCP порт. Нет ли вероятности того, что какое либо иное приложение не пытается использовать (периодически) его в своих целях? 2. Очевидно, что Вы используете программу опроса. На постоянной ли основе она открывает виртуальный COM-порт? Или открыли-опросили-закрыли? Не исключаю вариант, что в случае, если программа занимает порт на постоянной основе, она не позволяет драйверу произвести некую "реконфигурацию" внутри себя. 3. В конце концов, на этом драйвере свет клином не сошёлся. Если именно он вдруг перестаёт работать на Вашей конкретной конфигурации - почему бы не поискать альтернативный? Например, схожим функционалом (если я не ошибаюсь) обладает программа VSPE, например.

Если под конвертором мы понимаем TFC-142, то работать, разумеется, ничего не будет. Видимо, специалисты проектной организации перепутали указанный конвертор с устройствами серии NPort (терминальные серверы).

Добрый день! На CP-114 установлен разъём DB37. Его распиновку (в том числе и для RS-422) можно посмотреть например здесь http://moxa.ru/files/manuals_boards/cp-114_qig_v3.pdf стр.5

Что то я пропустил Ваше сообщение - извините за задержку. Очевидно, что где то что то не так с маршрутизацией. И тот факт, что Вы можете опрашивать 10.13.10.101, при отключенном шлюзе 10.13.10.1, т.е фактически проходя сквозь сеть 10.13.11.0/х говорит сам за себя. К сожалению, по такой схеме я ничего сказать не могу. На ней много устройств, которые вообще не имеют адреса, с непонятными таблицами маршрутов в каждом из них. Так же, как я вижу - у NPort получается 2 шлюза - то есть и модем, и роутер - я же правильно понял? Или нет? Я запутался -) Подпишите, пожалуйста, на схеме IP адреса каждого из интерфейсов устройств, приведённых на ней, таблицы маршрутов для каждого из них, и их метрики. При чём даже желательно приводить не только IP адреса, а и маски сетей, дабы точно понимать, как перемещается трафик внутри сети.

Здравствуйте! К сожалению, не знаю, что тут ещё посоветовать. Дело в том, что у нас это проблема не воспроизводится (пробовали различными способами). Вероятно, это какая то особенность, связанная с передачей данных конкретно у оператора. Тут даже нельзя однозначно утверждать, что проблема кроется именно в драйвере MOXA. Ибо точно так-же, можно предположить, что это "подвисает" стек протокола TCP в ОС. Ещё, я бы добавил, что в данном случае, мы пытаемся решить не проблему, а следствие. То есть проблема в нестабильной работе канала связи, а следствием из неё (предположительно) является многократное переобращение к TCP порту. И говоря другими словами - если многократно что-то "дёргать" - то есть шанс это "задёргать". Может быть, есть какой то не столь затратный способ улучшить качество связи (например, установив антенны с большим коэффициентом усиления), или произвести смену оператора (хотя-бы в целях диагностики)?

Добрый вечер! Что то я не понял - или настроить не получается (а что не получается то собственно?), или есть задача (а сколько, собственно, платят?) - как это понимать? -)

Здравствуйте! Как я понимаю, подойдёт обычный нуль-модемный кабель. Далее цитата с hp.com: HP ProCurve Switches -- Serial Console Cable Pinout for Part Number 5184-1894 Available Part Numbers: J4812A,J4813A,J4848B,J4849B,J4868A,J4899B,J4900B,J4903A,J4904A,J4905A,J4906A,J8692A,J8693A,J8697A,J8698A,J8699A,J8700A,J8762A,J8770A,J8772A,J8773A,J9019B,J9020A,J9021A,J9022A,J9049A,J9050A,J9064A,J9085A,J9085AZ,J9086A,J9087A,J9088A,J9088AZ,J9089A,J9137A,J9138A,J9145A,J9146A,J9147A,J9148A,J9447A,J9448A,J9470A,J9471A,J9472A,J9473A,J9562A,J9565A Issue Description: What is the pinout for the black DB9 to DB9 serial console cable with part number 5184-1894? Solution: NOTE: The following does not apply to the HP ProCurve Routing Switches 9300M. These products used a standard straight-through RS232 cable. The connectors are DB9 female, to DB9 female. DCD 1 -- 1 DCD RX 2 -- 3 TX TX 3 -- 2 RX DTR 4 -- 6 DSR GD 5 -- 5 GD DSR 6 -- 4 DTR RTS 7 -- 8 CTS CTS 8 -- 7 RTS RI 9 -- 9 RI

Добрый вечер! Знаете, такие возможности (я про JTAG, к примеру) есть наверняка. Однако все они "методом тыка" и "на свой страх и риск". Мне кажется, что лучшим вариантом (если устройство гарантийное) была-бы отправка в ремонт. А если гарантии нет, и очень хочется - тогда можно попробовать -)

Всем добрый вечер! Мы провели ряд тестов, и в принципе согласны с тем, что такая проблема существует. Хочу заметить, что на устройствах серии NPort такая проблема не проявляется. Отправили запрос разработчику.

Скорее всего в документации это вопрос не раскрывается, т.к. производитель гарантирует только совместимость "вверх" (т.е. на коммутатор версии 2.х можно поставить прошивку 3.х), а в обратную сторону совместимость не предусматривается. То есть на любой старый/новый коммутатор можно поставить новую прошивку - нет смысла документировать это отдельно.

Я к тому, что скорее всего новый коммутатор имеет исполнение 3 (Rev. 3.0), и вполне вероятно, что он не совместим с прошивками серии 2.х.

Здравствуйте! Вообще возможность понижения версии прошивки никак не заблокирована - т.е. прошивку старой версии можно залить на устройство штатными средствами, в том числе и через web интерфейс. Другое дело, что производитель крайне не рекомендует это делать, и публично не распространяет старые версии. Получить их можно только по запросу с конкретным обоснованием необходимости. Ваша же ошибка скорее говорит о том, что Вы пытаетесь залить версию от другого устройства (при чём это может быть просто другая аппаратная версия, т.е. прошивка 2.3.14 может быть несовместима с новыми аппаратными версиями EDS-518A).

ммм... Добрый день! Если VPN тут не причем - то зачем было о нём писать? -) Приведите пожалуйста: 1. Схему взаимодействия с указанием адресации сетей, IP адресов устройств (NPort, "сосед, которого ищем", маршрутизаторов) с указанием масок; 2. Снимок экрана сетевых настроек NPort 5230; 3. Лог программы мониторинга трафика с указанными событиями.

Здравствуйте! Если ping не проходит - значит что то пошло не так -) Я бы обратил внимание на настройку беспроводной части NPort (если другие устройства с роутером нормально соединяются), благо что она полностью описана на русском языке тут: http://moxa.ru/files/manuals_nport/nport_w2250_2150_rus.pdf начиная со стр. 5-7 и далее.

Здравствуйте! В одноранговой сети ARP используется для определения адреса получателя. В многоранговой - соответственно для определения адреса шлюза. При использовании VPN применение ARP-Proxy представляется абсолютно логичным выходом, т.к. NPort 5230 не имеет VPN-клиента. Честно говоря, я не очень понял, что же в конечном итоге не работает?

Знаете, так очень сложно ответить. Указанная модель (MACH1030) имеет ещё кучу букв и цифр в наименовании, обозначающих в том числе и типы используемых интерфейсов. Вообще, при одинаковой пропускной способности, длине волны, типу волокна и облучающих элементах всё должно взаимодействовать. Однако нужно учитывать, что современные производители редко открыто публикуют данные об информационной совместимости устройств. Режимы резервирования - только с использованием RSTP или STP и соответствующим временем восстановления.

Здравствуйте! Посмотрите на модель EDS-510E (скорее всего она Вам подойдёт).

Здравствуйте! А что значит "при активном соединении"? Можно получить какой то лог обращений к tcp-порту?

Тогда других вариантов нет. Надо либо точно знать параметры соединения Urometr, либо методом "тыка" дальше -)

Здравствуйте! А внутри ppp туннеля у Вас TCP поднялся? Можете ли Вы, например, выполнить с сервера(10.13.11.201) команду telnet 10.13.11.202 80 (проверить доступность 80 порта)? Я так же не очень понимаю, как к этой схеме применён Siemens TC 35, и что за шлюз 10.13.10.1? Можно попросить схематично нарисовать полную схему соединений?

Вообще, всё должно заработать. Но с провайдером лучше конечно тоже проконсультироваться. Если предполагается динамическое получение адреса от провайдера - тогда следует выбрать режим DHCP.

Я про скорость передачи и имел в виду, ибо ранее Вы говорили о том, что выставляли скорость как 9600.

Да, руководство конечно пустовато, но смотрите что я там нашёл (стр. 13, 14) : По умолчанию, скорость обмена между Urometr 120 и ПК - 115200. Я бы попробовал выставить 115200,8,N,1 как наиболее распространённые параметры. Если не поможет - то в п. 5.1 и 5.5 руководства приводятся манипуляции с кнопками, как заставить Urometr 120 распечатать свою конфигурацию, в которой, в том числе, указывается и текущая скорость, установленная на порту.

Великая вещь наука о контактах!