Использование COM весов в 1С на RDP-клиенте

(2)
тут имеется в виду работа по RDP, когда проброшенный в RDP COM-порт работает с огромными задержками да ещё через задницу, а то и вообще не работает.
Решение, конечно в лоб как говорится, но рабочее.
Весы подключаются к конвертеру и из любой точки локальной сети к ним есть доступ,
а если пробросить порты через роутер с белым ip-адресом, то и из интернета.
Да и конвертеры есть многопортовые.

Данное китайское чудо работает (у меня при комнатной температуре), но парни, которые торгуют ими, ездили в Китай и смотрели технологию производства, тестируют по полной программе.
Они эти конвертеры используют в ЖКХ, для подключения различных счётчиков и прочего.

Просто как вариант, не у всякого есть мозги настроить предложенное Вами решение. :-)
Про себя говорю, да ещё когда нужно "вчера", приходится искать варианты...
.

(6) Если я правильно понимаю, то при использовании любого преобразователя порта есть два варианта работы:
- либо эмуляция com устройства на конечном сервере через доп.софт от эмулятора,
- либо работа по ethernet.

Первый вариант ограничивает нас на использование большого количества устройств, т.к. мы переносим устройства на конечный сервер "физически". Проверено 100500 раз, если на сервере более 20 com устройств - они начинают вылетать. Но нужно уточнить с каким com портом будет подключаться устройство, а то можно навзвешивать на других весах. Но если устройств мало, то использовать адаптер - отличный вариант.

Второй вариант подразумевает, что штатным драйвером мы не можем воспользоваться, т.к. нет com устройства на сервере. Переписывать драйвер на использование com команд через ethernet все равно нужно. И зачем городить огород с железкой, если все-равно писать драйвер?

(14) именно. Но в том ПО стояла задача пробросить com-порт без уточнения чем будет принимающая сторона. В Вашем случае все равно принцип сохраняется: есть две программы, обменивающиеся между собой данными по сети (маршрут трафика в данном случае не существенен). На компе с оборудованием HTTP_SCALE слушает сетевой порт, при необходимости пинает com-порт и отсылает пришедший ответ. Сталкивался и с вопросами передачи данных (фоновая синхронизация содержимого папок винды при терминальном подключении, реализовывал на VC), и с вопросами работы с портами оборудования (принтер этикеток без дров на убунте, реализовывал на Qt) - все просто, если получится достать спецификации сигналов для различного оборудования то выйдет неплохой коммерческий продукт.

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