НПО Тепловизор. Теплосчетчики и расходомеры К вершинам эволюции теплосчетчика
     
Расширенный
Регистрация | Пароль?  
О компании Продукция Форум Вакансии
Пользователь    Пароль  
Главное меню
НовостиПродукцияФайлы/ДокументыСтатьиФорумОпросыФотогалереяО компанииРекламодателям
Потребители о нас
"Открытые и стандартизованные внешние интерфейсы узлов учета ВИСТ.Т позволяют реализовывать на их основе автоматизированные системы коммерческого учета энергоресурсов, необходимые для сбора, обработки и передачи итоговых значений объемов и качества потребленных ресурсов в автоматизированные системы ЕИРЦ, АС «Учета энергобалансов» ДТЭХ и т.д."

Ю.И.Припачкин, Генеральный конструктор ГЦП «Электронная Москва»
Наши партнёры
Свернуть/Развернуть ТЕПЛОСЧЕТЧИКИ • ВОДОСЧЕТЧИКИ • РАСХОДОМЕРЫ • ВИС.Т Свернуть/Развернуть
/  Архив форума
   /  Программное обеспечение
/  встроенный модем

Форум : Программное обеспечение

Название : встроенный модем

© NegaSoft co., 2005
http://www.teplovizor.ru

URL этой темы
http://www.teplovizor.ru/forum/viewtopic.php?topic_id=327&forum=2


 mobilandr :

9.12.13 21:56
 8.12.2013 19:32:27: >>> Начало сеанса удалённого доступа
8.12.2013 19:32:27: 2я северная линия,19
8.12.2013 19:32:27: Создание канала связи с прибором
8.12.2013 19:32:27: Доступ к удалённому устройству через шлюз
8.12.2013 19:32:27: Канал связи успешно создан
8.12.2013 19:32:27: Запрос доступа к прибору (Modbus-ASCII)
8.12.2013 19:32:43: Запрос доступа к прибору (HydraLink)
8.12.2013 19:32:58: Запрос доступа к прибору (Modbus-RTU)
8.12.2013 19:33:01: Получен ответ прибора (ModBus-RTU)
8.12.2013 19:33:01: Запрос CRC спецификаций/настроек прибора
8.12.2013 19:33:03: Запрос обновлённых спецификаций прибора
8.12.2013 19:33:22: Ошибка получения cпецификаций прибора
8.12.2013 19:33:22: Закрытие канала связи с прибором
8.12.2013 19:33:22: <<< Сеанс связи завершён с ошибкой

8.12.2013 19:35:00: >>> Начало сеанса удалённого доступа
8.12.2013 19:35:00: 2я северная линия,19
8.12.2013 19:35:00: Создание канала связи с прибором
8.12.2013 19:35:00: Доступ к удалённому устройству через шлюз
8.12.2013 19:35:00: Канал связи успешно создан
8.12.2013 19:35:00: Запрос доступа к прибору (Modbus-RTU)
8.12.2013 19:35:10: Запрос доступа к прибору (Modbus-ASCII)
8.12.2013 19:35:10: Запрос доступа к прибору (HydraLink)
8.12.2013 19:35:25: Нет ответа прибора
8.12.2013 19:35:25: Закрытие канала связи с прибором
8.12.2013 19:35:26: <<< Сеанс связи завершён с ошибкой

8.12.2013 19:37:52: >>> Начало сеанса удалённого доступа
8.12.2013 19:37:52: 2я северная линия,19
8.12.2013 19:37:52: Создание канала связи с прибором
8.12.2013 19:37:52: Доступ к удалённому устройству через шлюз
8.12.2013 19:37:52: Канал связи успешно создан
8.12.2013 19:37:52: Запрос доступа к прибору (Modbus-ASCII)
8.12.2013 19:38:08: Запрос доступа к прибору (HydraLink)
8.12.2013 19:38:23: Запрос доступа к прибору (Modbus-RTU)
8.12.2013 19:38:26: Получен ответ прибора (ModBus-RTU)
8.12.2013 19:38:26: Запрос CRC спецификаций/настроек прибора
8.12.2013 19:38:28: Запрос обновлённых спецификаций прибора
8.12.2013 19:38:41: Получены обновлённые спецификации прибора
8.12.2013 19:38:41: Запрос текущего времени часов прибора
8.12.2013 19:38:42: Запрос маски измеряемых параметров
8.12.2013 19:38:43: Чтение значений текущих измеряемых параметров
8.12.2013 19:39:02: Чтение накопителей нарастающего итога
8.12.2013 19:39:15: Обнаружено обновление архивных данных, переключение в режим передачи архива
8.12.2013 19:39:15: Получение размера архивной записи
8.12.2013 19:39:16: Приём архива...
8.12.2013 19:39:53: Приём архива завершён
8.12.2013 19:39:53: Закрытие канала связи с прибором
8.12.2013 19:39:53: <<< Сеанс связи завершён без ошибок

