0 votes
by (180 points)

Good Morning,
1. I am using Rebex Terminal Control
2. The connection with the device is via the Serial Port converter FTDI
2. During correct operation and data transfer from the device to the computer, I disconnect the FTDI converter from the USB and the termnal disconnects which is a good sign of operation.
3. After reconnecting the converter to USB and clicking connect in the terminal, unfortunately, there is no data on the template screen. I have to reset the entire terminal to get everything back to normal.
4. I checked that data was coming in and being passed to the control correctly.
5. At the beginning, after reconnecting the converter, there are several bytes of data that may affect the terminal control hangs.
6. Is there any solution to improve serial port communication?

Thank you very much

1 Answer

0 votes
by (69.1k points)

When you get the Disconnected event, the TerminalControl is unbound from the underlying channel. If you want to reconnect, you have to bind the terminal again, like this:

var serialPort = new SerialPortChannel("COM1");

This will create new serial port channel and start processing data.

Can you please add communication logging to the serial port channel and send us the log to support@rebex.net for analysis? Also please log the Disconnected event. Use the logger for all SerialPortChannel instances.
It can be done like this:

var logger = new Rebex.FileLogWriter(@"c:\data\terminal.log", Rebex.LogLevel.Verbose);

var serialPort = new SerialPortChannel("COM1");
serialPort.LogWriter = logger;

terminal.Disconnected += (s, e) =>
    logger.Write(LogLevel.Info, null, 0, "INFO", "Terminal Disconnected.");

by (180 points)
Thanks I found the problem.
When encoding of terminal is set to ISO-8859-1 and we send characters 0xB59D
there is no more data on display.
When I changed it to UTF-8 everything works fine.
Thanks for help
by (69.1k points)
Thank you for letting us know. I will try to reproduce the issue and see if it is a bug on our side.
by (69.1k points)
I have analyzed the issue and I have come to this conclusion:

When using ISO-8859-1 encoding the meaning of the 0xB59D byte sequence is following:

  0xB5 = Micro sign
  0x9D = OSC (Operating System Command) sequences

So, after receiving byte 0x9D the terminal is in state of processing OSC and all the received data is considered to be the OSC arguments. Therefore the data is not written to the terminal screen. The terminal is waiting for the OSC ending character, which is 0x9C (String Terminator) or 0x07 (Bell).

Alternatively, any escape sequence will also end the OSC processing. Sending for example ESC+ENTER will recover from "hanging" the terminal.