Hardware Flow Control Does not work in Teraterm
no response??
@zmatsuo I don't see the executable anywhere? Do you have a link? I am seeing files from over 2 years ago only/ thanks
We wants to solve the serial problems.
Recent binary can be found here.
https://osdn.net/projects/ttssh2/storage/snapshot/
But we have not yet investigate and no serial fixes have been made yet.
Is Hyper Terminal pre installed in Windows?
i tried Hyperterminal on an older computer, yes it was pre installed. I also tried various other terminal programs and they are working with flow control.
Just to be clear I am using a built in serial port (DB9 connector) on my motherboard, not any adapter or USB to Serial cable. USB to TTL or otherwise. I tested Teraterm on other computers with the same serial port configuration, the same problem exists. It appears as though Teraterm is ignoring the CTS and RTS signals.
The signals are RTS and CTS. I read somewhere that the signal names have changed in TeraTerm. Could this be the problem?
When I use a USB adapter like a CH340 or an FT232, flow control is working (although I did notice some problems with the FT232 setup).
So basically the problem is only with a real RS232 serial port.
Tera Term communicates using the same WIN32 API if the port number and/or hardware changes.
So basically the problem is only with a real RS232 serial port.
It is very strange.🤔
What signals does Teraterm use for Hardware Flow Control? Earlier versions showed CTS & RTS.
I am wondering if the signals are reversed or if Teraterm is using DTR & DSR?
I am using RTS & CTS and it's working for most terminal programs except Teraterm. (as I mentioned previously, Teraterm only works when there is a USB adapter like a USB to TTL, CH340, FT232RL, etc) These are the only tow adapters I have tested.
Flow control
Xon/Xoff RTS/CTS (rename from "hardware" 4.105) DSR/DTR (added 4.105) none
I am thinking about how to test...
oh so they renamed hardware to RTS/CTS.
I am assuming you have no desktop or laptop with a serial port. I have several and I am willing to test here. Let me know. Regards,
I changed some parameters when opening serial port, and this snapshot may not have this issue.
https://ttssh2.osdn.jp/tmp/teraterm-5.0-r10587-20230207-zmatsuo.zip
Could you please let us know the result in your environment?
Same thing, does not work with RTS, CTS flow control. Data is lost. The serial port communication is working, just no flow control using the RTS/CTS pins. It looks like Teraterm is ignoring the RTS/CTS signals.
Hyperterminal works using RTS/CTS and various other terminal programs I have tested. I was hoping to use Teraterm for this because of the VT100 capabilities.
Is it possible that the names are reversed in the software? i.e. RTS named CTS and CTS named RTS? This would definitely cause an issue.
I tried three different desktop computers. Two have a built in serial port on the motherboard the Lenovo computer has a card I installed. I have three pictures to add of the serial port setup screen.
I tried various versions of Teraterm even the very first on V2.3 they all have this issue. The serial port is working on all versions, just no flow control so data is lost, and I can't use Teraterm because of this.
EDIT: I should mention (again) that Teraterm is working with flow control when using an FTDI cable with RTS/CTS signals or other USBtoTTL modules or cables such as CH340G and CP2102. It is only when using the RS232 serial port (DB9) that Teraterm ignores the flow control signals. This is evident with all version of Teraterm.
Okay, I'm aware of that you are using real serial port, not USB serial converter.
Tera Term doesn't detect a com port is USB serial port or real serial port. Same code is used. You told that hardware flow with USB serial converter works well. We guess the difference comes from like serial chip behavior or hardware buffer size in serial chip or behavior of driver or buffer size of Tera Term or initialize parameters of serial port by Tera Term.
We want to confirm about your environment and operation for you are reporting this problem.
I and zmatsuo have FTDI serial USB converters. And I have three PCs that have real serial port. But we don't have serial analyzer, and don't know the device you are connecting ahead of serial cable, and don't know your operation to reproduce this issue.
+-- PC(DTE) ---------------------+ | [Tera Term or Hyper Terminal] | | | | | +--------------------[real serial port]---(serial cable)---[some device] ... What is this? +--------------------------------+
What serial analyzer are you use?
And how connected it? Like this?
+-- PC(DTE) ---------------------+ | [monitoring software?]-------[USB]-------------------------------+ | | | | [Tera Term or Hyper Terminal] | | | | | | | +--------------------[real serial port]---(serial cable)---[analyzer]---[some device] +--------------------------------+
Is this two images show that Tera Term ignores hardware flow control and HyperTerminal does not ignore hardware flow control? Can we see analyze result of Tera Term?
Please let us know followings: - Your operations.
- Expected result of each lines. - Actual result of each lines.
In my understanding, hardware flow control is followings:
Now we are considering flow control of B.
refs. https://tldp.org/HOWTO/Serial-HOWTO-19.html#ss19.4 https://tldp.org/HOWTO/Text-Terminal-HOWTO-11.html#ss11.7 https://en.m.wikipedia.org/wiki/RS-232#RTS,_CTS,_and_RTR https://www.youtube.com/watch?v=lwuZ7xYtMKk&t=140s A. Original define (half duplex, asymnetric) ===== 1. PC tells "I Request To Send to you." PC(DTE, sender) device(DCE) RxD ---------- TxD ---------- RTS 1---------> CTS ---------- ===== 2. device acks "You are Cleared To Send to me." PC device RxD ---------- TxD ---------- RTS 1---------> CTS <---------1 ===== 3. PC sends data. PC device RxD ---------- TxD ---------> RTS 1---------> CTS <---------1 B. Mordan define (full duplex, symmetric) ===== 1. device tells "I am Ready To Receive." PC(DTE, sender) device(DCE) RxD ---------- TxD ---------- RTS ---------- CTS <---------1 ===== 2. PC can send data. PC device RxD ---------- TxD ---------> RTS ---------- CTS <---------1 ===== 3. If device buffer close to overflow, device tells "I am not Ready To Receive." PC device RxD ---------- TxD ---------> RTS ---------- CTS <---------0 ===== 4. PC stops sending. PC device RxD ---------- TxD ---------- stop RTS ---------- CTS <---------0 ===== 5. If buffer data is processed and enough buffer space, device tells "I am Ready To Receive." PC device RxD ---------- TxD ---------- RTS ---------- CTS <---------1 ===== 6. PC restart send. PC device RxD ---------- TxD ---------> send RTS ---------- CTS <---------1
Thanks for responding.
I am well aware on how flow control works. I have a device with a micro controller connected to a MAX232, which is connected to a straight through serial cable to the com port on the PC. This setup works with flow control in most terminal programs except Teraterm.
The pictures I uploaded are only to show you that my device is raising and lowering its CTS line. They are the TTL signals present from the micro controller side of the MAX232.
On the micro controller side of the MAX232, CTS = output and RTS = input. I understand that it is the opposite on the PC side (the DB9 connector).
To summarize, my circuit is raising and lowering it's CTS signal (output) to satisfy the terminal where CTS = input. My circuit monitors its RTS input in case the PC wants to halt data flow on it's RTS (output) signal.
I did measure the signals at the DB9 connector (a few months back) to determine that Teraterm was ignoring the CTS signal from my circuit. I do not have the oscilloscope anymore to do the measurement now.
I am attaching a schematic of what my hardware looks like.
If you have such a circuit or dev board, I can send you some test code to run in order to show the problem. You just send a text file to the device and with some delays added to simulate the real device, it will echo the characters back to the terminal. This will show if the flow controls signals are working or not, (data is the same as the input, or lost data).
What the device is doing is accepting a file from the PC. The micro controller requires some time to process the information. If flow control is disabled (or ignored), data is lost. Sometimes the micro controller sends data back to the PC at 57600 baud rate.
In my situation, the PC never needs to negate RTS because the PC is a great deal faster than my micro controller. I am guessing that the reason the (FTDI, CH340G and other USBtoTTL) cables are working is because they have a buffer in the driver whereas the real serial port does not?
I have never been able to compile Teraterm source without numerous errors. If you can point me to the source code that is error free, I will ask a colleague to look at it.
Thank you again.
Test program prepared.
https://osdn.net/projects/ttssh2/storage/tmp/20230308_zmatsuo_ticket_45271/ttcomtester.zip
And movie.
https://ttssh2.osdn.jp/tmp/serial_flow_test.mp4
Please let us know what you find out.
I don't know what you are asking me to achieve with this test file??? Surely if you connect two PC's together it is going to work because there is no delay.
In other words, When my micro controller device receives the data, there is a small delay (around 4 mS, sometimes more and it varies with each byte). This time is needed for the micro controller to do something with the data, (i.e. write an eeprom or something similar.)
If you can somehow implement this delay in the receiving computer after receiving one byte, you can test and find that it actually does not work with the serial port. (not USB to TTL).
The only other way would be for me to send you a board with the micro controller receiving data but if you don't have a real RS232 serial port with DB9 you won't be able to troubleshoot the problem.
Regards,
Our focus is on hard flow control of Tera Term + your PC.
I think that test2 will tell us if hard flow is working in Tera Term + your PC.
Next, test3 and test4 can check communication between device and Tera Term.
When we know the results, Let's go and think next steps.
My apologies, I am not capable of doing your troubleshooting for you. (nor do I have the time to do so). I have spent a great deal of time on this and I cannot spare any more time. I thought the program would have been tested when it was written way back when you had a serial port to test. All of the versions of Teraterm do not work with flow control signals RTS and CTS.
I can show you a log with my logic analyzer, showing the RTS and CTS signals, and how the data from Teraterm does not stop coming when the receiver raises the CTS signal.
If you don't know how to fix your program, don't worry, I will use other terminal programs that are working perfectly with flow control.
Thank you for your efforts.
Hi,
We don't have a micro controller like you are in use. And I have some PCs that have DB9 but I don't have oscilloscope. We can only check PC to PC connection, can't reproduce at hand.
I don't doubt that "not work" in your environment. But we can't confirm what is "not work." Is it stall Tera Term or stop sending a file or finish sending but file content is garbled or else? We hope to see signals between Tera Term and micro controller in your environment with oscilloscope, but you don't have oscilloscope now as you said.
A) I am not a hardware expert, but this is just a thought... If a delay cause this issue as you guess, increasing "Transmit delay" on [Setup]-[Serial port] dialog cause some difference of behaviour?
B) This is a latest snapshot from a branch for this issue. https://ttssh2.osdn.jp/tmp/teraterm-5.0-alpha1-r10633-20230309_224024-maya-snapshot.zip Please try to add SerialAppCTSDSRFlow config in TERATERM.INI, both value = 0 and 1. Is it cause a difference of behaviour?
Thanks,
Yes of course a transmit byte delay or line delay works but that is not fixing the issue with flow control not working.
I have no idea what you mean by this statement: "Please try to add SerialAppCTSDSRFlow config in TERATERM.INI, both value = 0 and 1. Is it cause a difference of behaviour?"
The signals are RTS and CTS not DSR.
If you are using two computers why not just just implement a 5mS byte delay in the receiving version of Teraterm. If you have the source code you should be able to do this. This will clearly show you that flow control signals are being ignored by Teraterm.
some of the data that is sent is:
:10000000299EB7EFE73A761CC0FAEAD7433C62CCA8 :100010003D56D043DDC9BF7E818457815FE754AE32 :10002000F807CB51BAB3671B626BAF184F9BF774DD :100030003711250CFDC8C211586F4DDF166DD33E28 :10004000AB011F0084AF540624B51FE7B199C0E28D :1000500040E0586D08647A5D445BD3BF1DF2A7F1A0 :1000600081EDD8EDBF2F47187FAD5914DCC393BA8B :10007000529135FE3A17A0DA51FF33F8478503C98C :1000800031C52E6C64B830725675E440B197B8BF74 :1000900090C0DCCC3B3F41665CACBBABA693C1DC03 :1000A0006CB058513207C123E9D0041826F9FDF489 :1000B000B3D16C49EF5A270042DFDCA3946EF79B63 :1000C000AE5A584C6ECF833B08EF686AA92EF33BBB :1000D000F2E487F9FC7DDAAD465B91C395F3182510 :1000E0009205BCB3DE1D8810A98EA8CE6C2FCFBDA3 :1000F0000BD7E74F9EE065736C96321F9A5443B757
:00000001FF
with Teraterm every second line is lost: :10000000299EB7EFE73A761CC0FAEAD7433C62CCA8 :10001000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0 :10002000F807CB51BAB3671B626BAF184F9BF774DD :10003000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD0 :10004000AB011F0084AF540624B51FE7B199C0E28D :10005000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB0 :1000600081EDD8EDBF2F47187FAD5914DCC393BA8B :10007000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF90 :1000800031C52E6C64B830725675E440B197B8BF74 :10009000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF70 :1000A0006CB058513207C123E9D0041826F9FDF489 :1000B000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF50 :1000C000AE5A584C6ECF833B08EF686AA92EF33BBB :1000D000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF30 :1000E0009205BCB3DE1D8810A98EA8CE6C2FCFBDA3 :1000F000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF10
:00000001FF
Hyperterminal or other terminals where the flow control is working, there is no data loss. I did some testing today using the logic analyzer and a level converter. This is a direct log of the RS232 signals going into the computer. These is not the TTL signals.
See the file RS232.bmp.
The picture shows that the signals are correct, so the problem is with the software. Using the same setup, I tried hyperterminal and there is no data loss at all.
There is nothing more i can do on my end, I don't have the Teraterm source code (the version I have will not compile, too many errors)
If you have the source code that actually compiles without errors please send me a link. I can have someone look at it for me where we have more equipment/tools to troubleshoot the problem.
I asked before but you did not respond. I will also need to know how you compiled teraterm, i.e. visual studio 201x?
Hi,
Thank you for your information. My apologies for replying only to what I can reply immediately now. We will discuss about your information.
The signals are RTS and CTS not DSR.
About this, we don't confuse it.
See the file RS232.bmp.
Is my reading has mistake?
teraterm-5.0-alpha1-r10633-20230309_224024-maya-snapshot.zip is from a test branch. It supports some parameters for test. SerialAppCTSDSRFlow is one of test parameter.
If teraterm-5.0-alpha1-r10633-20230309_224024-maya-snapshot.zip with following TERATERM.INI:
[Tera Term] SerialAppCTSDSRFlow=0
Tera Term works same as trunk.
In our understanding, fOutxCtsFlow = TRUE is "Windows monitors CTS and control output."
If teraterm-5.0-alpha1-r10633-20230309_224024-maya-snapshot.zip with following TERATERM.INI:
[Tera Term] SerialAppCTSDSRFlow=1
Tera Term stop sending explicitly when CTS is low.
This is a diagram written by zmatsuo, who was add this test parameter.
https://ttssh2.osdn.jp/manual/5/en/reference/develop.html#build
This is a guide to build Tera Term.
Visual Studio 2019 and 2022 is supported now.
To download and build libraries, CMake and Perl is minimum required tools.
Thanks,
In the picture RS232.bmp is the same as Logic.png except that the logic is inverted.
In Logic.png, TxD = device transmit and PC receive.
RxD = device receive and PC transmit.
The logic signals are opposite that of RS232 (they are inverted).
In the picture RS232.bmp, TXD is sent from PC to device, inverted logic. YES
CTS is sent from device to PC, inverted logic. YES
sequence: PC will not transmit byte unless CTS = 1.
If Teraterm (or windows or the driver) inverts the logic then it will be reversed.
PC will not transmit byte unless CTS = 0.
PC must wait until device asserts CTS.
It is obvious that Teraterm is not doing this.
Device checks RTS and will not transmit to PC unless RTS = 0.
At the RS232 level, the signal will be inverted so RTS actually = 1 when the PC is ready to receive.
You should be able to figure it out if you implement a 4 - 5 mS delay (or longer)
between reception of each byte in the receiving computers version of Teraterm.
Of course you will have to modify Teraterm temporarily in order to debug.
(and I am sure you know that you must use a null modem cable with all 9 wires inside the cable).
Regards,
Hi,
Thank you for your explanation.
I want to confirm again about RS232.bmp.
Which do you present us by RS232.bmp?
TXD is sent from PC to decive, negative logic.
CTS is sent from device to PC, positive logic.
CTS is sent from device to PC, inverted logic. YES
I wrote CTS is positive logic. High is 1 and Low is 0. Because I read these articles.
https://tldp.org/HOWTO/Text-Terminal-HOWTO-23.html#ss23.2
Although the receive and transmit pins are inverted logic, other pins (modem control lines) are normal logic with a positive voltage being true (or "on" or "asserted") and a negative voltage being false (or "off" or "negated").
https://en.wikipedia.org/wiki/Flow_control_(data)#Hardware_flow_control
line polarity is TxD-, RxD-, CTS+, RTS+ (clear to send when HI, data 1 is a LO)
I don't know how to read serial analyzer. I added some description that my reading to RS232.bmp. Which is correct, or both are incorrect?
PC must wait until device asserts CTS.
I understand it. But can I watch from RS232.bmp (if it indicates normal behavior) that device suspend to receive with tell CTS=off about some time (a few bits), and PC stop transmit data?
Regards,
If you have such a circuit or dev board, I can send you some test code to run in order to show the problem.
We don't have the device (AT89C51/C52/S52). But we would like to see how it works, so can you show us your test code?
I am thinking of making a test program that works on Windows.
The test program is simple echo program that performs receive hard flow control.
[Tera Term]---(cross cable)---[echo test on Windows]echo test program receives data from Tera Term and sends back the same.
I consider the specification to be as follows
This specification is intended for device behavior.
However, conditions such as enabling and disabling interrupts, FIFOs in the serial chip, and driver and OS buffers are different between device and Windows (*2).
If there is a problem, how do I fix it? Would this specification be a test for hardware flow? Please advise.
Reply To zmatsuo
The terminal will keep RTS low (zero) unless it is busy then it is high (one). The device will check if the RTS line is high (one) before sending a byte to the terminal. Usually this is not a problem because the terminal is a great deal faster than most devices.
The device will keep CTS low (zero) until it is ready for data then it is high (one). The above signals are what the PC sees (the RS232 signals described are not inverted, for clarification purposes only).
Personally I would not echo back the data. Why not just display the data in the receiver computer while it is being received.
If you do not implement a reception byte delay of at least 5 mS then you are wasting your time because connecting two computers together as you described will show no problems whatsoever. The computer is fast enough that the data will not be lost.
This is the whole reason for flow control. When one of the devices cannot keep up with the data flow then flow must come to a stop or data is lost.
In order to fix this problem, you have to simulate a device. The only way if you don't have the hardware is to use a null modem cable as described. On the receiving computer, there must be a sleep or delay function after every byte is received (as to simulate the device). This means that the transmitting computer will not transmit any data until the device sets the CTS signal (one).
***The receiving computer will not accept any data at this time, if any data is sent it will be lost*** Therefore a delay where NOTHING HAPPENS is necessary on the receiving end. Of course this is for troubleshooting purposes only.
If you do not have the capability to do this I can send you some code to program the hardware like the schematic (HD-HS.JPG) I uploaded. Any microcontroller can be used, I can change the code to suit. Please check with me first so I can be sure the code will work in your device. The device must be RS232 with a DB9 connector (not USB).
If you have a RS232 to TTL adapter with CTS and RTS signals then it would be easier to build the circuit.
You may be able to purchase the hardware online somewhere for almost nothing.
The device will display the data it receives in the terminal. If the data is the same on both ends flow control is working.
I don't know what else to tell you except that all terminal programs work perfectly with (RS232) Flow Control except for Teraterm.
As I mentioned previously, Flow Control in Teraterm does work with some(not all) USBtoTTL cables. Maybe you will find the solution there.
Hi,
It's difficult to obtain at89c51/52 development board in our country.
Do you think Arduino can reproduce this issue? I found a serial connection equipment, it seems to connect to Arduino.
https://www.amazon.co.jp/dp/B07BZ91SNX
Thanks,
Reply To nmaya
Hi, It's difficult to obtain at89c51/52 development board in our country. Do you think Arduino can reproduce this issue? I found a serial connection equipment, it seems to connect to Arduino. https://www.amazon.co.jp/dp/B07BZ91SNX Thanks,
Arduino uses USB, some use CH340G and the flow control signals are not connected so it would not be easy. (and besides CH340 does not produce the Flow control problem, only RS232 serial port does)
You will need an MAX232 circuit with a DB9 connector to reproduce the problem.
Could the problem be in the way Teraterm buffers the data? When the device sets CTS (to stop data) maybe the buffered data keeps coming?
I have some simple Visual Basic 6.0 source code that is working with RTS and CTS from a very long time ago. If I upload it, would you be able to find the reason why it works and your program does not?
Regards,
Hi,
You will need an MAX232 circuit with a DB9 connector to reproduce the problem.
I know that Arduino has USB interface. The reason why I ask about Arduino, I assumed connection like this:
+-----------+ +---------+ | IDE-+-(*1)-+ Arduino | | | +----+----+ | PC | | | | +----+------------+ | Tera Term-+-(*2)-+ transceiver (*3)| +-----------+ +-----------------+
*1 connect with USB, only when push sketch to Arduino.
*2 connect with RS232, communicate and reproduce this issue.
*3 serial transceiver I mentioned before. It seems to have MAX2327 (https://www.amazon.co.jp/dp/B07BZ91SNX)
Do you think is this equipment configuration can reproduce the issue?
Could the problem be in the way Teraterm buffers the data? When the device sets CTS (to stop data) maybe the buffered data keeps coming?
We think Tera Term entrust Windows to stop send data when CTS (down to stop data) receive.
https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-dcb
fOutxCtsFlow
If this member is TRUE, the CTS (clear-to-send) signal is monitored for output flow control. If this member is TRUE and CTS is turned off, output is suspended until CTS is sent again.
We wondering that serial port does not stop send even if already data is queued in buffer of OS or driver or chip. If fOutxCtsFlow=TRUE is set, we think app does not have to inspect. "app-WinAPI-driver-chip-DP9" someone in bold part have to do it. We think even if app check CTS manually and stop, but if some data already handed from app to WinAPI, it will be transmitted from DP9.
Does your VB6 app inspects CTS full manually? I hope to see it if it has no license problem.
Thanks,
Reply To nmaya
Hi,
You will need an MAX232 circuit with a DB9 connector to reproduce the problem.
I know that Arduino has USB interface. The reason why I ask about Arduino, I assumed connection like this: {{{ +-----------+ +---------+ | IDE-+-(*1)-+ Arduino | | | +----+----+ | PC | | | | +----+------------+ | Tera Term-+-(*2)-+ transceiver (*3)| +-----------+ +-----------------+ }}} *1 connect with USB, only when push sketch to Arduino. *2 connect with RS232, communicate and reproduce this issue. *3 serial transceiver I mentioned before. It seems to have MAX2327 (https://www.amazon.co.jp/dp/B07BZ91SNX) Do you think is this equipment configuration can reproduce the issue?
Once you plug in to the USB the Arduino will establish a connection and open a com port.
You would have to cut the TxD and RxD tracks on the Arduino going to the CH340G or whatever chip the Arduino uses for USB to TTL. Now you can connect the RS232 to TTL to 6 pins, RxD, TxD, CTS, RTS, GND and VCC. I am confident I can make it work, however the 16 MHz crystal on those Arduinos prevents high speed communication without errors, if you could change the crystal to 14.7456 MHz then it would transmit and receive error free. The amazon link you posted is invalid.
So it is not easy to use an Arduino without some modification. Cutting the tracks would prevent programming the Arduino easily. (It can still be done using the IDE but it would be a little more complicated)
Regards,
Reply To nmaya
Could the problem be in the way Teraterm buffers the data? When the device sets CTS (to stop data) maybe the buffered data keeps coming?
We think Tera Term entrust Windows to stop send data when CTS (down to stop data) receive. https://osdn.net/projects/ttssh2/svn/view/trunk/teraterm/teraterm/commlib.c?view=markup&revision=10617&root=ttssh2#l216 https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-dcb
fOutxCtsFlow
If this member is TRUE, the CTS (clear-to-send) signal is monitored for output flow control. If this member is TRUE and CTS is turned off, output is suspended until CTS is sent again.
We wondering that serial port does not stop send even if already data is queued in buffer of OS or driver or chip. If fOutxCtsFlow=TRUE is set, we think app does not have to inspect. "app-WinAPI-driver-chip-DP9" someone in bold part have to do it. We think even if app check CTS manually and stop, but if some data already handed from app to WinAPI, it will be transmitted from DP9. Does your VB6 app inspects CTS full manually? I hope to see it if it has no license problem. Thanks,
The VB6 app uses MSCOMM control. here is the initialization:
With MSComm1 MSComm1.CommPort = 1 MSComm1.Settings = "115200,N,8,1" MSComm1.Handshaking = comRTS 'set the DTR and RTS flags MSComm1.DTREnable = True MSComm1.RTSEnable = True MSComm1.InputLen = 1 'enable the oncomm event for every received Character MSComm1.RThreshold = 1 'disable the oncomm event for send characters '''MSComm1.SThreshold = 0''' 'open the serial port MSComm1.PortOpen = True End With 'MSComm1
I suspect the reason the VB6 app is working is because there is no OnComm Event (interrupt) for send characters. So before every single character sent, CTS/RTS are checked automatically by the control.
If Teraterm is buffering the transmit data this could be the reason why the data does not stop coming when CTS is high.until the buffer data is empty which can cause data loss.
Probably why Teraterm is working with some USB drivers like CH340 is maybe because the driver handles the buffering better? Some FT232 modules do not work with Flow Control with Teraterm. I can test the program if you disable the interrupt for sending the data.
I am hoping this will help, Regards
I will continue to investigate hard flow.
Thanks you.
I would like to have the source code here for some of my colleagues to look at. I am almost certain they will find the problem.
However as I mentioned before, it is IMPOSSIBLE to build the source the way you instructed in the previous post. Numerous errors, eventually I just give up trying.
Is there a zip or rar file with the error free source code available that will compile in VS2019? If you build the source on your PC can you zip the files and post them?
Thanks
Reply To john_smyth
So it is not easy to use an Arduino without some modification. Cutting the tracks would prevent programming the Arduino easily.
OK. Thank you for your explanation.
Reply To john_smyth
I suspect the reason the VB6 app is working is because there is no OnComm Event (interrupt) for send characters.
So before every single character sent, CTS/RTS are checked automatically by the control.
I posted about teraterm-5.0-alpha1-r10633-20230309_224024-maya-snapshot.zip at here. This test version with configuration SerialAppCTSDSRFlow=1 in TERATERM.INI, Tera Term check CTS before every send. Tera Term doesn't entrust Windows to check CTS and stop send when SerialAppCTSDSRFlow=1. Its behavior looks like your VB6 code's behavior. We haven't been informed of the result of this version from you.
Thanks,
Reply To john_smyth
I would like to have the source code here for some of my colleagues to look at.
You can download source code like this.
svn checkout https://svn.osdn.net/svnroot/ttssh2
However as I mentioned before, it is IMPOSSIBLE to build the source the way you instructed in the previous post.
Numerous errors, eventually I just give up trying.
We believe to possible to build, and we actually build without fatal error.
Please let us see the first few fatal errors.
Thanks,
Reply To nmaya
Reply To john_smyth
I would like to have the source code here for some of my colleagues to look at.
You can download source code like this. {{{ svn checkout https://svn.osdn.net/svnroot/ttssh2 }}}
Yes I know but is there a way to download all of the files including subfolders in one zip file like Github? Thanks
Reply To nmaya
Reply To john_smyth
I suspect the reason the VB6 app is working is because there is no OnComm Event (interrupt) for send characters.
So before every single character sent, CTS/RTS are checked automatically by the control.
I posted about teraterm-5.0-alpha1-r10633-20230309_224024-maya-snapshot.zip at here. This test version with configuration SerialAppCTSDSRFlow=1 in TERATERM.INI, Tera Term check CTS before every send. Tera Term doesn't entrust Windows to check CTS and stop send when SerialAppCTSDSRFlow=1. Its behavior looks like your VB6 code's behavior. We haven't been informed of the result of this version from you. * extract teraterm-5.0-alpha1-r10633-20230309_224024-maya-snapshot.zip * edit TERATERM.INI * add "SerialAppCTSDSRFlow=1" line in [Tera Term] section * run ttermpro.exe and test Thanks
This appears to be working, I will test more tomorrow. I am hoping to use version 4.102.
Thanks
Reply To john_smyth
Reply To nmaya
Reply To john_smyth
I would like to have the source code here for some of my colleagues to look at.
You can download source code like this. {{{ svn checkout https://svn.osdn.net/svnroot/ttssh2 }}}
Yes I know but is there a way to download all of the files including subfolders in one zip file like Github? Thanks
I correct URL in above reply. Only trunk is necessary.
svn checkout https://svn.osdn.net/svnroot/ttssh2/trunk ttssh2-trunk
Do you mean that Subverion is not usable in your environment? OSDN does not seems to provide zip download via source browser. I archived current trunk source code here: https://ttssh2.osdn.jp/tmp/ttssh2-trunk-r10640.zip
Or all means all external library source codes which is used in Tera Term build? If so, it seems to me unrealistic.
Thanks,
Reply To nmaya
Reply To john_smyth
Reply To nmaya
Reply To john_smyth
I would like to have the source code here for some of my colleagues to look at.
You can download source code like this. {{{ svn checkout https://svn.osdn.net/svnroot/ttssh2 }}}
Yes I know but is there a way to download all of the files including subfolders in one zip file like Github? Thanks
I correct URL in above reply. Only trunk is necessary. {{{ svn checkout https://svn.osdn.net/svnroot/ttssh2/trunk ttssh2-trunk }}} Do you mean that Subverion is not usable in your environment? OSDN does not seems to provide zip download via source browser. I archived current trunk source code here: https://ttssh2.osdn.jp/tmp/ttssh2-trunk-r10640.zip Or all means all external library source codes which is used in Tera Term build? If so, it seems to me unrealistic. Thanks,
I need all of the files and subfolders or there are compile errors. Thank you, the zip file is what I needed. I am still trying to compile the source without errors. Is there source for Version 4.102? For me the program is too complicated. I would like to remove everything except for serial communication. Do you think this is possible or is there a release with only serial communication? Thank you
Reply To john_smyth
Reply To nmaya
Reply To john_smyth
I suspect the reason the VB6 app is working is because there is no OnComm Event (interrupt) for send characters.
So before every single character sent, CTS/RTS are checked automatically by the control.
I posted about teraterm-5.0-alpha1-r10633-20230309_224024-maya-snapshot.zip at here. This test version with configuration SerialAppCTSDSRFlow=1 in TERATERM.INI, Tera Term check CTS before every send. Tera Term doesn't entrust Windows to check CTS and stop send when SerialAppCTSDSRFlow=1. Its behavior looks like your VB6 code's behavior. We haven't been informed of the result of this version from you. * extract teraterm-5.0-alpha1-r10633-20230309_224024-maya-snapshot.zip * edit TERATERM.INI * add "SerialAppCTSDSRFlow=1" line in [Tera Term] section * run ttermpro.exe and test Thanks
This appears to be working, I will test more tomorrow. I am hoping to use version 4.102. Thanks
Editing the ini file in version 4.102 also works with flow control. More testing needed.
Thank you
Reply To john_smyth
Reply To john_smyth
Reply To nmaya
Reply To john_smyth
I suspect the reason the VB6 app is working is because there is no OnComm Event (interrupt) for send characters.
So before every single character sent, CTS/RTS are checked automatically by the control.
I posted about teraterm-5.0-alpha1-r10633-20230309_224024-maya-snapshot.zip at here. This test version with configuration SerialAppCTSDSRFlow=1 in TERATERM.INI, Tera Term check CTS before every send. Tera Term doesn't entrust Windows to check CTS and stop send when SerialAppCTSDSRFlow=1. Its behavior looks like your VB6 code's behavior. We haven't been informed of the result of this version from you. * extract teraterm-5.0-alpha1-r10633-20230309_224024-maya-snapshot.zip * edit TERATERM.INI * add "SerialAppCTSDSRFlow=1" line in [Tera Term] section * run ttermpro.exe and test Thanks
This appears to be working, I will test more tomorrow. I am hoping to use version 4.102. Do you have the source in a zip file for version 4.102? Thanks
Editing the ini file in version 4.102 also works with flow control. More testing needed. Thank you
I am testing the version you recommended: teraterm-5.0-r10587-20230207-zmatsuo
After some testing I found Teraterm does not work in Windows 10 with flow control. I tried three computers. I managed to get it to work on windows7 x64 only.
There are two folders created: C:\Users\user\AppData\Local and C:\Users\user\AppData\Roaming\teraterm5
In the second folder, multiple ini files are created. See the TT1.jpg
All of the INI files have the line added: "SerialAppCTSDSRFlow=1".
This seemed to allow Flow Control to work in windows 7 but not in windows 10. I have a dual boot OS on the same PC with W7 & W10. Flow control is working on W7 on this PC but not on W10.
Reply to john_smyth
I am testing the version you recommended: teraterm-5.0-r10587-20230207-zmatsuo
This seemed to allow Flow Control to work in windows 7 but not in windows 10.
Thank you for your testing.
Always teraterm-5.0-r10587-20230207-zmatsuo is enabled SerialAppCTSDSRFlow. teraterm-5.0-alpha1-r10633-20230309_224024-maya-snapshot can configure on/off by TERATERM.ini.
Editing the ini file in version 4.102 also works with flow control.
And also 4.102 does not support SerialAppCTSDSRFlow. Please see tt-revision.png.
In the second folder, multiple ini files are created.
It is a specification of Tera Term 5. Current file is backed up automatically when saved.
Thanks,
And also 4.102 does not support SerialAppCTSDSRFlow. Please see tt-revision.png.
I am wondering why Flow Control works in windows 7 then. It only works if the line is added to the ini file. Regards
Reply to john_smyth
I am still trying to compile the source without errors. Is there source for Version 4.102?
ini file
In Tera Term 4, TERATERM.INI is read from exe dir. If TERATERM.INI presents in My Documents, if is preferentially read.
In Tera Term 5, TERATERM.INI is read from C:\Users\user\AppData\Roaming\teraterm5. To use TERATERM.INI of exe dir, please put "portable.ini" file into exe dir.
Reply to john_smyth
I am wondering why Flow Control works in windows 7 then.
"Windows 7 or Windows 10" seems to one of fault isolation point.
In 4.102 and teraterm-5.0-r10587-20230207-zmatsuo, SerialAppCTSDSRFlow=1 or 0 is not a fault isolation point.
I guess this is full patterns. Did you cover all patterns?
| 4.102 | teraterm-5.0-r10587-20230207-zmatsuo | teraterm-5.0-alpha1-r10633-20230309_224024-maya-snapshot | |
| Win 7 / SerialAppCTSDSRFlow=0 | |||
| Win 7 / SerialAppCTSDSRFlow=1 | |||
| Win 10 / SerialAppCTSDSRFlow=0 | |||
| Win 10 / SerialAppCTSDSRFlow=1 |
If result is followings, the behavior of Windows version (or driver version) differences cause this issue. But SerialAppCTSDSRFlow=1 is to be a workaround in Windows 10.
| 4.102 | teraterm-5.0-r10587-20230207-zmatsuo | teraterm-5.0-alpha1-r10633-20230309_224024-maya-snapshot | |
| Win 7 / SerialAppCTSDSRFlow=0 | OK | OK | OK |
| Win 7 / SerialAppCTSDSRFlow=1 | OK | OK | OK |
| Win 10 / SerialAppCTSDSRFlow=0 | NG | OK | NG |
| Win 10 / SerialAppCTSDSRFlow=1 | NG | OK | OK |
Reply To nmaya
* I put 4.102 source code here https://ttssh2.osdn.jp/tmp/ttssh2-4_102.zip. download it and extract
this link is invalid
Reply To nmaya
Reply to john_smyth
I am wondering why Flow Control works in windows 7 then.
"Windows 7 or Windows 10" seems to one of fault isolation point. In 4.102 and teraterm-5.0-r10587-20230207-zmatsuo, SerialAppCTSDSRFlow=1 or 0 is not a fault isolation point. I guess this is full patterns. Did you cover all patterns? || || 4.102 || teraterm-5.0-r10587-20230207-zmatsuo || teraterm-5.0-alpha1-r10633-20230309_224024-maya-snapshot || || Win 7 / SerialAppCTSDSRFlow=0 || || || || || Win 7 / SerialAppCTSDSRFlow=1 || || || || || Win 10 / SerialAppCTSDSRFlow=0 || || || || || Win 10 / SerialAppCTSDSRFlow=1 || || || || If result is followings, the behavior of Windows version (or driver version) differences cause this issue. But SerialAppCTSDSRFlow=1 is to be a workaround in Windows 10. || || 4.102 || teraterm-5.0-r10587-20230207-zmatsuo || teraterm-5.0-alpha1-r10633-20230309_224024-maya-snapshot || || Win 7 / SerialAppCTSDSRFlow=0 || OK || OK || OK || || Win 7 / SerialAppCTSDSRFlow=1 || OK || OK || OK || || Win 10 / SerialAppCTSDSRFlow=0 || NG || OK || NG || || Win 10 / SerialAppCTSDSRFlow=1 || NG || OK || OK ||
I have NO IDEA what you are saying. I will not try every scenario, I have spent too much time on this already. I don't see the program every working correctly.
As for the source code, WHY all of the UNNECESSARY COMPLICATED steps? I believe that if you say the source is compatible with VS2019 then you should upload a VS2019 SLN and not ask the user to download multiple programs and spend 12 hours troubleshooting when it does not work. If you build it for 2019, then upload it in a zip file for others to fix mistakes in your code. This is what open source is.
I appreciate your efforts but I have accepted that the program will not work with Flow control. I do not have unlimited time for this.
I would appreciate if you could upload a ready to compile with VS2019 source code. Otherwise I cannot continue with this.
Regards,
Hi,
We appreciate for your time and efforts. We also spent times for this issue, and we are groping in the dark. Because we can't reproduce and confirmation without a device.
Did we recommended Tera Term version 4.102 and Visual Studio 2019? No. I wrote "Visual Studio 2019 and 2022 is supported now," it's about trunk (Tera Term 5). Because a test branch 'ttcomtester' and a test binary 'teraterm-5.0-r10587-20230207-zmatsuo.zip' for this issue was created from trunk source code. We don't think that the initialization of COM port is so different between trunk and 4-stable. You chose Tera Term version 4.102, and You chose Visual Studio version 2019.
Visual Studio 2019 was not born yet when Tera Term 4.102 was released. Tera Term 4.102 binary (released from TeraTerm Project) was built by Visual Studio 2005, and its source can also build by Visual Studio 2017 using ttermpro.v15.sln, and ttermpro.v16.sln does not provided. You have probably read "THIS SOFTWARE IS PROVIDED AS IS ..." in LICENSE file. That was so when that time. We don't add support for new compilers for past releases.
We have to find out what cause this issue (in other words, what is different when work or not work). We don't want to modify the source code by guesswork.
Your report Teraterm does not work in Windows 10 with flow control is very helpful. This is a progress in analyze this issue.
But we can't confirm the combination what you tried, and can't confirm that the difference from Win7/10, or difference from SerialAppCTSDSRFlow=0/1.
Some your explanation is partially. You know what you did completely because you did it, but we can't know without explicit explanation. Here is what I guess you did:
1. https://osdn.net/projects/ttssh2/ticket/45271#comment:1412:45271:1675785572 > The serial port is working on all versions, just no flow control so data is lost... 2. https://osdn.net/projects/ttssh2/ticket/45271#comment:1412:45271:1675778781 > > https://ttssh2.osdn.jp/tmp/teraterm-5.0-r10587-20230207-zmatsuo.zip > Same thing, does not work with RTS, CTS flow control. Is it really executed or your predict? In what version Windows? 3. https://osdn.net/projects/ttssh2/ticket/45271#comment:1412:45271:1679366136 > This appears to be working, Is it really executed or your predict? Run r10633? In what version Windows? 4. https://osdn.net/projects/ttssh2/ticket/45271#comment:1412:45271:1679395800 > Editing the ini file in version 4.102 also works with flow control. How about SerialAppCTSDSRFlow=0? I believe that SerialAppCTSDSRFlow configuration is not affect to Tera Term 4.102. But you wrote "'''Editing the ini file''' in version 4.102 also works". Then I have to doubt that how about 4.102 and SerialAppCTSDSRFlow=0 (not editing the ini file). Did you try it? 5. https://osdn.net/projects/ttssh2/ticket/45271#comment:1412:45271:1679570251 > Teraterm does not work in Windows 10 with flow control using teraterm-5.0-r10587-20230207-zmatsuo. using Windows 10 and Windows 7 on same machine. No hardware difference. Is Tera Term 4.102 works flow control with Windows 7? And not works flow control with Windows 10?
summary:
I will change question. What scenario did you test, and not tested?
If the difference is only Windows 7 or Windows 10, it seems to Microsoft changed something that is cause this issue. We cannot change Windows internal behavior.
What do you means "UNNECESSARY COMPLICATED steps"? Is it "download source code of libraries" or "build libraries myself" or "convert to Visual studio 2019 project"?
About download source code of libraries:
About build libraries myself:
About convert to Visual studio 2019 project:
If you need our support for build Tera Term, please copy and paste error messages from compiler. Please tell "what is happen", not "not going as expected." We can't help only your message "IMPOSSIBLE" or "numerous errors."
This is what open source is.
Is this your "open source"? ‘I want to build particular version of Tera Term. Hey project team, checkout source code of the version, download and extract all external library source code what is used in that Tera Term version. Yes, I want to use particular version of Visual Studio. Build all external libraries with that version Visual Studio to create library objects. If sln/vcxproj file for that version Visual Studio is not provided, create it. Do all that things for me, and send to me. When I receive it, I can build Tera Term with only open teraterm.sln and click 'build' from menu.’ It is convenient for users. Even if I do that for you, I can't do so to ALL users who request like that. And I guess that other open source project do not respond to requests like that.
I think that "open source" is "it is distributed with source code under an open source license." User can use, confirm, modify and publish it. I think it is not "I can build it as easily as like double-clicking".
not ask the user to download multiple programs and spend 12 hours troubleshooting when it does not work.
Did I ask compile Tera Term to you? If you try to compile Tera Term and run with a device, probably it contribute to analyze this issue. If some change of Tera Term solve this issue and you send a patch to this project, it's very very welcome. But the topic about compiling Tera Term started from you.
Thanks,
Please forgive me, but when something is unnecessarily complicated, my patience is lost very quickly. Other terminal programs are working with flow control, so for me spending a great deal of time on this is frustrating if there is no solution after a very long time. I don't know why Flow Control was never tested with Teraterm in the early releases because it clearly never worked even in Version 2.3 when there were RS232 com ports in every computer.
I am not interested in using any version of Teraterm after verion 4.102. The flow control does not work with USBtoTTL adapters after V4.102 in addition to the RS232 port flow control not working. And besides having to check the box "send file like Teraterm 4" is just annoying. There are other reasons why I don't like Teraterm after V4.102.
Please answer my question:
Is there ANY VERSION of Teraterm that includes a ready to compile sln file with ANY version of visual studio?
I don't want to have to download multiple libraries and try to configure the paths or I will just give up immediately. Therefore, a zip file containing all of the files in the correct paths and subfolders is needed.
I am confident my colleagues will figure it out as long as I give them source code that will compile in visual studio. I tried to give them the source that you posted and they refused to work with it.
I am willing to use ANY older versions of visual studio if needed.
Also I only want to use the serial port with teraterm so the oldest version of source code is preferred. I am not interested in ANY of the other features. Sending files (with a working progress bar) is all that is required. V2.3 is the most basic version however the progress bar is missing.
After some more testing I found the reason why it worked in windows 7 and not in windows 10.
Editing the line "SerialAppCTSDSRFlow=1" does nothing in Teraterm V4.102.
If you look at the picture I uploaded called "WorkingPortSettings.JPG", this shows how I got Flow control to work in Teraterm using windowsXP, windows7 and windows10.
I tried this before, but the change does not take effect unless the computer is restarted after the setting is changed. In windows 10 the change was not accepted unless the computer was shut down completely (as if you would be entering the bios settings), then when windows 10 was restarted, the change took effect and flow control worked.
I forgot that I changed the com port properties in windows7, and since it didn't work based on the changed settings (until the computer was restarted) I figured that was not the reason why it ONLY worked in windows 7.
Again, Teraterm V4.102 flow control works with *SOME* USBtoTTL adapters without having to change this setting. Newer versions of Teraterm are too troublesome with USB2TTL adapters so I would rather stick with what (almost) works. The setting in the picture only permits flow control to work in Teraterm using a real RS232 port.
I think if Teraterm does not buffer the outgoing (transmitted) data then flow control will work.
Changing the settings (as in the picture) is not the solution and Teraterm should be changed to allow Flow Control to work properly.
Regards,
Hi,
Is there ANY VERSION of Teraterm that includes a ready to compile sln file with ANY version of visual studio?
I guess your environment already has Visual Studio 2019.
I did followings:
svn checkout https://svn.osdn.net/svnroot/ttssh2/trunk trunk-r10645 curl -L https://github.com/kkos/oniguruma/archive/refs/tags/v6.9.8.tar.gz > onig-6.9.8.tar.gz curl http://www.math.sci.hiroshima-u.ac.jp/m-mat/MT/SFMT/SFMT-src-1.5.1.tar.gz > SFMT-src-1.5.1.tar.gz tar zxvf onig-6.9.8.tar.gz -C trunk-r10645/libs/oniguruma --strip-components 1 tar zxvf SFMT-src-1.5.1.tar.gz -C trunk-r10645/libs/SFMT --strip-components 1 echo #undef SVNVERSION> trunk-r10645/teraterm/common/svnversion.h echo #undef TERATERM_RELEASE>> trunk-r10645/teraterm/common/svnversion.h echo #define BRANCH_NAME "">> trunk-r10645/teraterm/common/svnversion.h pushd trunk-r10645\libs buildoniguruma6.bat buildSFMT.bat popd rm -rf trunk-r10645/.svn zip -r trunk-r10645 trunk-r10645
https://ttssh2.osdn.jp/tmp/trunk-r10645.zip contains:
You have to do followings:
1. download https://ttssh2.osdn.jp/tmp/trunk-r10645.zip and uznip it. 2. build Tera Term open uznipped folder with Explorer, and double-click teraterm\ttermpro.v16.sln "Build"-"Build Solution" from Visual Studio menu 3. run Tera Term "Debug"-"Start Debug" from Visual Studio menu
Thanks,
thank you for doing that. it compiles with no errors (lots or warnings but that is ok) Regards
Tera Term
Hardware flow control in Teraterm setup does not work using CTS and RTS. I am using an RS232 real serial port (not a USB to RS232 cable or USB to TTL cable).
I have tested this Hyperterminal and it is working. Something is wrong with Teraterm. Data is lost when using Teraterm most likely because it ignores the CTS/RTS signals.
I am using TeraTerm Version 4.106.