We Keep Coding

How to hide some return data from RS232 Serial Port

I am using C# Console app to interact with firmware on sas Expander card.
It was connected by RS232 Serial Port.
Here is the code:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.IO.Ports;
using System.Threading;
namespace SerialPortExample
{
class SerialPortProgram
{
// Create the serial port with basic settings
[STAThread]
static void Main()
{
SerialPort mySerialPort = new SerialPort("COM5");
mySerialPort.BaudRate = 115200;
mySerialPort.Parity = Parity.None;
mySerialPort.StopBits = StopBits.One;
mySerialPort.DataBits = 8;
mySerialPort.Handshake = Handshake.None;
mySerialPort.RtsEnable = true;
mySerialPort.DtrEnable = true;
mySerialPort.ReadTimeout = 2000;
mySerialPort.WriteTimeout = 1000;
mySerialPort.Open();
if(mySerialPort.IsOpen)
{
mySerialPort.Write("\r");
}
mySerialPort.DataReceived += new SerialDataReceivedEventHandler(DataReceivedHandler);
while (true)
{
string userResponse = Console.ReadLine();
if (userResponse == "sys")
{
mySerialPort.Write("sys\r");
}
else if (userResponse == "counters")
{
mySerialPort.Write("counters\r");
}
else if (userResponse == "phyinfo")
{
mySerialPort.Write("phyinfo\r");
}
else if (userResponse == "? -a")
{
mySerialPort.Write("? -a\r");
}
else
{
mySerialPort.Write("\r");
}
}
}
private static void DataReceivedHandler(object sender, SerialDataReceivedEventArgs e)
{
SerialPort sp = (SerialPort)sender;
string indata = sp.ReadExisting();
Console.Write(indata);
}
}
}
What the app execute command counters result:
Using PuTTy by sending command counters result:
You can see counters will show up on the app page
and counters won't show up in PuTTY's page.
What should I do to let my code result just like PuTTY does?
How to hide some return data from Serial Port?
My C# Console app is using .Net Framwork 4.7.2.
.....................................................
Update:
After I add mySerialPort.ReadChar(); in code,
the code looks like:
string userResponse = Console.ReadLine();
if (userResponse == "sys")
{
mySerialPort.Write("sys\r");
mySerialPort.ReadChar();
mySerialPort.ReadChar();
mySerialPort.ReadChar();
}
and the result is:
I am not satisfied with this result
because there are at least twenty command in firmware.
I don't want keep adding mySerialPort.ReadChar() in every condition.
Is there another way to fullfill my goal？
.......................................................
Update Part2:
After adding string echocancel = sp.ReadLine(); in DataReceivedHandler,
the code looks like:
private static void DataReceivedHandler(object sender, SerialDataReceivedEventArgs e)
{
SerialPort sp = (SerialPort)sender;
string echocancel = sp.ReadLine();
string indata = sp.ReadExisting();
Console.Write(indata);
}
and the result looks like:
After product identity :'s word should have default
and between product Identity and <<Alarm status>>
should have space, it should show up.
At least, sys , this three character won't show up again.
Did someone has some solution about it?

