Добрый день, уважаемые коллеги. Давненько я не посещал никакие форумы, но кривая судьбы и увлечения всё тааки снова привели меня сюда, так как официальная тех поддержка не помогла.
Лет эдак 5 назад я разобрался с преобразователями интерфейса usr TCP 232-302, 410, успешно установил десяток штук на узлы учета людям, они успешно работают по сей день. Но вот, потребовалось снова этим заняться и столкнулся с неожиданной проблемой.
Тезисно:
1) TCP 232 всегда подключаются успешно к удаленному серверу, к виртуальному com порту, как в локальной сети, так и общей в режимах клиента и сервера.
2) Опрос прибора учета происходит, но в какой то момент перестает работать, в этом и проблема.

Чаще всего это происходит при включении в сеть нового прибора, он работает, а старый который только что работал перестает работать. Он подключается к серверу, принимает информацию, но не передает ее. Причем если замкнуть rx и tx на rs233, то какая то коммуникация всё-таки происходит.

Есть случай, когда у 2х людей все работало и перестало работать через 3дня
Есть случай, когда я оставлял не рабочим и начинало работать через несколько часов

Реанимировать прибор после такой отключки TCP 232 тоже почти не возможно, ни в com, ни в клиенте, ни в сервере, в локальных нелокальных сетях, на разных виндовсах и компах. Проходит тест при замыкании rx tx, а прибор не опрашивает, переустановка прошивок, сброс настроек к заводским не помогают. Приборы учета тоже разные брад.

Вот три дня полежат, достанешь их, вроде работают, и всё по новой. Три недели... С ума сойду скоро.
SOS

https://img.radiokot.ru/files/161908/3vyqkx1304.jpg

Вопрос то в чём?

Вопрос в том, почему может быть такое поведение изначально работающих устройств. цель получить от прибора учёта определенный ответ, но его не удаётся получить. Точнее далеко не всегда.

Проверьте МАСи в сети.

У вас такое бестолковое описание, что даже не понять - что и как подключено.
Подключитесь сниффером к каналу и помониторьте обмен. В моменты возникновения проблем.

Спасибо за наводку, хорошо, что есть довольно подробная инструкция, что нужно посылать на прибор учета (далее ПУТЭ), и что он должен отвечать.


В целом анализ в сниффере (пришлось еще поразбираться в этом) показал, что либо преобразователь интерфейса (который словил баг) где-то теряет информацию, либо ПУТЭ не отвечает на запрос.

Если замнкнуть RX и TX преобразователь интерфейса начинает посылать запрос обратно.
Не добавляет ответов, что вся эта схема работает до тех пор, пока не начинаешь перезагружать, менять настройки преобразователя интерфейса.

А почему?

Добавлено after 9 minutes 24 seconds:



Вроде всё в порядке. В разных локальных сетях тоже не работает

А айпи адреса правильно настроены? Дхсп отключен?

Берите осциллограф и смотрите уровни Tx и Rx когда обмен есть и ждите, когда он пропадет. Обращать внимание не только на уровни, но и длительность импульса и примерную длину посылки.
Если используется больше соединения Tx/Rx, то и другие управляющие сигналы.

Для контроля, хорошо бы поставить комп. в постоянный мониторинг обмена, для чего взять другой 232->usb конквертор и подключить его на Tx subj (параллельно имеющемуся соединению с прибором учета тепла). Соответственно, открыть терминалку и пусти пишет всё подряд.

Подключитесь к линиям TX/RX прибора учёта (бросьте их на RX-ы двух дополнительных RS-232) и мониторьте данные любой терминалкой, умеющей показывать двоичные данные. Так увидите что реально приходит и уходит с прибора учёта.

Также можно поставить на ПК какую-нить из программ "COM to TCP", подключить счётчик к этому ПК и проверить работу в такой конфигурации.

