C# - Serial Handshaking Problem

[trentrockport]

I have rewritten a faulty serial app that my company uses at several sites. In most cases, it works fine. At one site, it does not work. I know for certain the following:

Port=COM1, Rate=9600bps, Framing=8+N+1, and Control Flow is either none or XON/XOFF.

I am using a .NET SerialPort object to manage the port. To open the port, I do the following:

serialPort.PortName = port;
serialPort.BaudRate = transmissionRate;
serialPort.DataBits = framingDataBits;
serialPort.Parity = framingParity;
serialPort.StopBits = framingStopBits;
serialPort.Handshake = handshake;

serialPort.Open();

At this one site, the old program opens the port correctly. It uses the following statement:

phandle = CreateFile(port, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, NULL);

However, with my program, the host on the other end complains that there is nothing on the other end to talk to. If I run PuTTY and connect to the same port as my program would, using 9600, 8+N+1, XON/XOFF, the host stops complaining.

Any ideas?

TIA,
Bob

[Plater]

With XON/XOFF you might need to send XON at the start to let the other program know you are up and running.
You are sure it doesn't try to use hardware flow control?

[trentrockport]

...you might need to send XON at the start

Although on the surface that doesn't make sense to me, it's exactly what I was thinking. I'm going to try that next.

You are sure it doesn't try to use hardware flow control?

Just considering the hardware, that would seem to make sense, however I dismissed that when I was able to get the device to... "come to life" when I connected to it via PuTTY using only XON/XOFF.

[Plater]

Although on the surface that doesn't make sense to me, it's exactly what I was thinking. I'm going to try that next.

Well if you think of it like the device got an XOFF from something and is sitting there waiting for an XON before it will talk, simply connecting to it won't do it.

I might actually suggest that your program send an XOFF as the very first thing, then send an XON when you are ready for data. Although I suppose it depends on who is considered the "master" for that to work.

[trentrockport]

...send an XOFF as the very first thing, then send an XON

Exactly what I was thinking. Adding to the fun, the agency in question is halfway across the country. My contact will be in tomorrow morning, I'll try it then and post my results. Thanks again!

[trentrockport]

Starting with XON did not work, nor did XOFF then XON.

The intriguing part is that If I PuTTY to COM1, which is where the external device is connecting, said external device sees PuTTY connecting and is happy. Similarly, if the old application connects to COM1, the external device is once again, happy. It's my program that uses the Microsoft SerialPort object's Open() method that is somehow failing to put the port into an appropriate state. I'll be online with the client again today. I'm adding the two lines at the bottom of this snippet:

serialPort.Open();
if ( handshake == Handshake.XOnXOff )
{
Reply( DC3 );
Reply( DC1 );
}

serialPort.DtrEnable = true;
serialPort.RtsEnable = true;

[trentrockport]

Adding the lines:

serialPort.DtrEnable = true;
serialPort.RtsEnable = true;

resolved the issue for the installation in question.

[Plater]

Adding the lines:

serialPort.DtrEnable = true;
serialPort.RtsEnable = true;

resolved the issue for the installation in question.

That is hardware flow control. Very strange.