I want to send and receive text files to and from a machine tool of early
1990's vintage controlling the data flow using RTS/CTS handshaking. (This is
called DNC).

Now the software I've been using to date ('RealTerm') seems to have a built
in transmit
buffer that I cannot disable, with the result that the machine says 'stop
sending' but the program continues for up to 16 characters resulting in
'overflow' errors. My work around has been to slow the data down to 300
baud, which is painfully slow but gets round the issue as the machine has
time to easily gobble up all the data without needing to pause for breath .

Looking at other programs for ascii file transfer Hyperterminal is a free
possibility, but although character by character it is fine, when sending
files it wants to use a protocol such as Kermit or X-Modem, which of course
the machine doesn't understand.

Is there any way of setting Hyperterminal up to just use hardware
handshaking and no protocol ? (Hyperterminal will run happily under Win7 if
you copy it's .exe and .dll from a windows release that carries it)

AWEM

On Fri, 12 Jul 2013 17:01:55 +0100, "Andrew Mawson"
wrote:


Now the software I've been using to date ('RealTerm') seems to have a built
in transmit
buffer that I cannot disable, with the result that the machine says 'stop
sending' but the program continues for up to 16 characters resulting in
'overflow' errors.

Just checking that it is the software and not windows...
Control panel - system - hardware - device manager - Ports - Comx -
properies - advanced - transmit buffer (1-16)

I guess one could use a batch file using piping but off hand I'm not sure if
that obeys the hardware handshaking. Its been a long time since having to do
this with a Spectrum computer.
Brian

--
From the Sofa of Brian Gaff Reply address is active
"Geo" wrote in message
...
On Fri, 12 Jul 2013 17:01:55 +0100, "Andrew Mawson"
wrote:


Now the software I've been using to date ('RealTerm') seems to have a
built
in transmit
buffer that I cannot disable, with the result that the machine says 'stop
sending' but the program continues for up to 16 characters resulting in
'overflow' errors.

Just checking that it is the software and not windows...
Control panel - system - hardware - device manager - Ports - Comx -
properies - advanced - transmit buffer (1-16)

"Geo" wrote in message ...

On Fri, 12 Jul 2013 17:01:55 +0100, "Andrew Mawson"
wrote:


Now the software I've been using to date ('RealTerm') seems to have a
built
in transmit
buffer that I cannot disable, with the result that the machine says 'stop
sending' but the program continues for up to 16 characters resulting in
'overflow' errors.

Just checking that it is the software and not windows...
Control panel - system - hardware - device manager - Ports - Comx -
properies - advanced - transmit buffer (1-16)

Yes I've been in there and disabled the Win7 buffer

AWEM

On Fri, 12 Jul 2013 18:13:48 +0100, "Andrew Mawson"
wrote:


Yes I've been in there and disabled the Win7 buffer

Could I suggest using Bray's Terminal - it can send a file, has macros
and a small scripting language. Various handshaking modes and it is
just a single .exe file.
It has been my RS232 debugging terminal of choice for years.

https://sites.google.com/site/terminalbpp/
has a download link to zip file.

So what exactly is the device its interfacing to?
Brian

--
From the Sofa of Brian Gaff Reply address is active
"Andrew Mawson" wrote in message
news
I want to send and receive text files to and from a machine tool of early
1990's vintage controlling the data flow using RTS/CTS handshaking. (This
is
called DNC).

Now the software I've been using to date ('RealTerm') seems to have a
built in transmit
buffer that I cannot disable, with the result that the machine says 'stop
sending' but the program continues for up to 16 characters resulting in
'overflow' errors. My work around has been to slow the data down to 300
baud, which is painfully slow but gets round the issue as the machine has
time to easily gobble up all the data without needing to pause for breath
.

Looking at other programs for ascii file transfer Hyperterminal is a free
possibility, but although character by character it is fine, when sending
files it wants to use a protocol such as Kermit or X-Modem, which of
course the machine doesn't understand.

Is there any way of setting Hyperterminal up to just use hardware
handshaking and no protocol ? (Hyperterminal will run happily under Win7
if you copy it's .exe and .dll from a windows release that carries it)

AWEM

"Brian Gaff" wrote in message ...


--
From the Sofa of Brian Gaff Reply address is active
"Andrew Mawson" wrote in message
news
I want to send and receive text files to and from a machine tool of early
1990's vintage controlling the data flow using RTS/CTS handshaking. (This
is
called DNC).