PS: Протокол этих ваших тепловычислителей конечно ужасен - никакой кодонезависимости похоже там нет и в помине. "Разработчики" сих поделий разложили грабли на ровном месте. Видимо какой-то наколенный самопал. Без кодонезависимости одна помеха может сломать обмен навсегда (до перезагрузки т.е.). Так что надо убедиться, что данные к счётчику и от счётчика приходят всегда корректные (посредством наблюдений через отдельные COM-порты как описал выше).

Одна из вероятных причин проблем: По какой-то причине происходит разрыв TCP-соединения внутри кадра. Преобразователь RS-232<->Ethernet сразу автоматически производит реконнект. Но часть кадра уже потеряна. Программа опроса не получив ответа на запрос, посылает новый запрос, но (так как отсутствует кодонезависимость протокола обмена на канальном уровне) прибор учёта воспринимает этот новый запрос как часть предыдущего кадра. И он не проходит по CRC, отбраковывается. И так до бесконечности со всеми новыми запросами.
Здесь надо:
1) или вправлять мозги разработчикам всего этого хозяйства (приборов учёта) и реализовывать кодонезависимый протокол обмена;
2) или обеспечивать идеальное TCP-соединение вообще без разрывов.
Правильнее конечно 1-е.
Этот как версия. Так как из предоставленной информации не видно кодонезависимости протокола. А такие решения - однозначно в утиль.
Если версия верна, и устойчивость соединения не представляется возможным обеспечить в принципе (например - провайдер рвёт долгие TCP-коннекты автоматом), можно попробовать добавить костыли в программу опроса. Скажем - чтобы она автоматически закрывала/открывала TCP-соединение после каждого опроса.

Добавлено after 29 minutes 8 seconds:
Мониторить нужно и TX и RX прибора учёта. Чтобы отловить самое важное - момент прекращения ответов. И проанализировать - что именно происходило в этот момент.
Если проблем с корректностью данных на RS-232 нет, то скорее всего - проблема с разрывами TCP-коннектов. Описанная выше.

Также ещё одна вероятная причина проблем: Использованные преобразователи "RS-232<->Ethernet" - кривые. Например - не корректно склеивают данные их двух последовательно идущих TCP-пакетов в единый поток. Или добавляют какие-то левые символы при склеивании. Или добавляют паузу (которая приводит к отбраковке кадров в приборе учёта). Либо некорректно отрабатывают повторы данных (либо дубликаты) внутри TCP-соединения (которые являются нормой, но не все изделия их корректно отрабатывают).
Поэтому я и советовал попробовать работу при помощи другой программы COM<->TCP.
Сталкивался на практике со многими из таких проблем. Корректность Firmware в разных поделиях бывает тоже совсем не на высоте.

Добавлено after 10 minutes 48 seconds:
Re: USR TCP 232 "забывает", как опрашивать прибор учета тепла
PPS: Да, ещё вопрос к ТС: А программа учёта как видит каналы связи с приборами учёта? Они для неё - отдельные TCP-соединения? Или как-то по иному? Т.е. - может она видеть случаи разрывов/восстановлений TCP-соединений?
Эта программа стоит на том "сервере с белым IP", держит открытым единый TCP-порт и ждёт коннектов на него от удалённых преобразователей "RS-232<->Ethernet"? Или как-то по иному?

До начала обсуждения я был почти уверен, что проблема кроется в tcp соединении, потому что оно может зависеть от большего количества переменных, НО
после этого совета я начал заниматься непосредственно соединением преобразователь - тепловычислитель: под руку попался случайным образом оживший прибор, где я замерил напряжения во всех пинах


Между пинами 1,3 (при подключенном ТСП232) на рабочем преобразователе 10.9 В, на не рабочем оно 1,5.
Разобрал преобразователь, нашел там 10В, припаял провод в свободный пин db9 (так уже кто-то делал в интернетах), сделал это с 13ю приборами, все работают стабильно, ничего не тупит после перезагрузок и смен настроек. Почему пропадает и появляется на штатном конфиге +5в тоже тот еще вопрос. Ну ладно, надеюсь, будет работать. В новые приборы тоже впаяю этот провод.

