Страница 1 из 1
Добавлено: 25 окт 2007, 01:26
Faster
И так есть объект , на деконте 182, связь с деспетчерской по GPRS модем -моем ...
найден великий глюк, в 3-4 из 10 случаях , если на диспетчерской машине во время передачи данных (в активном состоянии тоесть данные снимаются раз в секунду и их много) просто выгрузить виндеконт, но не отрубать интерент соединение , то удалённый деконт через энное время всётаки показывает в дескрете связи что её нет , но переподключения не следуеет ....
переподключается отлично если перезагрузить деконт по питанию или ручками , причём без перезапуска модема...
воппрос это что совсем реальный ГЛЮК ?
конфиги есть могу слить ...
далее неужели нет не каких способов перегрузить деконт программно, ведь мне пришлось удорожить каждый деконт на 7 тр, чтобы поставть внешную схему которая бы определяла , завис он или нет, и есть связь или нет ....
Добавлено: 25 окт 2007, 11:12
Юрий Сметанин
далее неужели нет не каких способов перегрузить деконт программно,
Кстати, меня то же весьма интересует этот вопрос!
Добавлено: 25 окт 2007, 11:32
Faster
Дело в том что количество вопросов уже привысело количество ответов на .....
Я всего тримесяца занимаюсь деконтом и уже пришол к выводу что не серьёзные люди деповцы

Добавлено: 25 окт 2007, 11:33
Faster
Кстати способ естьт , есть компонент в разработчике который позволяет с ошибкой устроить перезакгрузку деконта , но чтото смутно представляю ... устойчивость этого дела ...
Добавлено: 25 окт 2007, 15:25
Юрий Сметанин
Я уже шесть лет работаю с ДЕПом

И надо заметить, что раньше было еще хуже...

Добавлено: 28 окт 2007, 15:35
Faster
СЭр я всего несколько месяцев, не вас жаль
Добавлено: 31 окт 2007, 14:57
Aлексaндр
Хз у меня с 40 деконтов инфа собирается раз в минуту, подобного замечено небыло. Виндеконт перезагружал но все выходили на связь.
Добавлено: 01 ноя 2007, 02:53
Faster
Не знаю ... данный глюк довольно таки устойчев,
Насчёт 40 деконтов это что за объект такой ???
в нашем случае итдёт речь об устойчивой работе более 700 объектов , с стложной логикой в нутри объекта и сложным групповым поведением , причём любая ошибка или задержка может привести к выходу из строя оборудованию на цать лимонов ...
при этом удаление оборудования друк от друга по всему городу ...
Глюк был замечен и жостко описан , еслиб это было только в конфигурации описанной мной, то это одно но когда это сработало в конфиге второго програмера и в конфиге что деп прислал , я стал говорить об устойчивом шлюке ...
поза вчера разговагивал с деповцем ответственным за канальтный уровень , описал глюк будут думать ...
в принцепе как не странно но при смене варианта выхода в нет на E-ZTH платку и провайдера беспроводного интернета с шлюзом , проблема не как не появлялась ...
Добавлено: 01 ноя 2007, 02:54
Faster
Не знаю ... данный глюк довольно таки устойчев,
Насчёт 40 деконтов это что за объект такой ???
в нашем случае итдёт речь об устойчивой работе более 700 объектов , с стложной логикой в нутри объекта и сложным групповым поведением , причём любая ошибка или задержка может привести к выходу из строя оборудованию на цать лимонов ...
при этом удаление оборудования друк от друга по всему городу ...
Глюк был замечен и жостко описан , еслиб это было только в конфигурации описанной мной, то это одно но когда это сработало в конфиге второго програмера и в конфиге что деп прислал , я стал говорить об устойчивом шлюке ...
поза вчера разговагивал с деповцем ответственным за канальтный уровень , описал глюк будут думать ...
в принцепе как не странно но при смене варианта выхода в нет на E-ZTH платку и провайдера беспроводного интернета с шлюзом , проблема не как не появлялась ...
Добавлено: 01 ноя 2007, 03:18
Faster
Не знаю ... данный глюк довольно таки устойчев,
Насчёт 40 деконтов это что за объект такой ???
в нашем случае итдёт речь об устойчивой работе более 700 объектов , с стложной логикой в нутри объекта и сложным групповым поведением , причём любая ошибка или задержка может привести к выходу из строя оборудованию на цать лимонов ...
при этом удаление оборудования друк от друга по всему городу ...
Глюк был замечен и жостко описан , еслиб это было только в конфигурации описанной мной, то это одно но когда это сработало в конфиге второго програмера и в конфиге что деп прислал , я стал говорить об устойчивом шлюке ...
поза вчера разговагивал с деповцем ответственным за канальтный уровень , описал глюк будут думать ...
в принцепе как не странно но при смене варианта выхода в нет на E-ZTH платку и провайдера беспроводного интернета с шлюзом , проблема не как не появлялась ...