Компания ДЭП - Форумы

Здравствуйте!!!
У нас часть сети построена таким образом.
1. На объектах стоят контроллеры Д-182 с платами Z-Eth
2. Платы Z-Eth к подключены к точка Wi-Fi провайдера
3. На точке входа данных с этих объектов стоит точка Wi-Fi провайдера, затем наш маршрутизатор, затем наш комп. с виндеконтом(опрос по UDP).
Проблема в том, что иногда пропадает передача данных именно с со всех этих объектов сразу и самостоятельно не восстанавливается(у нас есть объекты в нашей локальной сети, где те же настройки у плат и контроллеров – там нет этих проблем). Приходится «оживлять» внешними способами. Представляете, каково это, если произошло в вечером или в выходные. Причиной такой ситуации может служить отсутствие некоторое время питание маршрутизатора и т.п. Наш сисадмин поизучал эту ситуацию и выдал следующее(некоторые слова мне незнакомы, поэтому дословно).
Вот его слова - «пусть ДЭП расскажет, как работает контроллер езернета, зачем он шлет эхи, проблема именно в том, что точки перестают слать данные, если некоторое время маршрутизатор не был доступен».
Что за посылки делает плата Z-Eth через порт 07(это та самая «эха») – кроме своего 2586?
Дело в том что, после зависания, оборудование нормально пингуется(и Wi-Fi, и и плата Z-Eth в контроллере), а данные не отдаются.
Было бы неплохо, если бы Вы разъяснили, как работает сама плата Z-Eth, с точки зрения запросов-ответов(контрольных пакетов, пакетов с данными и т.п.), так и вместе с контроллером.
Только давайте пожалуйста без «детского сада», ваш маршрутизатор(провайдер) виноват, у вас неправильная конфигурация и т.п. – ответить, но ничего не сказать. Не тратьте свое и мое время.
Думаю, Можарский Максим что-то сможет подсказать, он вроде знаком с платой и ее работой. Но буду рад и другим советам. Хотелось бы также услышать про «крыжик» Direct IP Search. В каких случаях он нужен? Может вот в таких, коротких сетях?
С Уважением, Александр !!!

Проблема в том, что иногда пропадает передача данных именно с со всех этих объектов сразу и самостоятельно не восстанавливается(у нас есть объекты в нашей локальной сети, где те же настройки у плат и контроллеров – там нет этих проблем). Приходится «оживлять» внешними способами.

Что вы рестартуете, чтобы система стала работать?
Как вы рестартуете?
Вы читали журнал ошибок в WD и удаленных контроллерах.

Причиной такой ситуации может служить отсутствие некоторое время питание маршрутизатора

Питание пропадает на маршрутизаторе, который стоит рядом с WD?
Если да, то связь пропадает со всеми удаленными контроллерами или есть с которыми связь не пропала?

Вышлите мне вашу конфигурацию на micromax@dep.ru.

Максим писал(а):

Проблема в том, что иногда пропадает передача данных именно с со всех этих объектов сразу и самостоятельно не восстанавливается(у нас есть объекты в нашей локальной сети, где те же настройки у плат и контроллеров – там нет этих проблем). Приходится «оживлять» внешними способами.

Что вы рестартуете, чтобы система стала работать?
Как вы рестартуете?
Вы читали журнал ошибок в WD и удаленных контроллерах.

Причиной такой ситуации может служить отсутствие некоторое время питание маршрутизатора

Питание пропадает на маршрутизаторе, который стоит рядом с WD?
Если да, то связь пропадает со всеми удаленными контроллерами или есть с которыми связь не пропала?

Вышлите мне вашу конфигурацию на micromax@dep.ru.

У нас подобьная ситуация, только нет местных соединений (все через n-маршрутизаторов).
Помогает только рестарт контроллера на объекте.

У нас подобьная ситуация, только нет местных соединений (все через n-маршрутизаторов).
Помогает только рестарт контроллера на объекте.

Рестарт вы делаете по кнопке RESET или снимаете питание с контроллера?

И так апресъеденяюсь и я таже трабла на A9-GSM

