On 1/3/21 10:27 AM, Dennis Lee Bieber wrote:
>  But the OP explicitly stated the use of a simple terminal program
> (though HyperTerm is ancient and $$$, since the light version is no longer
> available on Windows... TeraTerm and PuTTY in serial connection mode might
> do).

And the COM port driver allows a simple terminal program to use the
remote serial ports.

> How would the OP handle the 6 serial ports from this configuration?

Six different instances of the COM driver pointed to each remote serial
port.

Then HyperTerm / ProComPlus / Quicken / pager program / fax program
could use COM1, COM2, COM3, COM4, COM5, COM6 at their discretion.  Just
like they would for a hardware COM port.

You could even have Windows Routing and Remote Access Server provide
Dial Up Networking on the aforementioned COM ports.

> Open 6 shell windows/xterm and run minicom/cu in each (I presume they
> expect to receive some status back from the end devices in response to
> any commands sent, otherwise a simple "echo command > serialport" would
> maybe suffice and only use one shell window/xterm). Too messy? Open
> one shell window/xterm with 6 tabs, each tab running minicom/cu.

The pager / fax / banking program that need to connect to a modem on a
serial port are the exact type of programs that can't / won't use
something like minicom / cu on a remote machine.

> Create a custom application (Python with wxPython/Python
> GTK/Tkinter...) with input and response widgets, and [send] button?

That won't work when the time clock / attendance application needs to
connect to the time clocks in the factory over a serial port.

> * Don't have keyboard/mouse/monitor on the R-Pi?
> Configure the R-Pi VNC server. Install VNC client on the Windows box.
> Connect to R-Pi using VNC client.

That is untennable in a business environment.  Especially when there is
an option to install a virtual COM port that connects across the network
and allows the application to run the same way that it has for the last
15 years.

> One now has a window on the Windows box that looks just like the
> monitor did in the previous option, and the same serial port handling
> is available (minicom/cu in shell window/tab) or custom application.

Nope.

It's about more than simply talking to the serial port.  It's about
/how/ you talk to the serial port and /where/ you talk to the serial port.

Things like the time clock application or the fax software running on
Windows (where) need (as in they have no choice in the matter) to talk
to a local (to Windows) COM port (how).

> Note: GUI applications need not apply (though a custom application
> using text-only curses that handles all 6 serial ports at once is
> feasible)

GUI applications work perfectly fine with the virtual COM port.

> Run a web-server on the R-Pi (nginx?). Create a web-app (flask/django,
> PHP?) which presents a form with 6 sections (one for each serial port,
> each section has a command input field, and a response output field).

So now you want to add even more complexity -and- code development into
the process.

You're selling the virtual COM port for me.

1)  Install and configure the remote serial port server.
2)  Install and configure the virtual COM port driver.
3)  Reconfigure the existing program to use the new COM port.
4)  Profit!!!

> Creating VCPs seems fraught with difficulties.

Not really.

It's quite like using an IP port for a printer.  It's been quite
standard for the better part of 30 years.  Quite easy to do too.

> Which leads us back to something like
> https://www.eltima.com/products/com-port-redirector/
> (which, strangely, appears to be the same as
> https://www.eltima.com/products/serial-over-ethernet/ with a different
> name). One runs server side on the R-Pi (suspect one has to build
> from source, they likely don't have an ARMHF build), and client side
> on Windows to create the VCPs.

Which seems to be a varient of what I'm describing.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05