Hope you can help me on this.
I have a serial device, this device will then be connected to a USB-Serial converter, then the converter will be connected to my PC's usb port. The system will add another COM port to the Device Manager.
My question is, how can I possibly map the COM port number to the converter in C#? I can successfully enumerate available COM port in the system by doing the SerialPort.GetPortNames(), but not sure what COM port number this converter have.
thanks
ar
You can usually get some decent info out of a WMI query, although it requires the device driver to cooperate. Most do afaik. Run a query on the Win32_SerialPort class. You can use the WMI Code Creator tool to experiment with the query and auto-generate the C# code you need.
Don't count on being able to auto-select the device. You'll need a config option to allow the user to select the port. You can display the info you got from the query to help her pick the right one. Or ask her to unplug the device and plug it back in, the added COM port should be the right one.
We solved this different ways for different applications. We used explicit configuration for an instance where we had exactly one device of a particular type, but it wasn't clear what COM port it was going to be assigned until the system was configured. In another case, we had one USB cable that broke out into a hub with a bunch of converters on it, so we probed all the COM ports we could open successfully to look for our devices of interest.
A couple caveats with USB/serial converters on Windows -- if your device is something like a GPS unit that sends out data whenever it's powered on, Windows might detect it as an old serial mouse if it's plugged in during boot. Also, plugging into a different USB port is likely to chew up an additional COM port number (as well as break any explicit configuration you've done).
When i had the same problem (RFID reader), I checked each port if there was any data.
Probably it would be something in COM4 : COM9.
I know that it's not the best solution, but i used it on mobile device where i am sure about my COM connections...
Maybe in your driver's *.ini file there is some information about COM number.
If you are using an FTDI based solution for the USB<-> serial conversion, you can use the FT_PROG utility which is available from the FTDI web site to assign custom VID:PID pairs to the converter, which you can then query to identify which adapter is assigned to which virtual port.
Alternatively, you can make use of the FTDIChip-ID which is unique for each chip, details on this including code samples are located here: http://ftdichip.com/Support/SoftwareExamples/FTDIChip-ID.htm
You would have to look this up somewhere in the registry.
I can only assume this is a FTDI chip. If so, you may be able to get info from using their public API, which is included with the drivers.
If no other answers, I will check later tonite at home, as my JTAG debugger has the same chip.
Update:
Here is the registry key for my device's assigned COM port (under PortName)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_0483&PID_5740\498C54823932\Device Parameters
I guess you can just enumerate thru the USB devices with the usbser driver.
Related
I am trying to connect to a virtual com port provided by the drivers of a u-blox GPS device.
The device appears normally under the Sensors tab in Device Manager and I can really get the coordinate data using GeoCoordinateWatcher class from C#.
But I want to read the underlying NMEA data.
So in the process of doing that I installed the Virtual Com Port driver provided by U-BLOX and it generated a u-blox virta com port in devices manager.
Connecting to that using Putty is OK and I can see all the NMEA lines being dumped there.
but when I try to connect to the same port (after Putty is closed obviously) using C# I get the exception mentioned in the title
The given port name does not start with COM/com or does not resolve to
a valid serial port
My code is fairly simple (not the first time I use com ports) and everything is correctly defined (Port Name, Stop Bits, Parity, BaudRate etc). I even tried changing to a "wrong" com port name to see the exception I will get and it is completely different (Com Port does not a exit exception).
So what is happening with C# at this point? Am I doing something wrong? Is this a bug in the SerialPort class? Putty seems to work just fine in connecting and streaming the data.
My code is as simple as the following
m_port = new SerialPort
{
PortName = m_portName,
BaudRate = m_baudRate,
Parity = m_parityBit,
DataBits = m_dataBits,
StopBits = m_stopBit
};
m_port.Open();
I even tried hardcoding the values and I still get the same exception.
I tried many of the suggested solutions found here, none of them helped.
I also tried changing the COM port number from Device Manager advanced settings, that also did not help
As it turns out U-BLOX virtual COM port driver does not fully emulate a COM port which causes issues with .Net. Regardless if it is C# or C++ or any other language running on .Net
The only solution is to either, not use this device, or use an intermediary software.
If you don't have any particular reason for using the VCP driver, use the CDC driver instead. Available as "u-blox GNSS Standard Driver for Windows" at their website:
https://www.u-blox.com/en/product-resources/2673The/field_file_category/driver-221/field_file_products%253Afield_product_category/position-time-152
I had the same problem as you, but by changing the device driver, everything works as expected. It seems like their VCP driver is not fully compatible with the regular serial port driver structure.
I managed to resolve this issue, and thought I'd share my solution.
I wasn't able to use the CDC driver, as my device is a Rugged Windows Device with a dedicated GPS - the CDC solution may only work for removable gps devices via USB. The sensor driver must be installed, and the VCP driver can be installed alongside the sensor to provide a COM port.
Whilst the VCP driver does not fully emulate a COM port, you can use another piece of software to fully emulate the uBlox virtual com port and fill in the gaps. GPS Gate was that software for me - https://gpsgate.com/. The end result is uBlox Sensor -> uBlox VCP -> GPS Gate VCP. I was then able to successfully use the GPS Gate VCP in my C# app, and have GPS data coming down.
GPS Gate also offers a Location API plugin which could remove the uBlox VCP from the equation (uBlox Sensor -> GPS Gate VCP through Location API), but I didn't have much luck with it, plus I already had a working solution.
I have this system ive been working on where in the user has to print in a bluetooth thermal printer after every transaction. Can someone give me a source reference or a sample code for this particular function? he bluetooth printer brand is just generic, most of the sources in the website all have brands particularly Zebra. But i wont be using that since it might be different. any help would be nice. Thanks!
Please see inTheHand (or 32feet.net) for a framework using Bluetooth.
You need to discover and connect to the BT printer and then use a socket stream to send print commands.
You may also use RegisterDevice with the BT mAC address and then use the provided serial COM port to communicate with the printer.
To be more detailed you need to describe your needs in more details and shorter english sentences.
I have a device which sends data by com port on my computer.
I know how to simulate it, but the controller must be plugged in to simulate sending data (using Proteus)
Is it possible to simulate the com port sending data without having any external device plugged in?
For example: I want to write a C# program which opens the com port and waits for data, and another c# program which writes data on the same port.
The best way to do this is to use a software COM port emulator. I use com0com :
Null-modem emulator
This provides virtual NM COM port pairs on the system (ie: what is output to one is input to the other and vice-versa). The devices show up in Device Manager just like a real COM port so you interact with them in C# as though they were real hardware devices.
For simplicity's sake, get yourself a com port or null modem emulator. You'll get very far off track, and maybe waste a lot of time, trying to do this yourself.
See this post, too:
Faking an RS232 Serial Port
In my C# 2008 application, I use the SerialPort.GetPortNames() function to retrieve the list of currently available ports. What I have noticed is, when ever I plug in a USB device, it's port number i s shown in the list on my Application and when I unplug it and refresh the list, the port number is no longer there.
One phase of the application involves reading/writing data from/to the device continuously. Now, my expectation is, If I unplug the device during the operation and get the current Port list using SerialPort.GetPortNames(), the Port Name will not be there and I can use that to make the decision that the device has been unplugged.
To my surprise, the Port name is still found despite having it removed
Why is the program behaving like this? The port name isn't listed when in no-communication mode. Does it have something to do with the device being removed when it's communicating?
You have to be talking about SerialPort.GetPortNames(), "GetPortList" doesn't make sense. The function iterates values in the registry, written there by your USB emulator device driver. You can have a look-see with Regedit.exe, navigate to HKLM\Hardware\DeviceMap\SerialComm. Unplug it, press F5, if the COM port is still there then SerialPort doesn't know any better than the port still being present.
There is no prescribed behavior as to how a serial port device driver should behave when the port suddenly vanishes. Serial ports are very primitive, they date back to an era where "bug" meant a moth gumming up the teletype. There is no hardware support at all for Plug and Play, removing a port with the power turned on is equivalent to unplugging the disk drive while Windows is swapping to the paging file.
Most device drivers return an error code, it generates an uncatchable exception that crashes your program. The subject of this feedback article. Apparently your device driver doesn't do that, which ought to be preferable over bombing your program. Encouraging btw, most USB emulator device drivers are utter junk.
The ultimate workaround is simple: put a little tag on the plug "don't disconnect while in use!" It's kinda of a problem with USB, most people look at it and go "hmm, what can I do with it?". And arrive at the only answer and unplug it. After a couple of kabooms, they'll learn to not do that anymore.
I'm assuming you mean System.IO.Ports.SerialPort.GetPortNames(), because i could not find a GetPortList() function anywhere. MSDN says: "If the registry contains stale or otherwise incorrect data then the GetPortNames method will return incorrect data", so that's probably where the problem lies. I guess Windows doesn't update the registry if the port is still being 'used', just like you can't delete a file when a program has a handle on it.
If you want to test if the device is removed, you can do so with a Window API call (http://www.pinvoke.net/default.aspx/user32/RegisterDeviceNotification.html). Hope that helps!
It is correct that GetPortNames() reads the ports from the Registry key
HKLM\Hardware\DeviceMap\SerialComm
This is automagically updated by Windows every time a port is opened or closed.
But nevertheless it has happened to me that there is a non-existent Port listed in the Registry, and also returned from GetPortNames(). When I try to open this port I get "The Port XYZ does not exist".
What is that ???
I now found out the reason:
This happens always after using PortMon from www.sysinternals.com.
This tool is buggy and lets the dead port hanging around in the Registry if the port is closed while it is monitored.
In this case the only remedy is to reboot the computer.
As others have mentioned, it's very driver-specific. There does not appear to be a way to check with the .Net API whether a port returned by GetPortNames() actually exists and is valid.
As for why the ports behave like this, I have found that some USB-to-serial drivers cause the application to crash when the port is unplugged suddenly.
Other drivers, often those that do not crash, will keep the port in the list until your application closes it, then it disappears. Trying to read from or write to the stale port will (usually) cause timeouts or errors. Presumably, in order not to crash the application, the driver needs to keep the stale port around while it is still open in the application.
If you plug in the port again, some drivers are even be able to reconnect it to your application, others will not recognize the port until your application closes the stale port. This reconnecting behaviour can be somewhat dangerous if the port disappeared because the device rebooted, because then it will suddenly be in a different state than your application expects without an obvious indication that it has reset. At least if you get errors from the port you know that something happened.
I've also found that if I forget to close the port, it won't disappear from the list until the garbage collector gets around to disposing the SerialPort object.
I am working on driver that talks to a device via a serial port in C#.
I do not always have the device available to do physical testing with. Is there a way I can simulate a device on a serial port so that it responds in an ideal manner?
Get a second COM port and use a Null-modem cable to connect the COM ports to allow two C# programs to talk to each other.
I used Com0Com for a while and wrote some simulator/emulator code.
What kind of driver? If it is the serial interface driver, then that gets quite tricky.
However, if your driver is an application level above the Windows device driver, then it's fairly easy to replace the i/o behavior by altering the string passed to CreateFile, or whatever layer on top of that C# uses.
== More ==
Since you use the .net library tools, this technique may be too yucky to bother. However the idea is to replace where, at some point, your code says open COM1: or whatever. Change that to be a file which has the simulated data, say `c:/com1testdata.txt'. Additional emulation code which recognizes the contents of the file for pauses and/or responses might be useful for some protocols. Data which is written to the port can be logged or ignored, depending on your requirements.
When working in a team designing some custom hardware I used a great terminal emulator called ZTerm (only available for Mac, I believe). It allows you to script responsees which enabled me to complete the software to our pre-agreed specification while the custom controller chips were still in the design iteration stage.
If you're running in a VM, you may be able to attach things to the serial port. QEMU, for instance, allows you to attach the virtual serial port to a TTY, which you can then interact with either manually or with a program running on the host.