Now the software I've been using to date ('RealTerm') seems to have a
built in transmit
buffer that I cannot disable, with the result that the machine says 'stop
sending' but the program continues for up to 16 characters resulting in
'overflow' errors. My work around has been to slow the data down to 300
baud, which is painfully slow but gets round the issue as the machine has
time to easily gobble up all the data without needing to pause for breath
.

Looking at other programs for ascii file transfer Hyperterminal is a free
possibility, but although character by character it is fine, when sending
files it wants to use a protocol such as Kermit or X-Modem, which of
course the machine doesn't understand.

Is there any way of setting Hyperterminal up to just use hardware
handshaking and no protocol ? (Hyperterminal will run happily under Win7
if you copy it's .exe and .dll from a windows release that carries it)

AWEM


So what exactly is the device its interfacing to?
Brian

It's a Traub TX8F CNC controller in my Traub TND350G 4 1/2 ton CNC lathe

Full story of its acquisition and resurrection here (you'll need to register
to see the pictures but it's free and interesting):

http://madmodder.net/index.php/topic,8261.0.html

AWEM

On 12/07/13 17:01, Andrew Mawson wrote:
I want to send and receive text files to and from a machine tool of early
1990's vintage controlling the data flow using RTS/CTS handshaking.
(This is
called DNC).

Now the software I've been using to date ('RealTerm') seems to have a
built in transmit
buffer that I cannot disable, with the result that the machine says 'stop
sending' but the program continues for up to 16 characters resulting in
'overflow' errors. My work around has been to slow the data down to 300
baud, which is painfully slow but gets round the issue as the machine
has time to easily gobble up all the data without needing to pause for
breath .

Looking at other programs for ascii file transfer Hyperterminal is a
free possibility, but although character by character it is fine, when
sending files it wants to use a protocol such as Kermit or X-Modem,
which of course the machine doesn't understand.

Is there any way of setting Hyperterminal up to just use hardware
handshaking and no protocol ? (Hyperterminal will run happily under Win7
if you copy it's .exe and .dll from a windows release that carries it)

AWEM
Have you tried PuTTY? It tends to behave itself in most ways.

http://www.chiark.greenend.org.uk/~sgtatham/putty/

On Friday, 12 July 2013 17:01:55 UTC+1, Andrew Mawson wrote:
I want to send and receive text files to and from a machine tool of early

1990's vintage controlling the data flow using RTS/CTS handshaking. (This is

called DNC).



Now the software I've been using to date ('RealTerm') seems to have a built

in transmit

buffer that I cannot disable, with the result that the machine says 'stop

sending' but the program continues for up to 16 characters resulting in

'overflow' errors.

Isn't that likely to be the 16550UART HW buffer, rather than RealTerm?

FWIW the source to RealTerm is available, you could take a peek. IIRC it's written in Delpho though, so not the easiest of things to recompile. Someone round here might be able to help if you pointed them at the code. Or even the RealTerm Author?

Jon N

On 12/07/13 21:07, jkn wrote:
FWIW the source to RealTerm is available, you could take a peek. IIRC it's written in Delpho though, so not the easiest of things to recompile. Someone round here might be able to help if you pointed them at the code. Or even the RealTerm Author?

The Free Pascal Compiler will compile most Delphi.

http://www.freepascal.org/

--
Bernard Peek

On 12/07/2013 21:07, jkn wrote:
On Friday, 12 July 2013 17:01:55 UTC+1, Andrew Mawson wrote:
I want to send and receive text files to and from a machine tool of
early

1990's vintage controlling the data flow using RTS/CTS handshaking.
(This is

called DNC).



Now the software I've been using to date ('RealTerm') seems to have
a built

in transmit

buffer that I cannot disable, with the result that the machine says
'stop

sending' but the program continues for up to 16 characters
resulting in

'overflow' errors.

Isn't that likely to be the 16550UART HW buffer, rather than
RealTerm?

The 16550 will respect RTS/CTS handshaking though without needing to
empty its fifo.

FWIW the source to RealTerm is available, you could take a peek. IIRC
it's written in Delpho though, so not the easiest of things to
recompile. Someone round here might be able to help if you pointed
them at the code. Or even the RealTerm Author?

I have done tons of serial comms in Delphi...

--
Cheers,

John.

/================================================== ===============\
| Internode Ltd - http://www.internode.co.uk |
|-----------------------------------------------------------------|
| John Rumm - john(at)internode(dot)co(dot)uk |
\================================================= ================/

In article ,
John Rumm writes:
On 12/07/2013 21:07, jkn wrote:
On Friday, 12 July 2013 17:01:55 UTC+1, Andrew Mawson wrote:
I want to send and receive text files to and from a machine tool of
early

1990's vintage controlling the data flow using RTS/CTS handshaking.
(This is

called DNC).



Now the software I've been using to date ('RealTerm') seems to have
a built

in transmit

buffer that I cannot disable, with the result that the machine says
'stop

sending' but the program continues for up to 16 characters
resulting in

'overflow' errors.

Isn't that likely to be the 16550UART HW buffer, rather than
RealTerm?

The 16550 will respect RTS/CTS handshaking though without needing to
empty its fifo.

I would beg to differ.
Some of the newer chips with larger FIFOs have automatic flow control
handling (both RTS/CTS and XON/XOFF), but a 16550A doesn't.

--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]

On 14/07/2013 18:55, Andrew Gabriel wrote:
In article ,
John Rumm writes:
On 12/07/2013 21:07, jkn wrote:
On Friday, 12 July 2013 17:01:55 UTC+1, Andrew Mawson wrote:
I want to send and receive text files to and from a machine tool of
early

1990's vintage controlling the data flow using RTS/CTS handshaking.
(This is

called DNC).



Now the software I've been using to date ('RealTerm') seems to have
a built

in transmit

buffer that I cannot disable, with the result that the machine says
'stop

sending' but the program continues for up to 16 characters
resulting in

'overflow' errors.

Isn't that likely to be the 16550UART HW buffer, rather than
RealTerm?

The 16550 will respect RTS/CTS handshaking though without needing to
empty its fifo.

I would beg to differ.
Some of the newer chips with larger FIFOs have automatic flow control
handling (both RTS/CTS and XON/XOFF), but a 16550A doesn't.


Yup, I was about to say I could have worded that better - in that I was
not trying to suggest that the UART itself would do fully automatic
CTS/RTS handling without software intervention, unlike on the 16650 and
later devices.

However, thinking about it now, I am not even convinced that it will
inhibit transmit of what is actually in the fifo when CTS goes inactive.

There is a windows registry setting where you can control the number of
bytes used in the Tx FIFO:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Serial\TxFIFO

You can also turn the FIFO off altogether if you want by setting the
ForceFifoEnable key to 0



--
Cheers,

John.

/================================================== ===============\
| Internode Ltd - http://www.internode.co.uk |
|-----------------------------------------------------------------|
| John Rumm - john(at)internode(dot)co(dot)uk |
\================================================= ================/

"John Rumm" wrote in message
...

On 14/07/2013 18:55, Andrew Gabriel wrote:
In article ,
John Rumm writes:
On 12/07/2013 21:07, jkn wrote:
On Friday, 12 July 2013 17:01:55 UTC+1, Andrew Mawson wrote:
I want to send and receive text files to and from a machine tool of
early

1990's vintage controlling the data flow using RTS/CTS handshaking.
(This is

called DNC).



Now the software I've been using to date ('RealTerm') seems to have
a built

in transmit

buffer that I cannot disable, with the result that the machine says
'stop

sending' but the program continues for up to 16 characters
resulting in

'overflow' errors.

Isn't that likely to be the 16550UART HW buffer, rather than
RealTerm?

The 16550 will respect RTS/CTS handshaking though without needing to
empty its fifo.

I would beg to differ.
Some of the newer chips with larger FIFOs have automatic flow control
handling (both RTS/CTS and XON/XOFF), but a 16550A doesn't.


Yup, I was about to say I could have worded that better - in that I was not
trying to suggest that the UART itself would do fully automatic CTS/RTS
handling without software intervention, unlike on the 16650 and later
devices.

However, thinking about it now, I am not even convinced that it will
inhibit transmit of what is actually in the fifo when CTS goes inactive.

There is a windows registry setting where you can control the number of
bytes used in the Tx FIFO:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servi ces\Serial\TxFIFO

You can also turn the FIFO off altogether if you want by setting the
ForceFifoEnable key to 0





I cannot find a specification anywhere saying how soon transfer should stop
after the CTS/RTS transition. I'm getting at least 16 characters after the
flag drops

AWEM

On 15/07/13 18:25, John Rumm wrote:
On 14/07/2013 18:55, Andrew Gabriel wrote:
In article ,
John Rumm writes:
On 12/07/2013 21:07, jkn wrote:
On Friday, 12 July 2013 17:01:55 UTC+1, Andrew Mawson wrote:
I want to send and receive text files to and from a machine tool of
early

1990's vintage controlling the data flow using RTS/CTS handshaking.
(This is

called DNC).



Now the software I've been using to date ('RealTerm') seems to have
a built

in transmit

buffer that I cannot disable, with the result that the machine says
'stop

sending' but the program continues for up to 16 characters
resulting in

'overflow' errors.

Isn't that likely to be the 16550UART HW buffer, rather than
RealTerm?

The 16550 will respect RTS/CTS handshaking though without needing to
empty its fifo.

I would beg to differ.
Some of the newer chips with larger FIFOs have automatic flow control
handling (both RTS/CTS and XON/XOFF), but a 16550A doesn't.


Yup, I was about to say I could have worded that better - in that I
was not trying to suggest that the UART itself would do fully
automatic CTS/RTS handling without software intervention, unlike on
the 16650 and later devices.

The UART can. I've written device drivers for it.

If its programmed to respect RTS/CTS that absolutely halts transmission
at that point. Then teh ring buffer fills up, and then that should halt
upstream sofware elements.

Under windows all bets are off, of course.
Unix you can make em work with proper handshaking cos we used to drive
9600 baud ,modems at 115k no problem.

stty -crtscts would switch that on.,


However, thinking about it now, I am not even convinced that it will
inhibit transmit of what is actually in the fifo when CTS goes inactive.

It will if it set to respect it.
There is a windows registry setting where you can control the number
of bytes used in the Tx FIFO:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Serial\TxFIFO

You can also turn the FIFO off altogether if you want by setting the
ForceFifoEnable key to 0


What you need to do is to find the command that sets the chipset/driver
to CTS/RTS control.

The windows equivalent of an IOCTL call. I used to know what it was...

Oh. It looks relatively ****e
http://stackoverflow.com/questions/8...r-dsr-possible

Short answer. Ditch windows.

--
Ineptocracy

(in-ep-toc-ra-cy) €“ a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

On 12/07/2013 17:01, Andrew Mawson wrote:
I want to send and receive text files to and from a machine tool of early
1990's vintage controlling the data flow using RTS/CTS handshaking.
(This is
called DNC).

Now the software I've been using to date ('RealTerm') seems to have a
built in transmit
buffer that I cannot disable, with the result that the machine says 'stop
sending' but the program continues for up to 16 characters resulting in
'overflow' errors. My work around has been to slow the data down to 300
baud, which is painfully slow but gets round the issue as the machine
has time to easily gobble up all the data without needing to pause for
breath .

Looking at other programs for ascii file transfer Hyperterminal is a
free possibility, but although character by character it is fine, when
sending files it wants to use a protocol such as Kermit or X-Modem,
which of course the machine doesn't understand.

Is there any way of setting Hyperterminal up to just use hardware
handshaking and no protocol ? (Hyperterminal will run happily under Win7
if you copy it's .exe and .dll from a windows release that carries it)

AWEM


In my experience Hyperterminal has some major problems that alternatives
such as Tera Term (free) overcome.

Tera term can be set for hardware handshaking

I've sent ASCII strings a to bespoke interface by just constructing a
text file in a text editor (Textpad) and asking Tera Term to send the
text file. Turn on logging for the results that come back (which is put
into a text file)
--
mailto:news{at}admac(dot}myzen{dot}co{dot}uk

On 12/07/2013 17:01, Andrew Mawson wrote:
I want to send and receive text files to and from a machine tool of early
1990's vintage controlling the data flow using RTS/CTS handshaking.
(This is
called DNC).

Now the software I've been using to date ('RealTerm') seems to have a
built in transmit
buffer that I cannot disable, with the result that the machine says 'stop
sending' but the program continues for up to 16 characters resulting in
'overflow' errors. My work around has been to slow the data down to 300
baud, which is painfully slow but gets round the issue as the machine
has time to easily gobble up all the data without needing to pause for
breath .

Looking at other programs for ascii file transfer Hyperterminal is a
free possibility, but although character by character it is fine, when
sending files it wants to use a protocol such as Kermit or X-Modem,
which of course the machine doesn't understand.

Is there any way of setting Hyperterminal up to just use hardware
handshaking and no protocol ? (Hyperterminal will run happily under Win7
if you copy it's .exe and .dll from a windows release that carries it)

Just use the Send Text File option from the transfer menu. It just dumps
a file to the screen and also sends out the serial port as if you were
keying it.


--
Cheers,

John.

/================================================== ===============\
| Internode Ltd - http://www.internode.co.uk |
|-----------------------------------------------------------------|
| John Rumm - john(at)internode(dot)co(dot)uk |
\================================================= ================/