Если например удалённый WD ночь не отвечал, комп погасили то нефига не переподключается контроллер !


уже три объекта весят из 20 , просто й резет по контроллеру помагает !


ребята это плохо

Здравствуйте!!! Оказывается проблема с Z-Eth не только у нас! Почему-то тема раньше не засветилась? Немного еще добавлю, для полной ясности картины.
Я уже говорил, у нас есть и другие объекты, точь в точь с такими же настройками. Отличие лишь в том, что там платы Z-Eth не подключены к сети провайдера Wi-Fi напрямую в ихнюю сеть(см.выше), а отсечены от провайдера маршрутизаторами(в данном случае, это провайдер Интернета, а не Wi-Fi) . Вот в этом случае, проблем нет. Работает без подвисаний. Прошивки маршрутизаторов(ASUS WL500gP) абсолютно везде одинаковые(сисадмин сам на Linux написал), и для Wi-Fi - на входе в нашу сеть и для сети через провайдера Интернет), разница, естественно, только в IP для разных сетей, подсетей, шлюзов.
Пропадание питания маршрутизатора для Wi-Fi – это частный случай. На самом деле архитектура передачи-приема наших данных гораздо сложнее. Вся информация(и наша и бухгалтерская и т.д.) отовсюду и разными видами связи поступает(передается) сначала в серверы треста. Оттуда, именно наши данные, по локальной сети треста, поступают(передаются) на наш комп. с виндеконтом . Так что перерыв в передаче данных и последующим зависанием объектов может быть спровоцирован и перезагрузкой серверов, и пропаданием питания на них(хоть сервера и входные Wi-Fi и Интернет(Ethernet) и т.п., с маршрутизаторами запитаны от мощных UPS-ов, но бывают и перерывы питания).
Уточню для Максима, после подвисания - пинги до всех плат на объектах нормально проходят, а пропадает передача именно данных, сразу со всех объектов, объединенных в такую сеть. Проблему подвисания передачи данных мы сейчас ликвидируем рестартом маршрутизатора на входе, после Wi-Fi. Эта процедура – фактически «холодный старт»(хотя и пропадание питания – тоже холодный старт - непонятно), грузится по новой прошивка, стартует, все это занимает время до 1 мин. И похоже, именно такой «холодный старт» и(или) долговременная недоступность в сети помогает, «эхи» платы не доходят до маршрутизатора(может ответа не получают на эти «эхи»?) и это заставляет платы снова установить связь и начать «пулять UDP»(как говорит наш сисадмин). Но это, только мое предположение, т.к. «эхи» доходят только до маршрутизатора, а не дальше. Есть желание проверить ликвидацию подвисания одного из объектов рестартом(или снятием питания) контроллера, для получения более полноценной информации, остальные ведь должны продолжать висеть. Но объекты далеко, на чужих территориях и малодоступны, для вандалоустойчивости. Пока я туда доберусь рестартануть, шума из-за отсутствия данных с этих объектов будет!!!!!!!!!!! Поэтому делаем как быстрее. И проблема высветилась не сразу, сначала даже не понимали, что происходило. Возникает нечасто, нестабильно и сымитировать тяжело. Что за ошибки покажет контроллер на объекте(надо ж с ноутом ехать), пока не можем. В виндеконте наверное быстрее сможем посмотреть. Сейчас количество объектов пока 5, а будет еще больше, т.к. стали развиваться в этом направлении, у нас уже почти весь город Wi-Fi сотами опутан. Поэтому проблему надо срочно решать. Максим, конфигурацию вышлю позже. А хотелось бы ответ по работе платы Z-Eth.
Прошу прощения за многословность! С Уважением, Александр!!!

Александр III писал(а):...
Сейчас количество объектов пока 5, а будет еще больше, т.к. стали развиваться в этом направлении, у нас уже почти весь город Wi-Fi сотами опутан.
...

Александр, не надо развивать эту систему на D182 и Z_Eth. Сняли их с производства, возьмите А9. Уверена, Максим сможет понять, что именно не так делает Z_Eth, но если проблема будет в софте чип-а ("чужая" корейская математика и исходных нет), то потом, можно год переписываться с ними с просьбой исправить и не факт, что они возьмутся исправлять. И эти 5-ть штук лучше заменить на A9, если Вам негде их использовать, то заменим за свой счет.

