I am trying to detect whether the serial connection still exists or is broken down. How to detect live serial port connection in c#? Can the SerialPort.PinChanged Event be used for the same?
The term "life" has no useful meaning on serial ports. They are very primitive devices that date back to the stone-age of computing. It is where you plugged in your ASR-33 teletype to start banging in your Fortran program. There is no logical connection state and no error recovery, there is no way to share a serial port between multiple programs. Just a raw byte stream, it sits at the very bottom of the OSI model, implementing the physical layer.
It is never useful to use the IsOpen property, you want to immediately Open() the port so no other program can steal the port away from you. Don't call Close() until the very end of the program. Or never, Close() has several gritty deadlock problems.
The electrical standard does include handshake signals, about as close you could get to discover what is happening on the other end of the cable. The SerialPort.DsrHolding property is true when the device has turned on its DTR signal and can usually be interpreted as a power-on signal. Not every device implements it however. Not initializing the SerialPort.Handshake property is a standard bug and the core reason why you don't get a TimeoutException when writing to the port when it is disconnected. Most devices implement Handshake.RequestToSend, they use the RTS and CTS signals to tell the other side that it is ready to receive data and to prevent buffer overflow. Always check the manual first.
Related
i would like to implement a rather simple function, that outputs the byte array of a serial port, e.g.
byte[] o = readAllDataFromSerialPort();
Implementing the actual serial port functions is done. I use the serial port to receive some data and process the data through the event DataReceived.
sp = new SerialPort(portname, 9600, System.IO.Ports.Parity.None, 8, System.IO.Ports.StopBits.One);
sp.Handshake = Handshake.None;
sp.DataReceived += new SerialDataReceivedEventHandler(serialDataReceived);
I check the received data for an "message end"-package in order to then close the serial port, so sth. like
if (data = "UA") sp.Close()
So basically what I would like to do is wait for the closure, before giving back the data, so that on the top level view the program doesn't progress, until the data has arrived. However I cannot wrap my head around as to how I implement this "waiting" in an effective and elegant way, as I'm relying on events for my data. Any hints or clues or examples would be much appreciated.
Serial ports are not open or closed. The Open or Close functions open a handle to the serial port driver.
If no handle is open to the driver all input from the port is ignored.
The only way you can determine whether you have received all the data is to design a protocol that provides you with a guaranteed way to detect the end of a transmission.
You can do this with one of:
Either select a unique terminator for the end of your message,
Include a length towards the beginning of your message that indicates the amount of remaining data, or
Wait for long enough (which also depends) to be sure no more data is pending.
A further reason for the Open, Close metaphor is that a serial port is typically an exclusive resource and only a single process can gain access to the handle at a time to prevent incompatible (and possibly dangerous) access to the device at the other end of the port inadvertently. You should keep the port open throughout your program to prevent the connected device from becoming inaccessible because another program opens the device inappropriately.
The lack of hot-plugging facilities (and in fact device identification) makes serial ports much more static and keeping the device open should not be a problem.
You seem to favour the third option. Implement this by resetting a timer that is set each time data is received, and if it expires assume the transmission is complete.
As it sais on the SerialPort.Close() documentation:
The best practice for any application is to wait for some amount of time after calling the Close method before attempting to call the Open method, as the port may not be closed instantly.
There is no way to wait for it to be closed. you can call it a "bug" or a "function as designed"
It is a bad practice to Open and Close a SerialPort over and over again with the same program. You should keep the SerialPort open.
If you really want to close it and will open it later again you can add a small sleep before returning, but sleeps without meanings are bad practice.
I found this nice post https://stackoverflow.com/a/10210279/717559
with a nice quote:
This is the worst possible practice for "best practice" advice since it doesn't at all specify exactly how long you are supposed to wait.
Till now I opened when I needed to send data, and closed right away.
I get random "Access to Port" errors (although I always close the port after I use it),
so I was thinking maybe to leave it always open.
What is the right approach of use, assuming that every minute or two I need to send data in some COM ports?
Thanks..
Calling SerialPort.Close() frequently is a mistake. Having another app steal the port away from you isn't exactly very desirable. But more problematic, and the problem you are having, is that Close() doesn't wait for a worker thread that is started by SerialPort to exit. That worker thread raises the DataReceived, PinChanged and ErrorReceived events. It takes "a while" for it to exit, could be between milliseconds and seconds. Calling Open() again will fail until that's done.
It's a flaw in the class, but induced by the common usage for serial ports. Apps don't normally close them until the app terminates. Including never, avoiding a common deadlock scenario. Do note that the MSDN article for Close warns about this:
The best practice for any application is to wait for some amount of time after calling the Close method before attempting to call the Open method, as the port may not be closed instantly.
If you're worried about the opening/closing and other apps stealing the COM port away, you could use the approach used by Microsoft for the GPS intermediate driver in windows embedded, i.e. to write an aggregator, one which opens the port, keeps it open, then provides connection points for other apps to connect to.
How you create the connections is up to you: you can get right down deep in the hardware and write a virtual com port driver that's shareable, or you can do what I did and write a simple win32 socket service that allows client programs to connect via regular windows socket connections.
Maybe not a straight forward answer, but food for thought.
There is very little harm in leaving a serial port open, so yes, keep it open. It saves you the overhead of open/closing it.
I have a GPIB device that I'm communicating with using a National Instruments USB to GPIB. the USB to GPIB works great.
I am wondering what can cause a GPIB device to be unresponsive? If I Turn off the device and turn it back on it will respond, but when I run my program it will respond at first. It then cuts off I can't even communicate with the GPIB device it just times out.
Did I fill up the buffer?
Some specifics from another questioner
I'm controlling a National Instruments GPIB card (not USB) with PyVisa. The instrument on the GPIB bus is a Newport ESP300 motion controller. During a session of several hours (all the while sending commands to and reading from the ESP300) the ESP300 will sometimes stop listening and become unresponsive. All reads time out, and not even *idn? produces a response.
Is there something I can do that is likely to clear this state? e.g. drive the IFC line?
Since you are using National Instruments hardware you can run NI Trace in the background to check all the commands that is send out from the Program. In the Trace do check the last command and its parameters that is send out from the program that causes the hardware to hang.
You can download NI IO Trace here
There should be a clear command (something like "*CLS?", but dont quote me on that). I always run that when i first connect to a device. Then make sure you have a good timeout duration. I found for my device around 1 second works. Less then 1 second makes it so I miss the read after a write. Most of the time, a timeout is because you just missed it or you are reading after a command without a return. Make sure you are also checking for errors in the error queue in between write to make sure the write actually properly when through.
Even the command *CLS will not work if the device is not listening anymore (which might be the case here). The only way to force resetting the device's interface whatever its status (listening or not) is to send the low-level gpib bus message "Selected Device Clear" (it is implemented by the function "ibclr" of the standard gpib library, e.g. https://www.l-com.com/multimedia/manuals/M_USB-488.PDF page 3-7, but I don't know what is the equivalent in Python). This command is intended to be used whenever a GPIB error occurs, I'm always doing it and never had problems. For this to work well you should also monitor the return values of all gpib calls - usually people don't do it so they are unaware of errors until the program hangs.
Here's the scenario - I have a C# application that reads from a COM port. Most of the time I use devices with a serial adapter and on a machine with a serial ports. However, machines with serial ports are increasingly difficult to come by so I have started using machines with a USB/Serial connection.
In some cases, the C# code that I have will work just fine with a "true" serial connection but fail with a USB/serial connection. The data comes in fragmented with the first part of the data coming in (like maybe the first 1 or 2 characters) and nothing else.
I'm using something basic like comport.ReadExisting() to pick up the data from the port. Is this part of the problem? Are there other methods that would guarantee that all the data would be read in a single string?
Finally, I want to add that I've already played around with some of the USB/serial settings in device manager AND the data comes in fine when using good, ole' hyperterminal . . . so it has to be something in the code.
With USB-serial converters, you MUST set your receive timeout, because the data can sit in the USB device for a long time where Windows doesn't know about it. Real serial ports hold data in the 16550 FIFO where the Windows driver can see it.
Most of the times you would want to use the SerialPort.DataReceived event ( http://msdn.microsoft.com/en-us/library/system.io.ports.serialport.datareceived.aspx ).
This requires you to combine the chunks of data manually since you can receive parts of your string, but once you detect the boundary of a single 'record' you can fire of processing that record while letting the IO receive more events.
This allows some asynchronous IO which doesn't block your threads, and thus allows more efficient handling of the data in general. If it helps in your specific situation I don't know, but it has helped me in the past dealing with data reading issues, low speeds, thread pooling, and lock-ups.
Here's some background on what I'm trying to do:
Open a serial port from a mobile device to a Bluetooth printer.
Send an EPL/2 form to the Bluetooth printer, so that it understands how to treat the data it is about to receive.
Once the form has been received, send some data to the printer which will be printed on label stock.
Repeat step 3 as many times as necessary for each label to be printed.
Step 2 only happens the first time, since the form does not need to precede each label. My issue is that when I send the form, if I send the label data too quickly it will not print. Sometimes I get "Bluetooth Failure: Radio Non-Operational" printed on the label instead of the data I sent.
I have found a way around the issue by doing the following:
for (int attempt = 0; attempt < 3; attempt++)
{
try
{
serialPort.Write(labelData);
break;
}
catch (TimeoutException ex)
{
// Log info or display info based on ex.Message
Thread.Sleep(3000);
}
}
So basically, I can catch a TimeoutException and retry the write method after waiting a certain amount of time (three seconds seems to work all the time, but any less and it seems to throw the exception every attempt). After three attempts I just assume the serial port has something wrong and let the user know.
This way seems to work ok, but I'm sure there's a better way to handle this. There are a few properties in the SerialPort class that I think I need to use, but I can't really find any good documentation or examples of how to use them. I've tried playing around with some of the properties, but none of them seem to do what I'm trying to achieve.
Here's a list of the properties I have played with:
CDHolding
CtsHolding
DsrHolding
DtrEnable
Handshake
RtsEnable
I'm sure some combination of these will handle what I'm trying to do more gracefully.
I'm using C# (2.0 framework), a Zebra QL 220+ Bluetooth printer and a windows Mobile 6 handheld device, if that makes any difference for solutions.
Any suggestions would be appreciated.
[UPDATE]
I should also note that the mobile device is using Bluetooth 2.0, whereas the printer is only at version 1.1. I'm assuming the speed difference is what's causing the printer to lag behind in receiving the data.
Well I've found a way to do this based on the two suggestions already given. I need to set up my serial port object with the following:
serialPort.Handshake = Handshake.RequestToSendXOnXOff;
serialPort.WriteTimeout = 10000; // Could use a lower value here.
Then I just need to do the write call:
serialPort.Write(labelData);
Since the Zebra printer supports software flow control, it will send an XOff value to the mobile device when the buffer is nearly full. This causes the mobile device to wait for an XOn value to be sent from the printer, effectively notifying the mobile device that it can continue transmitting.
By setting the write time out property, I'm giving a total time allowed for the transmission before a write timeout exception is thrown. You would still want to catch the write timeout, as I had done in my sample code in the question. However, it wouldn't be necessary to loop 3 (or an arbitrary amount of) times, trying to write each time, since the software flow control would start and stop the serial port write transmission.
Flow control is the correct answer here, and it may not be present/implemented/applicable to your bluetooth connection.
Check out the Zebra specification and see if they implement, or if you can turn on, software flow control (xon, xoff) which will allow you to see when the various buffers are getting full.
Further, the bluetooth radio is unlikely to be capable of transmitting faster than 250k at the maximum. You might consider artificially limiting it to 9,600bps - this will allow the radio a lot of breathing room for retransmits, error correction, detection, and its own flow control.
If all else fails, the hack you're using right now isn't bad, but I'd call Zebra tech support and find out what they recommend before giving up.
-Adam
The issue is likely not with the serial port code, but with the underlying bluetooth stack. The port you're using is purely virtual, and it's unlikely that any of the handshaking is even implemented (as it would be largely meaningless). CTS/RTS DTR/DSR are simply non-applicable for what you're working on.
The underlying issue is that when you create the virtual port, underneath it has to bind to the bluetooth stack and connect to the paired serial device. The port itself has no idea how long that might take and it's probably set up to do this asynchronously (though it would be purely up to the device OEM how that's done) to prevent the caller from locking up for a long period if there is no paired device or the paired device is out of range.
While your code may feel like a hack, it's probably the best, most portable way to do what you're doing.
You could use a bluetooth stack API to try to see if the device is there and alive before connecting, but there is no standardization of stack APIs, so the Widcom and Microsoft APIs differ on how you'd do that, and Widcom is proprietary and expensive. What you'd end up with is a mess of trying to discover the stack type, dynamically loading an appropriate verifier class, having it call the stack and look for the device. In light of that, your simple poll seems much cleaner, and you don't have to shell out a few $k for the Widcom SDK.