Seems like a situation of double echo of keyboard input.
By default the typical terminal emulation program (e.g. minicom) disables local echo for keyboard input; apparent putty does the same.
So when the attached device does echo the typed input, you only see one copy of the input displayed.
(Because of this default mode, you will not see what you type when the attached device also has its echo inhibited.)
With your program, characters typed as input on keyboard are echoed locally to your display, and when transmitted that line is echoed by the attached device and then displayed (by your program) as part of the response.
You can verify this hypothesis by changing your code to accept a foo command instead of counters:
...
else if (userResponse == "foo")
{
mySerialPort.Write("counters\r");
}
...
The expected display should then be something like
bp1 >foo
counters
...
Possible solutions are:
a. disable echo from the device (preferred), or
b. disable local echo, or
c. echo cancellation.
Echo cancellation can be simplified in your program because each command transmitted seems to be a line terminated by a carriage return. So instead of absorbing individual characters as you did for an individual command, you only need a single read of a line to absorb the echoed line:
while (true)
{
string userResponse = Console.ReadLine();
if (userResponse == "sys")
...
else
{
mySerialPort.Write("\r");
}
/*
* might need a delay here allow serial output to drain/complete
* and give device time to respond
*/
string echocancel = mySerialPort.Readline();
}
However such echo cancellation would also require proper setting of the line-terminator character, i.e. mySerialPort.NewLine = "\r";
See
https://learn.microsoft.com/en-us/dotnet/api/system.io.ports.serialport.newline?redirectedfrom=MSDN&view=dotnet-plat-ext-5.0#System_IO_Ports_SerialPort_NewLine
Note that disabling echo from the device is the standard mode for (serial) communication with a device by software (i.e. machine to machine). This simply reduces the amount of data transferred. Echo is only enabled for the convenience of humans.
What is the local echo in my code? Console.ReadLine()?
For Linux, minicom disables local echo by configuring termios flags for stdin (aka the keyboard).
Seems like you're using Windows, so I don't know the equivalent operation.
Yes, the local echo should be occurring during the Console.ReadLine().
Addendum in response to Update Part2
My suggestion for echo cancellation guarantees that only one line of input would be discarded per command sent.
Your modification differs from my suggestion in order to keep all serial port reads within a single procedure/handler.
However that could introduce a synchronization issue, because now you have to ensure that DataReceivedHandler() is performed only once per iteration of the while loop that receives userResponse.
But there seems to be absolutely nothing in that while loop that could enforce any synchronization with DataReceivedHandler().
Prior to this echo cancellation modification, your program really didn't have to rely on any synchronization. Since DataReceivedHandler() simply displayed whatever it received, this data transfer seems flawless, and you weren't concerned about how indata aligned with the text of the response.
To test this synchronization hypothesis, report the line(s) that is/are being discarded for echo cancellation, e.g.
private static void DataReceivedHandler(object sender, SerialDataReceivedEventArgs e)
{
SerialPort sp = (SerialPort)sender;
string echocancel = sp.ReadLine();
Console.WriteLine($"DEBUG: {echocancel}");
string indata = sp.ReadExisting();
Console.Write(indata);
}
In practice echo cancellation is probably the method of last choice in comparison to simply avoiding the generation of the echo. Some schemes validate the received data prior to discarding (e.g. using a FIFO of expected echo data) to ensure the cancellation is accurate.

SerialPort.Close() freezes application if the USB COM Port in use has been removed

I faced my application freeze, when closing .NET C# SerialPort after the current COM Port connected to, has been removed.
Doing a SerialPort.Dispose() freezes also.
I read this blog which gave some explainations (to take with caution) on the possible issue :
https://www.sparxeng.com/blog/software/must-use-net-system-io-ports-serialport
Could you help me solving this issue ?

I found a workaround but not sure it's a good way to solve the issue.
I'm using the
dmitrynogin / PnP excellent library to handle serial COM Port add/remove events.
private SerialPort _serialPort;
...
private void Main()
{
...
Open(); // Open COM Port
... // Do Stuff
}
...
// COM Port removed event
private void PortCOMRemoved()
{
...
Close(true);
...
}
...
private void Close(bool currentCOMPortRemoved = false)
{
...
if (currentCOMPortRemoved)
{
_serialPort.DtrEnable = false;
_serialPort.RtsEnable = false;
_serialPort.DiscardInBuffer();
_serialPort.DiscardOutBuffer();
// Do not close the COM Port, otherwise, it will freeze
// This is a Bug in SerialPort class management Framework
// On next connexion, it will create a new SerialPort instance
// Application can close itself
}
else
{
_serialPort.Close();
}
...
}
...
private bool Open()
{
bool success = false;
Close();
try
{
_serialPort = new SerialPort();
_serialPort.ErrorReceived += HandleErrorReceived;
_serialPort.PortName = _portName;
_serialPort.BaudRate = _baudRate;
_serialPort.StopBits = _stopBits;
_serialPort.Parity = _parity;
_serialPort.DataBits = (int)_dataBits;
_serialPort.ReadTimeout = 1000;
// We are not using serialPort.DataReceived event for receiving data since this is not working under Linux/Mono.
// We use the readerTask instead (see below).
_serialPort.Open();
success = true;
}
catch (Exception e)
{
Close();
}
return success;
}
When trying to Close() properly the SerialPort the application freeze.
So why not closing it if the current COM Port has been removed ?
Later when the COM Port will be plugged again, a call to Open() will create a new instance of SerialPort then forget the previous SerialPort instance that was not Closed properly. Then the application don't freeze and can be closed normaly.
I tryed it and it's working as a Workaround hoping someone will find a better solution.
Another way could be to bypass the native .Net SerialPort class by SerialPortStream :
jcurl / SerialPortStream
an independent implementation of System.IO.Ports.SerialPort and SerialStream for better reliability and maintainability.
Best regards

