type a file to serial port and receive it on another computer

Hello all,

Recently I remembered that it was possible to make a serial connection
between two 'puters and send, from the commandprompt and without using any
(other) programs, a textfile from one to the other. I say "was", as I
can't seem to repeat it between two XPsp3 machines.

Specs:
The machines are connected thru a so-called "null modem" (three-wire) cable
(with the handshake signals wrapped back onto the same conector).

A "mode com1 9600,n,8,1" command has been used (trying to debug the matter)
on both to set up the connection, and "mode com1 /status" returns the same
for both 'puters:

Baud: 9600
Parity: None
Data Bits: 8
Stop Bits: 1
Timeout: ON
XON/XOFF: OFF
CTS handshaking: OFF
DSR handshaking: OFF
DSR sensitivity: OFF
DTR circuit: ON
RTS circuit: ON

The problem:
Both "type com1" and "copy com1 bla" on the target 'puter finish
immediatlily (do not wait for incoming data).

The null-modem connection itself seems to be fine, as I've used a simple
RS232 application which shows the data coming in.

Does anyone recognise the problem and can tell me what goes wrong ?

Regards,
Rudy Wieser

R.Wieser wrote:
Hello all,

Recently I remembered that it was possible to make a serial connection
between two 'puters and send, from the commandprompt and without using any
(other) programs, a textfile from one to the other. I say "was", as I
can't seem to repeat it between two XPsp3 machines.

Specs:
The machines are connected thru a so-called "null modem" (three-wire) cable
(with the handshake signals wrapped back onto the same conector).

A "mode com1 9600,n,8,1" command has been used (trying to debug the matter)
on both to set up the connection, and "mode com1 /status" returns the same
for both 'puters:

Baud: 9600
Parity: None
Data Bits: 8
Stop Bits: 1
Timeout: ON
XON/XOFF: OFF
CTS handshaking: OFF
DSR handshaking: OFF
DSR sensitivity: OFF
DTR circuit: ON
RTS circuit: ON

The problem:
Both "type com1" and "copy com1 bla" on the target 'puter finish
immediatlily (do not wait for incoming data).

The null-modem connection itself seems to be fine, as I've used a simple
RS232 application which shows the data coming in.

Does anyone recognise the problem and can tell me what goes wrong ?

Regards,
Rudy Wieser

One of the requirements, was to send an EOT character

https://en.wikipedia.org/wiki/End-of...sion_character

so that the connection could close properly.

Now, mine is all cabled up and ready to go. The two machines
already have a serial RS232 interconnect (COM1 == COM3), with a null modem
thingy in the center (connects TX to RX, RX to TX, so
two computers can talk to one another, without shorting a
TX to a TX).

I fired up putty to verify, on the receiving end.
Set baud rate to 57600, enabled RTS/CTS.

On sending end

mode COM1 BAUD=57600 PARITY=n DATA=8 STOP=1 RTS=on
type sample.txt COM1
copy con: COM1
Enter
ctrl-Z
Enter === flushes input at a guess

The problem seems to be mostly on the receiving end.

1) Doesn't seem to have permission to copy COM3 to anything.
2) Does see the ctrl-Z coming across the cable. Closes COPY.

copy COM3 impossible.txt

impossible.txt ends up with "0 files copied" string in it.

The receive end is not at all happy. Could this be
symptoms that "port is busy" ? Probably.

Evidence when receiving in putty, is "it's working to the
best of puttys knowledge". Ownership issues from Command Prompt
seem an issue right now. When putty exist, you'd think COM3
could then be captured by anyone.

So, nope, doesn't work for me at the moment. Situation
"ripe" but "not harvested". All the ingredients seem to be
there, but Clippy has broken it.

HTH,
Paul

Paul,

One of the requirements, was to send an EOT character

Yep, I also tried sending files terminated with it. Alas, no change.

impossible.txt ends up with "0 files copied" string in it.

I found out that in my case it depends: directly after booting it doesn't
return and needs to be killed thru the taskmanager, but after having used my
beforementioned RS232 checking program (even though "mode com1" showing the
same !) it returns directly (either not displaying anything or as you
described, with a zero-length file)

The receive end is not at all happy.

Thats my assumption too.

Could this be symptoms that "port is busy" ? Probably.

As I can run that "RS232 checking program" without a problem (and it
receives the send data), I would say that the port isn't busy or owned by
another program.

So, nope, doesn't work for me at the moment. Situation
"ripe" but "not harvested". All the ingredients seem to be
there, but Clippy has broken it.

:-) /Something/ seems to be "broken" alright. I just wish I knew how to
fix it.

Regards,
Rudy Wieser

A heads-up:

I just tried to use "type com1" on a machine running w98 DOS, and it works
as expected.

I have no clue if its just an XP, or more globally a Windows problem though.

Regards,
Rudy Wieser

R.Wieser wrote:
A heads-up:

I just tried to use "type com1" on a machine running w98 DOS, and it works
as expected.

I have no clue if its just an XP, or more globally a Windows problem though.

Regards,
Rudy Wieser

After doing an additional number of test cases,
my conclusion is, someone has gone to a great deal
of trouble to break it. Everything I tried had
a bad outcome.

At the receiver, this works better:

copy COM3: output.txt

but even so, I can't get copy.exe to exit,
and get to keep a proper output.txt file.

I tried sending

single character 0x03 hex
single character 0x04 hex
ctrl-Z (which gets remapped by the OS)

Paul

Paul,

At the receiver, this works better:

copy COM3: output.txt

I've tried "type com1" as well as "copy com1 con". Neither works, but
depending on what program I ran before it it fails differently (instantly
returning, or not returning at all) - even though "mode com1 /status" shows
no difference between.

The only thing I can still try is to, instead of a z-modem cable, use one
with the signalling lines connected too. That will have to wait until I can
find the cable for it though.

Regards,
Rudy Wieser

Paul,

The only thing I can still try is to, instead of a z-modem cable, use one
with the signalling lines connected too. That will have to wait until I
can find the cable for it though.

I realized I had still had my crossover dongle, and even could find it back
(Jay!). Alas, no change.

I can't get copy.exe to exit,

Same here, regardless of the used cable (z-modem or full-wired). Only
"type com1 datafile" works /somewhat/ on the DOS 'puter - I still have to
press Ctrl-C, which "^C" output than (ofcourse) also gets stored in the
file. Not that that is the only thing, as the output file also starts with
a slew of NUL (0x00) chars.

It looks like that copying a textfile over COM1 is a bitof a tricky
business...

Regards,
Rudy Wieser

On 21.05.2021 11:10, R.Wieser wrote:

It looks like that copying a textfile over COM1 is a bitof a tricky
business...

Why not use a communication program? I don't know
if HyperTerm from Windows XP still works in Win10,
but there are many free replacements.

Or try PowerShell instead of CMD (type and copy
are build-in commands and so part of the shell program).