9.12.2013 20:42:22: >>> Начало сеанса удалённого доступа
9.12.2013 20:42:22: 2я северная линия,19
9.12.2013 20:42:22: Создание канала связи с прибором
9.12.2013 20:42:22: Доступ к удалённому устройству через шлюз
9.12.2013 20:42:22: Канал связи успешно создан
9.12.2013 20:42:22: Запрос доступа к прибору (Modbus-RTU)
9.12.2013 20:42:37: Запрос доступа к прибору (Modbus-ASCII)
9.12.2013 20:42:53: Запрос доступа к прибору (HydraLink)
9.12.2013 20:43:08: Нет ответа прибора
9.12.2013 20:43:08: Закрытие канала связи с прибором
9.12.2013 20:43:08: <<< Сеанс связи завершён с ошибкой
mt9g. клиент.
И так постоянно. При этом модем в нужное время выходит на связь, но если не успеть его опросить в первые 5 минут, такая свистопляска. Ошибок связь рвется и через 10-15 мин восстанавливается и все повторяется.

 CH :

9.12.13 22:13
 Всё это сильно напоминает закрытие сетью неактивного TCP-соединения. Keep alive настроен, на сколько?
Дополнительно, можно облегчить ситуацию с восстановлением связи. Протокол прибора уже известен, Modbus RTU, поэтому можно указать его принудительно в битовых настройках драйвера для прибора (см. readme драйвера). А то вследствие того, что прибор не отвечает на первый запрос, драйвер снова и снова пробует перебирать протоклы - вдруг настройка прибора изменилась, причём делает это со сдвигом ряда.

 mobilandr :

10.12.13 01:02
 +TTCP: 120,0,480,36 как обычно :-)
да, и после времени отключения долго еще продолжаю видеть модем "зеленым" в MtRoute(сегодня вот спустя 1.5 часа после времени отключения)

[ Редактировано mobilandr в 9.12.13 23:39 ]

 CH :

10.12.13 12:18
 А если всё-таки задать таймаут данных поменьше? Напр. 300 секунд...
Если интервала не хватает, не сможет проинициализироваться автоматический обработчик keep_alive в MtRoute - он автоматически настраивается на интервал между двумя KA-символами.

А может лог MtRoute что-то интересное подскажет?

 mobilandr :

12.12.13 00:23
 Не подскажите? Столкнулся тут с адаптером USB-RS485 от Z-TEK. Позиционируют как USB2.0/422,485. Драйверы автоматом из сети загрузились и установились. Имеет 9pin разъем и ответную часть с клемником. По RS-485 обозначения D+;D-;GND;+5V. На старом с которым привык общаться были только A+ и B-.
При попытке подключиться D+ на Rx, а D- на Tx получаю нет ответа в Архивисте или ошибку в MtCfg. Это какой то неправильный 485? Или я что не так делаю? :-?

 CH :

13.12.13 15:02
 mobilandr
Цитата:

При попытке подключиться D+ на Rx, а D- на Tx получаю нет ответа в Архивисте или ошибку в MtCfg. Это какой то неправильный 485? Или я что не так делаю?

Испробован вариант с обратным подключением + и - ? Кроме этого, не зная аппарата, что-то предложить трудно.

 mobilandr :

19.12.13 23:28
 Спасибо с 485 разобрался - джамперы на плате на 232 стояли...
На 300 таймаут поменял. Вот такое частое явление:
19.12.2013 22:17:07: >>> Начало сеанса удалённого доступа
19.12.2013 22:17:07: 2я северная линия,19
19.12.2013 22:17:07: Создание канала связи с прибором
19.12.2013 22:17:07: Доступ к удалённому устройству через шлюз
19.12.2013 22:17:07: Канал связи успешно создан
19.12.2013 22:17:07: Запрос доступа к прибору (Modbus-RTU)
19.12.2013 22:17:22: Нет ответа прибора
19.12.2013 22:17:22: Закрытие канала связи с прибором
19.12.2013 22:17:22: <<< Сеанс связи завершён с ошибкой