sniff serial port - .net

I have this Arduino code just for testing purpose:
int num=0;
void setup() {
Serial.begin(9600);
}
void loop() {
Serial.println(num);
num+=1;
delay(800);
}
Now it prints an integer and increments its value by one. When I open up Serial Monitor it prints as expected every 800ms.
My Arduino is connected on PORT-6
Now if I try to access the port, it says it is in use, I'm trying to access that from a .NET application. How can I do so?
c# code, collected from the internet, modified a little:
using System;
using System.IO.Ports;
using System.Threading;
namespace ConsoleApp1
{
class Program
{
static SerialPort _serialPort;
public static void Main()
{
_serialPort = new SerialPort();
_serialPort.PortName = "COM6";//Set your board COM
_serialPort.BaudRate = 9600;
_serialPort.Open();
while (true)
{
string a = _serialPort.ReadExisting();
Console.WriteLine(a);
}
}
}
}
How can I sniff data from that serial port ? [Educational Purpose]

You can't open a serial port twice.
If what you want is to get to see what is going through the bus (sniffing), you can use virtual ports and port forwarding, see here for a complete example.
Nothing will stop you from replacing any of the tools discussed in the link with your own code (.NET or other), in case they don't suit your needs or if you have enough determination to reinvent the wheel.

Serial port sometimes takes (exactly) 30 seconds to Open or Close, only connects once without manual RTS control

