Determining a virtual COM port of an USB device
Dilip
I am not a low-level developer -- more of an application programmer,
so I might've gotten some of my terminology wrong here. Do bear with
me.
We have a USB printer that we use in our application to print receipts
and such. The drivers for this printer also create a virtual COM port
for applications to communicate with it. Is there a way by which I
can enumerate all the devices that are on the USB ports and determine
what virtual COM port # they are sitting on? I know its possible to
blindly open all the available COM ports (virtual or otherwise) one by
one and query the device for its status and determine if its indeed a
printer or not. However I don't want to go down this route because if
by chance another device is sitting on one of the COM ports and I try
to send some printer-specific control characters it kinda messes up
that device.
I did read up a lot of stuff on the internet and even came across this
tiny program that displays all the USB devices connected to your PC --
(beware its a .PDF document containing CPP code)
http://www.intel.com/intelpress/usb/examples/DUSBVC.PDF
I managed to get that code to compile and it even printed information
regarding my printer but I wasn't able to determine its COM port from
that info.
Any way out of this?
chris.a...@gmail.com
> We have a USB printer that we use in our application to print receipts
> and such. The drivers for this printer also create a virtual COM port
> for applications to communicate with it. Is there a way by which I
> can enumerate all the devices that are on the USB ports and determine
> what virtual COM port # they are sitting on?
My advice is to drop the idea of looking for COM ports altogether and
look for device interfaces. Use SetupDiEnumDeviceInterfaces() to
enumerate all instances of the COM port GUID (i.e.
{86e0d1e0-8089-11d0-9ce4-08003e301f73}) and then look for your
device's VID and PID in the symbolic link.
Maxim S. Shatskih
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com
"Dilip" <rdi...@lycos.com> wrote in message
news:7b98a98a-0187-4da4...@a70g2000hsh.googlegroups.com...
abei
device by device name.
"Dilip" <rdi...@lycos.com>
??????:7b98a98a-0187-4da4...@a70g2000hsh.googlegroups.com...
chris.a...@gmail.com
> Add a proprietary IOCTL to your COM port implementation.
I think he wants to avoid communicating with unknown devices on the
system altogether. What if a customer's system has a buggy COM port
driver that crashes on unknown IOCTLs?
Dilip
I already managed to accomplish this. However I definitely need to
know the virtual COM port # because some of the status messages that
the device sends (like out-of-paper, lid open etc) comes via that
communication port. The only 2 uses of the USB port are for the
actual printing and to subscribe to printer plugged-in/plugged-out
events.
As I said its possible to interrogate every COM port from 1 - 10, send
some control characters, watch the response and then determine if the
printer is sitting there or not. The problem with this approach is if
another device has used one of these ports then sending control
characters to that device messes it up for some reason.
Dilip
The printer is a third party device. We don't own the source code to
it. I will have to work with what I have. See my reply to Chris
elsethread.
On Apr 4, 4:41 pm, "Maxim S. Shatskih" <ma...@storagecraft.com> wrote:
> Add a proprietary IOCTL to your COM port implementation.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> ma...@storagecraft.comhttp://www.storagecraft.com
>
> "Dilip" <rdil...@lycos.com> wrote in message
>
> news:7b98a98a-0187-4da4...@a70g2000hsh.googlegroups.com...
>
>
>
> > Howdy Gurus
>
> > I am not a low-level developer -- more of an application programmer,
> > so I might've gotten some of my terminology wrong here. Do bear with
> > me.
>
> > We have a USB printer that we use in our application to print receipts
> > and such. The drivers for this printer also create a virtual COM port
> > for applications to communicate with it. Is there a way by which I
> > can enumerate all the devices that are on the USB ports and determine
> > what virtual COM port # they are sitting on? I know its possible to
> > blindly open all the available COM ports (virtual or otherwise) one by
> > one and query the device for its status and determine if its indeed a
> > printer or not. However I don't want to go down this route because if
> > by chance another device is sitting on one of the COM ports and I try
> > to send some printer-specific control characters it kinda messes up
> > that device.
>
> > I did read up a lot of stuff on the internet and even came across this
> > tiny program that displays all the USB devices connected to your PC --
> > (beware its a .PDF document containing CPP code)
> >http://www.intel.com/intelpress/usb/examples/DUSBVC.PDF
> > I managed to get that code to compile and it even printed information
> > regarding my printer but I wasn't able to determine its COM port from
> > that info.
>
> > Any way out of this?- Hide quoted text -
>
> - Show quoted text -
Dilip
> My advice is to enumrate all COM port by COM class GUID then pick up your
> device by device name.
Could you show me an example of how to do this? You can also point me
in the right direction? I am more of an application programmer but
have been writing code for almost a decade. I shouldn't have any
problems getting something up and running if I knew where to look.
Pavel A.
>... I definitely need to
> know the virtual COM port # because ....
Ok then do you know the hw id of your USB device?
You can detect whether parent of the COM port is an usb device with certain
ID.
--PA
chris.a...@gmail.com
> On Apr 4, 4:41 pm, chris.aselt...@gmail.com wrote:
>
> > My advice is to drop the idea of looking for COM ports altogether and
> > look for device interfaces. Use SetupDiEnumDeviceInterfaces() to
> > enumerate all instances of the COM port GUID (i.e.
> > {86e0d1e0-8089-11d0-9ce4-08003e301f73}) and then look for your
> > device's VID and PID in the symbolic link.
>
> I already managed to accomplish this. However I definitely need to
> know the virtual COM port # because some of the status messages that
> the device sends (like out-of-paper, lid open etc) comes via that
> communication port. The only 2 uses of the USB port are for the
> actual printing and to subscribe to printer plugged-in/plugged-out
> events.
I don't think you understood what I said. Either opening the symbolic
link (i.e. "\\?
\ACPI#PNP0501#1#{86e0d1e0-8089-11d0-9ce4-08003e301f73}") or the
"virtual COM port #" (i.e. "\\.\COM9") -- each will give you a handle
to the same exact device stack.
In the case of the symbolic link, you can look for your device's
hardware ID in it, so that solves your problem of distinguishing
devices without probing.
Pavel A.
news:df83d95c-a9eb-4683...@b1g2000hsg.googlegroups.com...
.............
> In the case of the symbolic link, you can look for your device's
> hardware ID in it, so that solves your problem of distinguishing
> devices without probing.
Chris, this is risky - MS folks warned several times that the sym. link
format
can change.
--PA
chris.a...@gmail.com
> > In the case of the symbolic link, you can look for your device's
> > hardware ID in it, so that solves your problem of distinguishing
> > devices without probing.
>
> Chris, this is risky - MS folks warned several times that the sym. link
> format can change.
Yeah ... I know, I know. But think about it. What choice do you
have? When you call SetupDiEnumDeviceInterfaces() you're basically
saying "give me all the device interfaces registered on the system
with GUID X." The GUID specifies your contract with the driver. It
doesn't tell you anything about the device *behind* the driver. It
also doesn't tell you whose driver it is, either. So what's someone
supposed to do to find *their* device or *their* driver, without
actively probing each interface returned?
Looking at the doc page for SetupDiGetClassDevs, it seems to imply you
can pass a device instance ID to the function and it will limit the
results based on that ID. However I've never experimented with that.
Ben Voigt [C++ MVP]
You could instead check the parent device.
On a side note, I had some code that does something similar, but
interrogates the Location property. This breaks on Vista because the
Location no longer contains the Device Model string. Anyone know how to
obtain USB string descriptors from user mode when all I have is a DEVNODE?
(The UsbView sample uses different identifiers, so I'd need some way of
mapping them).
>
> --PA
Doron Holan [MSFT]
between the printer and the instance of the com port. also, once you have
an HDEVINFO you can query for properties that will give you the service
behind the sym link.
d
--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Ben Voigt [C++ MVP]" <r...@nospam.nospam> wrote in message
news:OouDhULm...@TK2MSFTNGP02.phx.gbl...
Rob
You can filter the events for certain device types.
Greetings,
Rob.