19.12.2013 22:17:45: >>> Начало сеанса удалённого доступа
19.12.2013 22:17:45: 2я северная линия,19
19.12.2013 22:17:45: Создание канала связи с прибором
19.12.2013 22:17:45: Доступ к удалённому устройству через шлюз
19.12.2013 22:17:45: Канал связи успешно создан
19.12.2013 22:17:45: Запрос доступа к прибору (Modbus-RTU)
19.12.2013 22:17:55: Получен ответ прибора (ModBus-RTU)
19.12.2013 22:17:55: Запрос CRC спецификаций/настроек прибора
19.12.2013 22:17:58: Ошибка получения CRC
19.12.2013 22:17:58: Закрытие канала связи с прибором
19.12.2013 22:17:59: <<< Сеанс связи завершён с ошибкой

19.12.2013 22:18:13: >>> Начало сеанса удалённого доступа
19.12.2013 22:18:13: 2я северная линия,19
19.12.2013 22:18:13: Создание канала связи с прибором
19.12.2013 22:18:13: Доступ к удалённому устройству через шлюз
19.12.2013 22:18:13: Канал связи успешно создан
19.12.2013 22:18:13: Запрос доступа к прибору (Modbus-RTU)
19.12.2013 22:18:16: Получен ответ прибора (ModBus-RTU)
19.12.2013 22:18:16: Запрос CRC спецификаций/настроек прибора
19.12.2013 22:18:20: Запрос обновлённых спецификаций прибора
19.12.2013 22:18:37: Получены обновлённые спецификации прибора
19.12.2013 22:18:37: Запрос текущего времени часов прибора
19.12.2013 22:18:38: Запрос маски измеряемых параметров
19.12.2013 22:18:39: Чтение значений текущих измеряемых параметров
19.12.2013 22:18:55: Ошибка получения значений измеряемых параметров
19.12.2013 22:18:55: Закрытие канала связи с прибором
19.12.2013 22:18:55: <<< Сеанс связи завершён с ошибкой

19.12.2013 22:19:06: >>> Начало сеанса удалённого доступа
19.12.2013 22:19:06: 2я северная линия,19
19.12.2013 22:19:06: Создание канала связи с прибором
19.12.2013 22:19:06: Доступ к удалённому устройству через шлюз
19.12.2013 22:19:06: Канал связи успешно создан
19.12.2013 22:19:06: Запрос доступа к прибору (Modbus-RTU)
19.12.2013 22:19:08: Получен ответ прибора (ModBus-RTU)
19.12.2013 22:19:08: Запрос CRC спецификаций/настроек прибора
19.12.2013 22:19:09: Запрос обновлённых спецификаций прибора
19.12.2013 22:19:33: Ошибка получения cпецификаций прибора
19.12.2013 22:19:33: Закрытие канала связи с прибором
19.12.2013 22:19:33: <<< Сеанс связи завершён с ошибкой

При этом по CSD все читается б/м нормально. Прибора нет в положенное время в мт роуте, после опроса по CSD сразу появляется, но ведет себя как показано выше. Мт роут не корректно отслеживает "отваливание" прибора, я его вырубил совсем или перезагрузил, а мтроут показывает его активным...
51% сигнал - единственное что вызывает подозрение. Какой минимум для gprs?

 CH :

25.12.13 12:43
 Видно, что подключение постоянно рвётся. Возможно что и из за слабого сигнала. Насчёт того, какой уровень сигнала хорош - а чёрт его знает, скажем от 75 процентов. Сигнал может быть не только относительно слабым, но и нестабильным по уровню, да мало ли.
Корректно отследить наличие устройства не передавая информацию нельзя, TCP-протокол не позволяет. Вот удалённый модем "отвалился".. и что дальше, об этом не знает ни он сам, ни маршрутизатор. Модем узнает об обрыве после того, как отправит запрос keep_alive, не раньше.
Сервер узнает об обрыве, если keep-alive в положенное время не получит, причём он ещё должен предварительно настроиться на интервал ожидания по парочке таких посылок (как я упоминал, эта функция сделана автоматической, так показалось проще, чем пользователю самому следить за взаимным соответствием настроек keep_alive в маршрутизаторе и каждом модеме).
Дополнительная возможность для маршрутизатора обнаружить пропадание модема - при запросе статусной информации. Что-то посылается, соотв. факт отсутствия модема сразу становится явным. На самом деле и от этого толку не особо много, важнее, чтобы сам модем был в курсе обрыва и переподключился.