I'm having a very peculiar issue with the serial port class in C# (using .NET 4.5 as a target). Our application needs the ability to switch between (close then open another) serial COM ports which are all USB 1.1 virtual COM port devices. The problem I'm having has two symptoms that may be related. First, we can only connect to our device after having already read from it using another terminal emulator or similar application and even then only once. After one successful connection all other attempts after closing and re-opening the port will never receive data (DataReceivedEvent never fires). The only workaround I have found to this is to manually drive the RTS signal as shown below (even though every other serial library or emulation program requires no handshaking to talk to this device, including TerraTerm, Java, and PySerial).
Second, even then, while the port may be freely opened and closed successful, occasionally (1/30 ish) the Open() or Close() functions take precisely 30 seconds to finish (30008 ms measured via a diagnostic Stopwatch) where it would normally take a mere 5-8 ms. There seems to be no explanation for this. Any thoughts?
Measures already used to try eliminating or mitigating the problem:
Attempts to Open or Close the port are executed as separate tasks in the thread pool so that they can be terminated or aborted cleanly after a specified period of time if unsuccessful (I use 60 seconds for this value in testing)
I've added various time delays both short (100 ms) and extreme (5000 ms) in every conceivable place with no effect (between port close and reopen, between open and close, and between open/close and RTS true/false
Double triple and quadruple checked the designed port parameters for our USB serial device
I've looked at this article by bvoigt and this article by Zach Saw which both seem to suggest that there are deeply rooted issues with .NET SerialPort class. This has left me with the impression that a third party library might be the best option (there are some good candidates on NuGet). Ultimately this will be used as the serial port within a WPF application.
Before anyone asks, no, simply opening the port and leaving it open is not an option in our application and, frankly, this is something that works seamlessly 100% of the time with the same device from the same hosts with the same driver in other languages' standard serial implementations (see above).
Please see the simple exemplary application below which I have been using to successfully reproduce this problem. Any pointers in the right direction are greatly appreciated!!!
SerialTestApplication.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.IO.Ports;
using System.Diagnostics;
using System.Threading;
namespace SerialTestApplication
{
class Program
{
private SerialPort S = new SerialPort();
private bool S_active = false;
private int succeed = 0;
private int fail = 0;
static void Main(string[] args)
{
Program P = new Program();
System.Threading.Thread.Sleep(1000);
var test_timer = new Stopwatch();
test_timer.Start();
for (int a = 0; a < 100; a++)
{
P.ConnectSerial(P);
P.CloseSerial(P);
}
Console.WriteLine("EXIT");
System.Threading.Thread.Sleep(1000);
Console.ReadLine();
}
private bool ConnectSerial(Program P)
{
if (S.IsOpen)
{
fail++;
Console.WriteLine("PORT NOT CLOSED YET");
return false;
}
// Setup The Serial COMM Port
S.PortName = "COM1";
S.BaudRate = 115200;
S.Handshake = System.IO.Ports.Handshake.None;
S.Parity = Parity.None;
S.DataBits = 8;
S.StopBits = StopBits.One;
// Write Properties
S.WriteBufferSize = 2048;
S.WriteTimeout = 500;
// Read Properties
S.ReceivedBytesThreshold = 1;
S.ReadBufferSize = 2048;
S.ReadTimeout = 500;
try
{
S_active = false;
if (!P.OpenSerial(P))
{
fail++;
return false;
}
var connection_timer = new Stopwatch();
connection_timer.Start();
while (S.IsOpen && !S_active)
{
if (connection_timer.ElapsedMilliseconds > 1000)
{
fail++;
CloseSerial(this);
Console.WriteLine("Succeed/Fail: " + succeed + " " + fail);
return false;
}
}
succeed++;
Console.WriteLine("Succeed/Fail: " + succeed + " " + fail);
Console.WriteLine(S.BytesToWrite + " " + S.BytesToRead);
return true;
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
return false;
}
}
private void Receive(object sender, System.IO.Ports.SerialDataReceivedEventArgs e)
{
if (S.IsOpen)
{
S_active = true;
S.ReadExisting();
}
}
private bool OpenSerial(Program P)
{
Task OpenAttempt = Task.Factory.StartNew(() =>
{
try
{
if (S.IsOpen)
{
Console.WriteLine("PORT STILL OPEN!");
return;
}
S.Open();
S.DiscardInBuffer();
S.DataReceived += new System.IO.Ports.SerialDataReceivedEventHandler(Receive);
S.RtsEnable = true;
}
catch (Exception ex)
{
System.Diagnostics.Debug.WriteLine(ex.ToString());
}
});
var open_timer = new Stopwatch();
open_timer.Start();
OpenAttempt.Wait(60000);
Console.WriteLine("Opened In: " + open_timer.ElapsedMilliseconds);
return S.IsOpen;
}
private void CloseSerial(Program P)
{
Task CloseAttempt = Task.Factory.StartNew(() =>
{
try
{
S.RtsEnable = false;
S.Close();
}
catch (Exception ex)
{
System.Diagnostics.Debug.WriteLine(ex.Message);
}
});
var close_timer = new Stopwatch();
close_timer.Start();
CloseAttempt.Wait(60000);
Console.WriteLine("Closed In: " + close_timer.ElapsedMilliseconds);
}
}
}
EDIT 1
I've found one issue with this but unfortunately it doesn't solve the core "takes 30 seconds to finish the Open() or Close() method" problem. The way I am recycling (closing and reopening) the SerialPort object in this test application adds a new DataReceived event handler every time the port is reopened. Basically after closing/opening the port 10 times there will be ten DataReceived handlers associated with the object. To correct that I'm now letting Close() Dispose() the SerialPort object then setting the reference to null and creating a completely new instance of SerialPort on the next open. That seems to ensure that the serial port is properly released so long as the USB cable is not physically pulled out of the computer.

How can I simulate SerialPort interactions for testing?

