I want to auto detect devices connected to the COM ports of my computer. Being able to use the SerialPort class allows me to get the list of available COM ports easily.
I want to iterate through them and poll(send a command) to each port and wait for a response. However it seems that most tutorials suggested to use the DataReceived event. I am lost at how to do a serial send followed by waiting for xx amount of seconds till I receive a response from the device.
The DataReceived event is very nice when you need to talk to devices that can send something at a very unpredictable time. You don't have to burn up a thread that just blocks and waits for the device to send something.
But that's completely the opposite of what you're trying achieve, you do expect to receive something. So don't use DataReceived, use Read() with the ReadTimeout property set to a suitably low value. Now it is simple. Also consider using the DsrHolding property. It is true when there's a device attached to the port and it is powered-up.
I should note that doing this is rather dangerous. You have no idea what kind of devices are attached to the machine, it is rather tricky to send them something they were not designed to process. If whatever "are you there?" command you send just happens to mean to a robot controller "go home with 1G acceleration" then somebody is going to get hurt easily. You cannot do this in any kind of industrial setting.
By far the best way is to make it somebody else's responsibility to get this right. Add an option menu that lets the user set the port name. And settings, they matter a lot too and there's no way to auto-detect them. The option dialog could have a "help me find the device" button, now it is safe and useful.
I believe WMI have feature to query devices on COM, there is also Linq to WMI library that could be helpful
Hope this helps
Related
I'm writing a C# program that reads data from a USB GPS logger, which acts like a new COM port when i plug it in. I've managed to write some code that listens to the COM port and fires an event when it receives data, but i have a few problems with this approach :
The event listener is way to slow : i get like only 1 result per second which takes forever if there are thousands of tracks on the logger.
Since i don't know how much data the logger contains, how do i know when i should stop the event listener, without losing data? I would also like to write all the data to a csv file, but since i dont know when to stop listening, i also don't know when to call my writer function.
I actually don't understand why this happens over a COM port, since the logger already contains all the data i need? I just want to extract it all at once. Is there a way to accomplish this? Thanks in advance!
I believe there is not much you can do about this.
You can't change the behavior of the USB device, since this is a driver issue.
The reason it is recognized as a COM port is probably because the manufacturer who made the device didn't want to have to deal with the devious task of writing drivers for the device.
So instead he used a chip that translates the data from the microchip to "Serial communiation", to emulate RS-232 communication. Which is far easier to handle. Also for you, because you probably wouldn't be able to read the data or interact with a Custom USB device without proper documentation..
The normal baud rate for RS-232 is usual 9600. This would be minimal 9600 Bits per Second.
So thinking it could be a 8 or 16 bit device, this would result in 1200 or 600 integers per minute.
So depending on the data you read per result, i think 1 result/second is rather slow.
Hope this is of any help.
I can use some help for a designing my COMport connection classes.
I have a device with a microcontroller (which I programmed) connected to my comport.
Whenever I send a message to it, it should send an acknowledge.
So whenever I send something over the comport, it should wait for an acknowledge before continuing.
Ofcourse, I dont want something like a while(!ack) wait().
When a ack is not received in 1 second or so, it should send the command again.
The Ack looks different for each type of command (note: only the type, no message-specific id).
The connected device also sends messages (apart from ACKs), which need to be handled by the application itself.
Does anybody has suggestions about an easy and flexible way (a design pattern maybe? a sample?) to fix this?
You'll probably want a dedicated thread that handles the communications. You'll need a Queue on which the client code can push a message, protect it with a ReaderWriterLockSlim. No need for the DataReceived event, just call SerialPort.Read() directly. Detect timeouts with the ReadTimeout property. If you get responses that need to go back to the client code then use an event.
Watch out designing the protocol, it isn't that easy to get right. You'll protect against loss of bytes with your scheme, but it is just as likely for the ACK to be lost. The microcontroller will see the same command twice. Now you need a "message number" to suppress duplicates and a way for both ends to synchronize them. Take a look at RFC 916.
I am working on an application that needs to control another device.
This control should be using Wi-Fi.
How can this be done in C#?
Important to know that the other device I want to make it.
I can afford the part of making and design but how to make it connect to PC using Wi-Fi?
I don't know about it.
I just need a key to start searching or some thing similar.
Connecting over Wi-Fi could be as easy as opening a socket on the server, and another on the client, and start streaming data. Of course this if both devices are compatible and has Wi-Fi receivers. Just think of them as two computers connected with a wire, or without a wire they will just behave the same.
The connection protocol will care about doing the magic of converting what you write on the socket, into RF signals received from the other device and converted back to bytes.
But if you are building your own antenna/receiver/protocol ... then things will be much more complicated.
If you have to ask then you're probably going to want a single board computer. Popular choices are:
gumstix
Zii EGG
nwg100 by Atmel
(XBee) --not too sure about these, I haven't used.
You can install a network stack and everything on them.
I'm an embedded programmer trying to do a little bit of coding for a communications app and need a quick start guide on the best / easiest way to do something.
I'm successfully sending serial data packets but need to impliment some form of send/ response protocol to avoid overflow on the target system and to ensure that the packet was received ok.
Right now - I have all the transmit code under a button click and it sends the whole lot without any control.
What's the best way to structure this code , i.e sending some packets - waiting for response .. sending more .. etc etc until it's all done, then carrying on with the main program.
I've not used threads or callbacks or suchlike in this environment before but will learn - I just need a pointer to the most straigtforward ways to do it.
Thanks
Rob
The .NET serialport uses buffers, learn to work with them.
Sending packets that are (far) smaller than the Send-buffer can be done w/o threading.
Receiving can be done by the DataReceived event but beware that that is called from another thread. You might as well start your own thread and use blocking reads from there.
The best approach depends on what your 'packets' and protocol look like.
I think to have a long experience about serial comm, both MCU and PC-based.
I strongly UNSUGGEST the single-thread based solution, although it is very straigthful for light-speed testing, but absolutely out for final releases.
Surely you may choose among several patterns, but they are mostly shaped around a dedicated thread for the comm process and a finite-state-machine to parse the protocol (during receiveing).
The prevoius answers give you an idea to how build a simple program, but it might depends on the protocol specification, target device, scope of the application, etc.
there are of course different ways.
I will describe a thread based and an async operation based way:
If you don't use threads, your app will block as long as the operation is performing. This is not what a user is expecting today. Since you are talking about a series of sending and receiveing commands, I would recommend starting the protocol as a thread and then waiting for it to finish. You might also place an Abort button if neccesary. Set the ReadTimeout values and at every receive be ready to catch the exception! An introducing into creating such a work thread is here
If you want to, use Async Send/Receive functions instead of a thread (e.g. NetworkStream.BeginRead etc.). But this is more difficult because you have to manage state between the calls: I recommend using a Finite State Machine then. In fact you create an enumeration (i.e. ProtocolState) and change the state whenever an operation has completed. You can then simply create a function that performs the next step of the protocol with a simple switch/case statement. Since you are working with a remote entity (in your case the serial target system), you always have to consider the device is not working or stops working during the protocol. Do this by starting a timeout timer (e.g. set to 2000ms) and start it after sending each command (assuming each command will get a reply in your protocol). Stop it if the command was received successfully or on timeout.
You could also implement low-level handshaking on the serial port; set the serial port's Handshake property to rts/cts or xon/xoff.
Otherwise (or in addition), use a background worker thread. For simple threads, I like a Monitor.Wait/Pulse mechanism for managing the thread.
I have some code that does read-only serial communications in a thread; email me and I'll be happy to send it to you.
I wasn't sure from your question if you were designing both the PC and embedded sides of the communication link, if you are you might find this SO question interesting.
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.