Тема: прерывается связь с контролерами SCM-NET2
Добрый день!
После года использования контроллеров SCM-NET2 начала проявятся проблема связи контроллеров с сервером. На данный момент контроллеры теряют и восстанавливают связь по нескольку раз за минуту, это видно из службы связи с контролерами - зеленый кружок меняется на красный, через некоторое время обратно на зеленый, рядом с ним постоянно горит восклицательный знак. Патчкорд идущий к контролерам проверялся на наличие стабильного соединения, также несколько раз сбрасывали IP адрес контролера на стандартный и задавали нужный снова. Версия ПО Коменданта обновлена до последней версии.
Пожалуйста подскажите, в какую сторону копать в данной проблеме?
P.S: контролеров три, проблема для всех одинакова, ставились они в разное время
1) Проверить наличие диода FR207 в цепи питания замка.
2) Контроллер отображается серым либо зелёным кружком с красным восклицательным знаком
это значит <Cбой базы событий контроллера>.
Нужно сделать сброс событий.
Конфигуратор
На точке доступа правой кнопкой мыши -> сервисные функции -> сброс событий.
Подобное происходит при монтаже с включённым питанием или плохих контактах.
1) Проверить наличие диода FR207 в цепи питания замка.
2) Контроллер отображается серым либо зелёным кружком с красным восклицательным знаком
это значит <Cбой базы событий контроллера>.Нужно сделать сброс событий.
Конфигуратор
На точке доступа правой кнопкой мыши -> сервисные функции -> сброс событий.
Подобное происходит при монтаже с включённым питанием или плохих контактах.
У нас стоят турникеты, схема замка немного другая, но в ней не нашел наличия данного диода, сброс событий из-за потери связи с контролерами пока не получается сделать, пишет аналогичную ошибку.
Турникет питается от собственного блока питания?
Устройство турникетов разное, поэтому универсальную схему нарисовать нельзя.
Диод FR207 в цепи нужен для гашения обратной эдс, если в турникете имеются индуктивность типа реле или другая, то параллельно ей должен стоять диод. Это актуально при общем питании турникета и контроллера, питание должно быть раздельным.
Также для внесения ясности будет полезным попробовать посмотреть, что пишет <Монитор событий>.
Турникет питается от собственного блока питания?
Устройство турникетов разное, поэтому универсальную схему нарисовать нельзя.Диод FR207 в цепи нужен для гашения обратной эдс, если в турникете имеются индуктивность типа реле или другая, то параллельно ей должен стоять диод. Это актуально при общем питание турникета и контроллера, питание должно быть раздельным.
Также для внесения ясности будет полезным попробовать посмотреть, что пишет <Монитор событий>.
Да, у турникета собственный блок питания, события пишутся, правда большие задержки при передачи события от контроллера на сервер, события характера - человек вошел, вышел, ошибок не наблюдается
Вполне может быть, что задержки связаны с перегруженностью базы из за сбоя.
Необходимо в диспетчере задач в процессах посмотреть загруженность.
Чтобы исключить базу как возможный источник проблем.
Рекомендую создать временную новую тестовую базу на другом компьютере и понаблюдать на наличие или отсутствие старых проблем.
На компьютере с рабочей базой нужно отключить <Служба связи с контроллерами> остальное можно не трогать.
На компьютере с тестовой базой также необходимо сконфигурировать службу связи, и конфигуратор.
Контроллеры к тестовой базе надо подключать по одному.
Вполне может быть, что задержки связаны с перегруженностью базы из за сбоя.
Необходимо в диспетчере задач в процессах посмотреть загруженность.
Чтобы исключить базу как возможный источник проблем.
Рекомендую создать временную новую тестовую базу на другом компьютере и понаблюдать на наличие или отсутствие старых проблем.
На компьютере с рабочей базой нужно отключить <Служба связи с контроллерами> остальное можно не трогать.
На компьютере с тестовой базой также необходимо сконфигурировать службу связи, и конфигуратор.Контроллеры к тестовой базе надо подключать по одному.
Попробовал сделать тестовую базу, но остановился на добавлении контроллеров в нее. Сейчас обнаружилась другая проблема, не идут пинги к контролеру даже напрямую. Пробовал сделать сброс через кнопку на плате, но пинги всеравно не появились. Вчера еще получалось к ним подключиться после сброса кнопкой, но последний месяц наблюдался произвольный сбой связи, когда связь пропадала полностью. Таких случаев было порядка двух, решалось нажатием на кнопку ресет на плате и восстановлением необходимых IP адресов.
Могли слететь MAC адреса из-за постоянных сбоев. Это только к нам на перепрошивку.
Хотя бы один контроллер, с которым есть связь имеется?
Могли слететь MAC адреса из-за постоянных сбоев. Это только к нам на перепрошивку.
Хотя бы один контроллер, с которым есть связь имеется?
Да, тот, который собственно не трогали, у него изначальная проблема как я описывал вначале. Есть возможность вызвать мастера?
MAC записывается только у нас.
Тот контроллер, с которым есть связь нужно подключить к тестовой базе, сделать сброс событий и программирование, дальше сделать несколько проходов т посмотреть не появиться ли восклицательный знак.
Если появится, проверить: минус и плюс питания турникета и контроллера должны быть связаны только на клеммах к которым подключен блок питания, параллельно всем обмоткам задействованных электромагнитов и реле должны стоять диоды. Провода не должны вываливаться из контактов.
Если все работает нормально, проверить 50 - 100 раз для уверенности.Все повторить по каждому контроллеру, те из них, с которыми связь не появится, к нам на перепрошивку (бесплатно) или менять (платно).
Когда все заработает стабильно, подключиться к своей базе, в конфигураторе выбрать пункт система контроля доступа -> оптимизация базы событий. Запустить оптимизацию за тот период времени, с которого начались проблемы, лучше за все время.
MAC записывается только у нас.
Тот контроллер, с которым есть связь нужно подключить к тестовой базе, сделать сброс событий и программирование, дальше сделать несколько проходов т посмотреть не появиться ли восклицательный знак.
Если появится, проверить: минус и плюс питания турникета и контроллера должны быть связаны только на клеммах к которым подключен блок питания, параллельно всем обмоткам задействованных электромагнитов и реле должны стоять диоды. Провода не должны вываливаться из контактов.
Если все работает нормально, проверить 50 - 100 раз для уверенности.Все повторить по каждому контроллеру, те из них, с которыми связь не появится, к нам на перепрошивку (бесплатно) или менять (платно).
Когда все заработает стабильно, подключиться к своей базе, в конфигураторе выбрать пункт система контроля доступа -> оптимизация базы событий. Запустить оптимизацию за тот период времени, с которого начались проблемы, лучше за все время.
Один контроллер удалось ввести в систему и установить с ним связь. Второй во время задания персонального IP адреса переклинило, на плате появились в местах контактов обугливания. Цепь прозванивается, но при подключении питания теперь возникает КЗ. Возможен ли ремонт или потребуется полная замена?
Обугливание контактов - это следствие неправильного подключения питания.
Ремонт скорее всего возможен. нужно смотреть контроллер.
Привозите в офис.
Еще такой вопрос есть, при сравнении работы контролера с тестовой базой и базой “нашей” при подключении к контролеру напрямую обнаружилось, что в работе с “нашей” базой пинги идут ощутимо хуже. В “нашей” забито около 200 карточек, события пишутся с мая прошлого года, может ли быть объем данных причиной “тугой” связи с контроллером?
Работающий контроллер может не отвечать на пинги потому, что служба связи опрашивает контроллер довольно часто.
Работающий контроллер может не отвечать на пинги потому, что служба связи опрашивает контроллер довольно часто.
Да, если отключить службу связи пинг идет стабильно, но при программировании контролера необходима эта служба. Во время программирования, например на установке даты и времени возникает ошибка “модуль связи не отвечает”, при нескольких повторах он все-таки продвигается дальше. Дальше идет около 200 карточек и на них почти на каждом такая же ошибка.
В таком случае необходимо сделать тестовую базу из рабочей сделав резервное копирование.
Что-бы после всех операций можно было из неё восстановиться.
Потом в модуле отчетов очистить архив событий. И провести действия которые ранее не получались или вызывали ошибки. Если данные действия помогут, то значит дело в объеме архива событий, который необходимо уменьшить и также проверить на сбойные события.
Также напишите каков объём и количество у вас занимает Архив событий (СКУД). Посмотреть это можно в
конфигураторе > Система > кнопка «Получить статистику по системе» > Архивные таблицы > Архив событий (СКУД).
