Коллеги, помогите с идеями. Задача такова. Есть удалённый компьютер, на котором крутится программа, собирающая информацию с датчиков и выдающая поток данных на COM-порт.
Требуется организовать передачу этих данных на центральный компьютер, который мог бы получать поток в квази-реальном времени. Ну, то есть, как если бы они были связаны шнурком RS-232 физически. В удалённом месте есть возможность подключить только USB-net stick или, скажем, GPRS-модуль. Но никаких драйверов писать нет возможности, особенно под USB.
Подскажите, каким образом можно решить такое с минимальной морокой?

Да, удаление - несколько километров в условиях города. То есть, радиомодули не внушают надёжности. Предпочтительнее всего интернет.

Может, я чего не понял, но...

Taltech TCP-com, на "удаленной" стороне клиент с виртуальным COM, на который программа шлет данные. С другой стороны он же (TCP-com) в режиме сервера, можно на виртуальный или реальный порт, или что и как вообще предполагается делать с принятым потоком ?

Да, и что за машина с какой ОС стоит на "удаленной" стороне ? Если не с win, то предложенное решение отпадает, само собой...

Сообщение отредактировал rx3apf - Mar 15 2018, 20:47

А поток информации какой? Допустимая средняя скорость, задержки?
Тоже интересует такая задача, M2M GPRS телематика стоит ~~100руб/месяц в РФ.
Но пока не понял, можно ли организовать такой режим на обычных GPRS модулях, те без покупки готовых устройств.

Сообщение отредактировал Leka - Mar 15 2018, 21:33

На удалённой машине Win7, поток относительно медленный: samle rate 8Hz, baud rate 115200. На центральном компьютере предполагается принять данные, обработать в МАТЛАБ, и выдать на монитор картинку. Задержка в несколько секунд допустима. Посмотрю на Taltech, спасибо.

Посмотрел, M2M услуга - только на страничке для корпоративных клиентов - не подходит для частного разового устройства?
(мне нужно мобильное решение)

Сообщение отредактировал Leka - Mar 15 2018, 21:55

как-то пробрасывал порты через сеть если не ошибаюсь с помощью com0com. но там надо было именно чужой программе устройство пробросить.
а если в свою программу обработки в матлабе, то можно наверное вообще тупо писать в файл на удалённом ПК чуть ли не средствами ОС.
copy COM1 somefile поди до сих пор работает и в win7
а из матлаба потом этот файл по сети как угодно забирать, хоть по http, и отображать.
ну а уж как лучше интернет на удалённом компе организовать в условиях города вам там поди виднее.

Если не ошибаюсь, там используется создание виртуальных портов от Eltima. Софтина с определенными ограничениями, но все решаемо. Ну, а на приемной стороне можно принять чем угодно, хоть терминалом с поддержкой TCP, хоть вообще на vbs с сетевым компонентом за пару часов накропать. Ну или опять же в порт перенаправить.

На удалённом компьютере сейчас программа и так пишет данные в таблицу, csv-file, помимо выдачи потока на порт. В USB вставлен модем (USB-net stick), при помощи которого есть доступ к компьютеру по интернету через TeamViewer. Через него же я забираю готовые файлы, останавливая запись и отрывая новый файл. Это могу делать раз в сутки или неделю. Но теперь нужно получать в реал-тайм, или почти в реал-тайм. Обработку в любом случае делать уже в центральном, на удалённом МАТЛАБ ставить громоздко, да и ни к чему. Вопрос как раз в том, чем передать данные по интернету, я в веб-сервисах полный ноль.

Буду разбираться. Вся проблема в том, что для меня эти сетевые компоненты, TCP и vbs - в диковинку. Нужно что-то готовое по максимуму.

Для меня, в общем-то, тоже (тридцать лет прекрасно обходился без ЯВУ). Но быстренько накропать что-то суррогатное из нескольких строчек basic может кто угодно, ничего там сложного нет. А, оказалось, вещь-то (vbs) удобная и и полезная, если нужно быстренько соорудить какую-нибудь консольную утилиту.

Уже много лет для решения подобных задач (преобразования интерфейса виртуального COM-порта в TCP-сокет) использую "Tibbo VSP Manager".
На прошлой работе он широко использовался и в системах АСКУЭ и АСДУЭ в коммерческих проектах.
По этой ссылке http://tibbo.com/ru/soi/software.html
Только там смотреть и ставить нужно именно только "VSP Manager". Остальное - не нужно.
Пример конфигурирования для создания порта в пассивном режиме:
Для активного режима - всё то же самое, только "Routing mode" == "Client" и нужно задать "Destination" вместо "Listening port":
Теперь при открытии порта COM51 будет установлено соединение COM51<->COM50.


Tibbo очень легко сконфигурить: только нужно определиться в каком режиме порт нужен - пассивный (при открытии COM-порта открывается TCP-порт в режиме listening и ждёт входящего соединения с удалённой стороны) или активный (при открытии такого COM-порта инициируется исходящее активное TCP-соединение на удалённый TCP-порт).
Протокола передачи в сокете там никакого нет, данные передаются "как есть", так что связать можно не только два приложения, работающие через интерфейс COM-порта, но и приложение работающее через COM-порт с приложением работающим через TCP-порт.
Есть ограничение для портов в пассивном режиме: они могут принимать только одно входящее соединение.

PS: Для VSP Manager кряков никаких не нужно - он и так работает без ограничений.

А Tibbo в режиме UDP понимает, когда исходящий порт у отправителя меняется ? А то у софтины от Taltech с этим проблема - если на удаленном конце сотовый модем в режиме UDP и интервал между посылками достаточно велик, то порт может смениться, а софтина этого не понимает, и продолжает отправлять на старый порт, и приходится перезапускать. В TCP все хорошо, а вот в UDP - такая неприятность...

Никогда не использовал её в UDP. Зачем?

В системах сбора данных с множеством абонентов и одним сервером. TCP там совершенно не подходит. Ладно, при случае попробую, интересно...

можно просто запустить какой-нибудь miniweb в директории с csv файлом.
а со стороны матлаба забирать этот файл частично по http, последние n байт.
если матлаб сам не умеет куски файла забирать, он может запускать какой-нибудь wget который будет просто докачивать недостающее, а csv файл пусть пишется непрерывно.
ну а самый простой наверное способ это какой-нибудь dropbox (google/yandex диск/...) на обоих компах установить, но вроде бы достаточно умный должен быть чтобы файл не целиком пересылать каждый раз если ему в конец что-то дописали.
на раз в несколько секунд поди хватит.
ну или может просто расшарить директорию с csv файлом через smb, и подключить на комп с матлабом как сетевой диск.

Есть несколько проектов, где на объектах стоит GSM модем, который имеет железячный COM-порт.
Этот порт виден в интернете по IP, и к нему возможен удаленный доступ как к виртуальному порту.
На центральном сервере стоит своя программа (писал в си++билдере), которая может достучаться до данного виртуального порта, ну а дальше работает с этим портом как с локальным.

Утилит и софта, как работать с виртуальным портом со стороны сервера- много, нужно только решить как оптимально этот порт организовать на удаленном устройстве. Например, GSM модем или COM/TCP или COM/DSL коробочка, да мало ли что.

В своем софте использовал Indy компоненты для виртуального порта, так как были какие-то глюки в сетевых компонентах от привычного AsyncProfessional.