I need a suggestion to better understand if I'm using com0com and hub4com in the right way…this is my config:
a com0com virtual null modem (COM4<>CNCB0) is used to get input data from the Windows "Generic Text Only" printer (configured on virtual COM4). After this I used hub4com to "split" the ASCII stream in 2 data paths: one stream goes to a dot matrix printer connected via Ethernet (hub4com creates a TCP client that connect to Jetdirect port 9100 of the printer) and the other one is used for a local TCP server on port 5555 (hub4com create a TCP server that will be used by a networked PC to collect the same data printed on paper). This is the hub4com command-line:
hub4com.exe --route=0:1,2 \\\\.\\CNCB0 --use-driver=tcp *5555 --use-driver=tcp *192.168.1.91:9100[/code]
1. Yes, there is a risk to lose data when hub4com (re)create the TCP
connection to the printer. Also there is a risk to lose data when
you printing a big job (printer's buffer become full so hub4com can't
put data to the destination port).
It's because with "-route=0:1,2" there is not internal flow control routed
from 1 and 2 to 0 (internal means that hub4com does not read data
from source port if it can't put it to the destination port).
2. If the TCP client is switched off you will periodically get
"Write lost TCP(1): …, total …" message.
If the printer is switched off you will periodically get
"Write lost TCP(2): …, total …" message.
If both are off you will periodically get both messages.
Other words you already have "Enable Buffer Overrun" emulated in hub4com.
With latest hub4com from CVS you can do the following:
: NOTE: copy and paste to concole (it's not a bat-file script)
: Set required flow control on the printer's side
mode com4 octs=on odsr=on dtr=on rts=on
: Start hub4com
# - Route data CNCB0(0) --> TCP(1) TCP(2)
# - Route data TCP(1) --> CNCB0(0)
# - Route data TCP(2) --> CNCB0(0)
# - Route flow control TCP(1) --> CNCB0(0)
# - Route flow control TCP(2) --> CNCB0(0)
# The DTR should be in raised state on CNCB0
# if any TCP port is connected
# connect TCP(2) only when the DSR is in raised state
# Disable writing to the CNCB0
# Restore write queue limit for TCP(1)
# Set write queue limit to a big value for TCP(2)
# (it's optional)
# Try connect each minute
In my answer I presumed that "TCP client" from you question 2 is "a networked PC to collect".
Isn't it "a TCP client" that "hub4com creates"?
You are absolutely right: in point#2 when I wrote “TCP client” I assumed that this is the “networked PC I’m using to collect data”. I rewrite here the sentence:_
I'm asking this because I want to be sure that the “networked PC I’m using to collect data” continues to get data also in case that the printer is switched off (or disconnected from the network) and, at the same time, I want to be sure that the printer continues to print data also in case that the “networked PC I’m using to collect data” is switched off (or disconnected from the network). If useful please suggest some com0com/hub4com parameters that will best suit my needs._
I read your solution very closely but my problem is that I cannot compile the com0com / hub4com CSV package easily (I quickly tried with Visual Studio 2010 with no luck, probably I’m missing some required SDK/DDK)…is something I can do to improve my config with the current released/stable version of hub4com?
In fact you do not need any com0com's virtual serial ports.
The hub4com command-line:
hub4com --bi-route=0:1,2 --use-driver=tcp 9100 192.168.1.91:9100 *5555
Type: Standard TCT/IP Port
Very nice setup! In this way I don't need anymore the com0com software.
With this new suggested configuration there is still the possibility to lose some data or now there is some sort of flow control between TCP data flows? And there is no need to specify a "permanent" connection (* option) for the 192.168.1.91:9100?
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.