PS. У нас сервер на 65 приборов izr (модемов) и десяток tsp, и список растет. В целом, стандартных программ для опроса хватает за глаза, но нет толковых программ для работ с базами данных, мониторинга, доведения всей этой информации до бухгалтерии необходимым образом (для обычного теплоэнергетика), а от тепловычислителей ощущения от работы будто со старыми советскими телевизорами работаешь.


Всем огромное спасибо за помощь!

Добавлено after 22 minutes 28 seconds:
[quote]PPS: Да, ещё вопрос к ТС: А программа учёта как видит каналы связи с приборами учёта? Они для неё - отдельные TCP-соединения? Или как-то по иному? Т.е. - может она видеть случаи разрывов/восстановлений TCP-соединений?
Эта программа стоит на том "сервере с белым IP", держит открытым единый TCP-порт и ждёт коннектов на него от удалённых преобразователей "RS-232<->Ethernet"? Или как-то по иному?[/uquote]

В программе учета есть главным образом список приборов учета с их конкретными id и параметрами опроса. Она устанавливает связь с программой - сервером, или напрямую, есть функции опроса через com, upd, tcp, модем. В моем случае каждый прибор учета в плане связи имеет адрес сервера один на всех и тсп порт свой собственный, можно сделать и один в некоторых серверных приложениях, но пока это не целесообразно и я в этом не разобрался. gprs модемы irz подключаются к программе от производителя irz к одному тсп порту, а приложение присваивает свой порт каждому прибору для подключения программы опроса. Преобразователи интерфейса подключаются каждый к своему порту к "коммутатору", который соединяет порт для прибора и порт для программы опроса.

Программа опроса показывает лишь "таймаут" когда ей не удается соединится с прибором учета и запустит процедуру вновь. Если она не может подключиться к серверу, то скажет о невозможности. Программа опроса не видит, что происходит после сервера, для нее это все "таймаут".

Программа держит открытыми порты для приборов, и тех кто хочет их опросить. Повторюсь, для преобразователей это разные порты, для irz gprs модемов это один порт в irz collector. Следующим шагом надо как то подсоединить преобразователи в 1 порт, желательно в irz collector.

Советую разобраться. Там не сложно: выставить флаг реюза при открытии прослушиваемого порта и потом в потоке обслуживания сокета просто форкаем новый поток с каждым соединением. Так работают все вебсервера, например. И один порт защищать фаерволлом сильно проще, нежели диапазон, который ещё и конечен.

Ну вот, как всегда...
Оказалось что не дедушка, а бабушка... Там (в приборе) ещё и не RS-232. Хотя вверху, на схеме рисовали как будто в теплосчётчике RS-232.

Ни нормальной общей схемы системы; ни распиновки соединения преобразователь RS232-Ethernet <-> теплосчётчик; даже так и не понятно - у вас к единому преобразователю RS232-Ethernet один теплосчётчик подключен или несколько параллельно? Ещё и вдруг всплыли "gprs модемы irz", о которых раньше ни слова не было...
С такими исходными данными вам не на форум надо, а к прорицателям Ктулху...

Вам нужен рядом человек, который соображает в технических деталях. Не плавает в них. И который всё сделает как надо. Ну или кто сможет хотя-бы технически грамотно формулировать вопросы здесь. Который будет знать - что такое "RS-232", "TCP-порт" и т.п.
Иначе так и будет дальше глючить.

Добавлено after 6 minutes 31 second:
Наверняка же есть готовые централизованные системы сбора и учёта тепла. Для э/энергии такие системы ещё с 90-хх годов многие конторы производят. Для тепла наверняка тоже аналогичные есть.
Только надо не отдельные счётчики покупать (да ещё и разные), а сразу систему сбора и учёта заказывать.