SerialPort class bizarre behaviour

[UncleRonin]

I've worked with the .NET 2.0 SerialPort class a whole bunch of times and in general it's okay but I've noticed some very strange behaviour.

First up is not really a problem, it's just a matter of sorting out Encoding I think? I've never actually made the effort to find out the source of the issue since there's never been any time and alternate method is 4 lines of code away but maybe someone here knows the solution? Most of the comms I do relies on exact byte values so everything must be very specific. But when writing a string from the serial port using .Write() the byte values change. Not for all characters in the string mind you, but most. Say the first byte has a decimal value of 02 the it somehow gets converted to a decimal value of 243! You can see why this is a problem!! The obvious way around this is the old fashioned method of using a byte array and then looping through it and writing it out byte for byte so that's what I normally do.

The second issue I've noticed is phantom input. My latest application communicates to a MIP via a serial port. If there is no power to the MIP there is no communication. However, I've noticed that even if there is no power garbage data is still received. I do simultaneous communication both ways so I get the feeling there is some sort of weird loopback. The only thing is the received data is a total mess and utter garbage and nothing like the sent data. If the power is on everything behaves correctly and as expected so what on earth is going on!?!

Another thing is that on the one PC there are no serial ports configured but using .GetPortNames() still returns COM5! A connection can be opened to it and data can be sent and read juuuuust fine. The data received is an exact mirror of what gets transmitted so it is a loopback for sure. Where it comes from I have no idea since I've never installed any software for that kind of thing.

Last but not least is an issue with 'The I/O operation has been aborted because of either a thread exit or an application request'. There's been an instance where an I/O loaded the port with data and this exception happened. Most people seem to think that it has to do with reading from a port when it's closed but code wise there is no way this could have happened. So the only alternatives are that the OS killed the port or that the buffers were overloaded... right?

But ja, that's the stuff I've found so far. Any comments?

 

[Robert_Zenz]

Hello there.

I've used the Reflector (see my signature) for the first issue you report, and figured that the SerialPort Class has an Encoding-Property which is used to convert the String. Default it's set to ASCII, so you may wanna check that.

The phantom input...does it appear out of the nowhere or if you have sent data to the powered off machine? It's not necessarily the way that a powered off machine does not do something on input. I've worked with Balances which are controlled over a serial interface, and those even respond if they are powered off (telling me that he can't do anything since he's powered off). But could it also be that it is somekind of background noise? Something like inducted current, which gets overlayed by the real communication so that it doesn't infer, but still strong enough to get noticed by the port if there's no communication?

COM5, could it be that this was installed by a complete other piece of software? F.e. Bluetooth Software is also using COM-Port-'Devices' for communication. Have also a look at the Device Manager (check in the menu the point to show all devices) if it appears there too.

I did a Google Search on the last issue and it seems like that it can have many different reasons, SerialPort The I/O operation has been aborted because of either a thread exit or an application request - Google-Suche .

Hope this helps,
Bobby