Prev: Prevent Dialog from Being Shown in OnShowWindow
Next: Dynamically creating new Views
From: Marius on 9 May 2008 10:20
Hello All,

This is more of a win32 question so I am sorry if I am off-topic but I
wasn't sure where to post this.

Here is my scenario: I have a USB to Serial converter that is using the
"Prolific" driver in order to emulate a serial port (it exposes it as COMx)
so I should be able to treat it as a regular port. Anyway, its settings are:
Baud Rate 9600, Data bits: 8, Parity: None, Stop Bits: 1, Flow Control:
None.

I have a barcode scanner (Symbol LS1203) connected to this converter and I
am trying to capture the data sent by this scanner. I can confirm that the
settings of the scanner match the settings of the driver (9600, 8, N, 1.)

My "virtual" com port is number 3.

So, I open the COM port handle as follows:

m_hComPort = CreateFile(_T("COM3:"), GENERIC_READ | GENERIC_WRITE, 0, NULL,
OPEN_ALWAYS, FILE_FLAG_OVERLAPPED, NULL);

CreateFile succeeds and returns me a com port handle. In a separate thread,
I use ReadFile (with an overlapped structure) in order to capture the
incoming data from the scanner. Since this is an asynchronous call, ReadFile
returns with ERROR_IO_PENDING and thus I wait for the event that I specified
in the overlapped structure (a manual reset event.) using
WaitForSingleObject.

When I scan a product, the event mentioned earlier is never signaled
(WaitForSingleObject never returns) and thus I concluded that no data is
comming in.

I suspected that the driver is, for some reason, not forwarding my
application the incoming data. So, to find out a little bit more, I ran a
"serial analyzer" tool to see if the scanner is actually sending any data.
In this software, I did a "New Serial Terminal Session" and I specified COM
3 with 9600, 8, N, 1, Flow Control: None. I started this session, scanned a
barcode and data was displayed so I concluded that the scanner is sending
the data and closed this analyzer tool.

After that, I ran my application (without modifying anything in its source
code) and scanned a barcode and indeed, this time the event got signaled and
the data was correctly captured.

I re-booted my machine, started my application again, scanned a barcode and
it did not receive it. I ran the analyzer tool again, did the same thing as
before, closed it and then ran my application. Again, my application
received the data successfully. Therefore, I concluded that somehow I am not
initializing the communication correctly but I have no idea what to do.

Thanks for your time,
Marius




From: Scott McPhillips [MVP] on 9 May 2008 10:42
"Marius" <prisasm(a)hotmail.com> wrote in message
news:%23bEMi$dsIHA.4376(a)TK2MSFTNGP06.phx.gbl...
> I suspected that the driver is, for some reason, not forwarding my
> application the incoming data. So, to find out a little bit more, I ran a
> "serial analyzer" tool to see if the scanner is actually sending any data.
> In this software, I did a "New Serial Terminal Session" and I specified
> COM 3 with 9600, 8, N, 1, Flow Control: None. I started this session,
> scanned a barcode and data was displayed so I concluded that the scanner
> is sending the data and closed this analyzer tool.
>
> After that, I ran my application (without modifying anything in its source
> code) and scanned a barcode and indeed, this time the event got signaled
> and the data was correctly captured.
>
> I re-booted my machine, started my application again, scanned a barcode
> and it did not receive it. I ran the analyzer tool again, did the same
> thing as before, closed it and then ran my application. Again, my
> application received the data successfully. Therefore, I concluded that
> somehow I am not initializing the communication correctly but I have no
> idea what to do.


Are you calling SetCommState? Make sure you do that and review all of the
settings it controls. To learn more, you might want to call GetCommState
after your serial analyzer has "fixed" the problem. This will show you what
settings it set.

Are you calling SetCommTimeouts? This controls the conditions that will
cause WaitForSingleObject to return. The basic idea is that you should set
the timeouts so WaitForSingleObject will return if a number of milliseconds
elapse with no new input arriving.

--
Scott McPhillips [VC++ MVP]

From: Marius on 9 May 2008 11:57
Hi Scott,

"Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message
news:e2ALrLesIHA.4476(a)TK2MSFTNGP06.phx.gbl...
> "Marius" <prisasm(a)hotmail.com> wrote in message
> news:%23bEMi$dsIHA.4376(a)TK2MSFTNGP06.phx.gbl...

>> I re-booted my machine, started my application again, scanned a barcode
>> and it did not receive it. I ran the analyzer tool again, did the same
>> thing as before, closed it and then ran my application. Again, my
>> application received the data successfully. Therefore, I concluded that
>> somehow I am not initializing the communication correctly but I have no
>> idea what to do.
>
>
> Are you calling SetCommState? Make sure you do that and review all of the
> settings it controls. To learn more, you might want to call GetCommState
> after your serial analyzer has "fixed" the problem. This will show you
> what settings it set.

That's a very good idea. Thank you!

> Are you calling SetCommTimeouts? This controls the conditions that will
> cause WaitForSingleObject to return. The basic idea is that you should
> set the timeouts so WaitForSingleObject will return if a number of
> milliseconds elapse with no new input arriving.

Well, in fact, I am using WaitForMultipleObjects with two events. One quit
event and the event set in the overlapped structure. So, when I want to
quit, I just set the quit event.

Thanks again for your suggestion. I will try it and post the results here.

Marius


From: Marius on 9 May 2008 13:12
Scott,

> Are you calling SetCommState? Make sure you do that and review all of the
> settings it controls. To learn more, you might want to call GetCommState
> after your serial analyzer has "fixed" the problem. This will show you
> what settings it set.

I called GetCommState and it successfully populated the DCB structure with
values. I confirmed that my application wasn't receiving any data after
which I ran that serial analyzer program and started the COM 3 emulation,
scanned a barcode and it worked. Then, I ran my application again, inspected
the values returned from GetCommState and they were IDENTICAL to the values
of the structure when the application would not receive the values although
the application would now receive data correctly. It is important to note
that the application will now work correctly until I reboot my computer...

I tried a "long shot" as well, namely I did a GetCommState and then I
overwrote a few fields of the DCB structures so that it would reflect a
9600, 8, N, 1 communication then called SetCommState but the results were
the same...

Thanks again for your advice,
Marius


From: David Ching on 9 May 2008 13:59
"Marius" <remove-thistextprisasm(a)hotmail.com> wrote in message
news:eTMbpffsIHA.552(a)TK2MSFTNGP06.phx.gbl...
> Scott,
>
>> Are you calling SetCommState? Make sure you do that and review all of
>> the settings it controls. To learn more, you might want to call
>> GetCommState after your serial analyzer has "fixed" the problem. This
>> will show you what settings it set.
>
> I called GetCommState and it successfully populated the DCB structure with
> values. I confirmed that my application wasn't receiving any data after
> which I ran that serial analyzer program and started the COM 3 emulation,
> scanned a barcode and it worked. Then, I ran my application again,
> inspected the values returned from GetCommState and they were IDENTICAL to
> the values of the structure when the application would not receive the
> values although the application would now receive data correctly. It is
> important to note that the application will now work correctly until I
> reboot my computer...
>
> I tried a "long shot" as well, namely I did a GetCommState and then I
> overwrote a few fields of the DCB structures so that it would reflect a
> 9600, 8, N, 1 communication then called SetCommState but the results were
> the same...
>

Then please make sure you are setting the wait timeouts, as Scott suggested.

-- David


 |  Next  |  Last
Pages: 1 2
Prev: Prevent Dialog from Being Shown in OnShowWindow
Next: Dynamically creating new Views