I'm about to start developing a small app (C#) that communicates with a PLC and a testing unit via Serial Ports - this is my first venture into this area.
In essence, I am going to send the PLC a signal to start an operation, and then I am going to wait for the result of that operation from the test unit (which will be independently communicating with the PLC) to return a ASCII string.
Depending on the content of that string, I may want to listen to a signal from the PLC...
It's all new to me, so at the moment, I'm just researching System.IO.Ports.SerialPort; digression: are there third part products out there than simplify interaction with the Serial Port, or are the built-in classes as good as you will get? I'm thinking of ease of use as opposed to better features.
However, it will be a few weeks before the hardware is available for development and testing, so I was wondering how I could simulate communication to/from the serial port so that I can start developing my app?
[I don't yet know how the PLC and the PC are due to communicate - I understand it will be binary rather than text, but at the moment, that is all I know.]

Abstract away your serial port comms behind an interface so that you can code your app against the interface and then test with a 'fake' implementation. When you've got the hardware for the real thing, you can code up the 'real' implementation of the interface and swap out the fake one.
So for example, you'd have an interface
public interface ISerialComms
{
void SendMessage(string message)
}
and you'd code your app against that interface using a fake implementation:
public class FakeSerialComms : ISerialComms
{
public void SendMessage(string message)
{
//some implementation
}
}
Hope that helps!

I've had some success in the past using com0com.

There are two pieces of software that I have found invaluable while doing serial port work.
Free Serial Port Monitor
http://www.serial-port-monitor.com
Despite the cheesy name, it is actually quite useful. Note that you should have it stop listening to your port if you go to unplug a USB-to-Serial converter. Otherwise it can crash (well... wait indefinitely on exit, which is annoying). It doesn't have to put itself in the middle of a serial connection to sniff data. It monitors the IO using the Win32 API.
Franson Serial Port Tools
http://franson.com/serialtools/
Or.. any loopback software really. There are lots out there. This allows you to send data and receive it within software. If you end up doing any GPS work, Franson also has a nice GPS simulator so you don't have to sit outside the whole time to debug code.
Finally, if you have had enough with the built-in serial class and its horrendous shortcomings, then you need a replacement, and going straight to the Win32 API will take forever.
CommStudio
I have found CommStudio to be absolutely rock solid. Quite frankly, after spending 5 months researching and buying other options, it is the only one that works perfectly with removable USB adapters. All of the other solutions have issues when the device is plugged back in. You can download their free "Express" version here: http://www.componentsource.com/products/commstudio/downloads.html?rv=42917

I have wrote an article on this topic using Virtual Serial Port Driver 9.0 standard using Microsoft SerialPort Class (Sytem.IO.Ports), it is of course possible to use any other comm port tool.
In the software I create 2 virtual ports COM1 and COM2.
I use COM1 to emulate as data sender.
I use COM2 to receive what ever being send from COM1.
This is helpful if you are developing Embedded or IoT solution.
Emulator (in this example as random accelerometer)
private static bool _continue;
private static SerialPort _serialPort;
public static void Main()
{
var stringComparer = StringComparer.OrdinalIgnoreCase;
var readThread = new Thread(Read);
_serialPort = new SerialPort
{
PortName = "COM1",
ReadTimeout = 500,
WriteTimeout = 500
};
_serialPort.Open();
_continue = true;
readThread.Start();
while (_continue)
{
var x = ValueGenerator();
var y = ValueGenerator();
var z = ValueGenerator();
var message = $"x:{x};y:{y};z:{z}";
if (stringComparer.Equals("quit", message))
{
_continue = false;
}
else
{
_serialPort.WriteLine(message);
Thread.Sleep(200);
}
}
readThread.Join();
_serialPort.Close();
}
public static double ValueGenerator()
{
const int range = 1;
var random = new Random();
return random.NextDouble() * range;
}
public static void Read()
{
while (_continue)
{
try
{
var message = _serialPort.ReadLine();
Console.WriteLine(message);
}
catch (TimeoutException) { }
}
}
And my data receiver is almost similar
private static bool _continue;
private static SerialPort _serialPort;
public static void Main()
{
var stringComparer = StringComparer.OrdinalIgnoreCase;
var readThread = new Thread(Read);
_serialPort = new SerialPort
{
PortName = "COM2",
ReadTimeout = 500,
WriteTimeout = 500
};
_serialPort.Open();
_continue = true;
readThread.Start();
while (_continue)
{
var message = Console.ReadLine();
if (stringComparer.Equals("quit", message))
{
_continue = false;
}
else
{
_serialPort.WriteLine(message);
}
}
readThread.Join();
_serialPort.Close();
}
public static void Read()
{
while (_continue)
{
try
{
var message = _serialPort.ReadLine();
Console.WriteLine(message);
}
catch (TimeoutException) { }
}
}
Disclaimer: the link of this guideline refer to my personal web site.

I like David's answer above but if your looking to do integration tests and actually test your serial port communication I have used and application called ViN soft virtual serial cable in the past to basically create 2 serial ports on your machine that are connected by a virtual cable.
Also if you have a serial port on your development machine you could use it to connect to another machine that has a serial port and write an application that will basically simulate the communication of the PLC.
I would prefer to use a combination of both David's method and this method to ensure proper testing.

There is another resource out there that emulates serial ports for windows if anyone else is still looking for decent serial debugging tools.
The 32-bit version is free and seems pretty decent. It's called Virtual Serial Ports Emulator.

Very old but still might be useful to some. Instead of relying on COM interaction, just use the SerialPort.BaseStream to communicate with the port. This allows you to simply use a standard stream interface for communication, in other words, doesn't matter if you use serial ports, TCP connections, or even file streams. Perfect for simulation.