Faster писал(а):И так апресъеденяюсь и я таже трабла на A9-GSM

Если например удалённый WD ночь не отвечал, комп погасили то нефига не переподключается контроллер !


уже три объекта весят из 20 , просто й резет по контроллеру помагает !


ребята это плохо

Faster, "таже трабла на A9-GSM" не имеет отношение к проблемам Z-Eth, сообщите, пожалуйста, версию библиотеки driver.so в "подвисших" контроллерах. Версию можно посмотреть в Конфигуратор>Менеджер файлов вкладка "Загруженные в контроллер".

Связь пропадает со всеми удаленными контроллерами или есть с которыми связь не пропала?

UDP Порт 7, это ECHO - контроль удаленного обьекта, что он живой.
Этот пакет посылается платой примерно раз в две минуты и маршрутизатор должен на него отвечать.

Возникает вопрос: Какой ответ высылает маршрутизатор на пакет ECHO? Если ваш админ сможет, то пусть вышлет полный обмен пакетами между маршрутизатором и удаленным объектом во время этого зависания. В этом обмене обязательно должны быть присутствовать запросы WD, которые маршрутизатор отправляет на удаленный обьект.

Здравствуйте!!!
Пока поймаем отказ, чтобы снять показания для Максима, вот такое отступление.
К сожалению мы 1,5 года у Вас ничего не покупали, а тут еще кризис на нашу голову. У нас нет опыта работы с А9. И по форуму видно – проблем с А9 хватает. А мне 182-й нравится, 80-90% наших задач решает. Не всегда нужен такой мощный универсальный контроллер, как А9. Зачем нужен экскаватор, если нужно выкопать ямку 10Х10 см. Может лучше иметь 2-3 вида контроллера, для разных задач. Скажу начальству про замену или покупку А9. Пусть почешут «репку».
Меня насторожило про «сняли ИХ с производства». Это относится и к интерфейсным платам Д-182 – го? Чаще выходят из строя именно интерфейсный платы, чем контроллер. В результате гроз, статики, даже грозозащиты не спасают. Закрывают, так сказать, собой амбразуру, спасая контроллер. Вот у нас выходили из строя Z-RS485(при работе с Неводами), Z-Eth. На 485-х переписывали на 2-й сегмент и вводили в работу, Z-Eth – в мусор. Проясните ситуацию с производством интерфейсных плат для 182-го. А то накладно заменять 182-й контроллер на А9, если только надо плату сменить.
С Уважением!!!

Насчёт корейских исходников, Cвтлана я уверяю вас что тот чип что вы юзали в Z-ETH настолько надёжен , что к ниму не разу на проф форумах не видел нарикания? и сам его юзал в своих разработках.


насчёт мсложных контроллеров, в общем то да если честно a9 нафиг не нужен в половине задач, а то для чего он задумался на нём не реализовать , потому что :
1.софт коряво ставится
2.зависимость от конфигурации
3.удалённо WD не шьётся полноценно


ну и так далее я уже писал тока всем пофиг

Faster писал(а):Насчёт корейских исходников, Cвтлана я уверяю вас что тот чип что вы юзали в Z-ETH настолько надёжен , что к ниму не разу на проф форумах не видел нарикания? и сам его юзал в своих разработках.

Faster, Вы можете уверять меня в чем угодно, но мы имели проблемы с их софтом и общались с ними по этому поводу. Вы на ранних прошивках с этим чипом работали?

Александр, сняли с производства и D-182 и интерфейсные платы к ним. Но это не значит, что их нельзя покупать сейчас. Предыдущую серию контроллер PL мы производили около восьми лет, после того как их сняли с производства. Просто не серийно и если нет остатков на складе, то срок поставки увеличивался. С этой серией, наверное, будет так же. Если нужны гарантии, пишите официальное письмо руководству.

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

Светлана, да работал давно ... но недавно заказал 10 штук себе нановый проект , пока всё работает.