Prev: Why value changed after context switch?
Next: Can you specialize the Template operator==
From: Ian Semmel on 9 May 2008 14:30
You say you open the comms port and read it in a separate thread.

You may have to call DuplicateHandle in your read thread prior to
starting the read process.

"Marius" <prisasm(a)hotmail.com> wrote in message
news:#bEMi$dsIHA.4376(a)TK2MSFTNGP06.phx.gbl:

> 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: Marius on 9 May 2008 14:33
Scott,

> 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.

This was the key to the solution. Thanks! It seems that the other program
was probably settings the com port timeouts and that is why my application
was working after that. For some reason, I was under the impression that
ReadFile would magically know when the data should be returned. :)

Thanks again,
Marius


> --
> Scott McPhillips [VC++ MVP]


From: Marius on 9 May 2008 14:33

"David Ching" <dc(a)remove-this.dcsoft.com> wrote in message
news:lf0Vj.2696$7k7.1050(a)flpi150.ffdc.sbc.com...
> "Marius" <remove-thistextprisasm(a)hotmail.com> wrote in message
> news:eTMbpffsIHA.552(a)TK2MSFTNGP06.phx.gbl...

>> 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.

Thanks David. Indeed, the solution to the problem was to specify the com
timeouts.

Marius


>
> -- David
>
>


First  |  Prev  | 
Pages: 1 2
Prev: Why value changed after context switch?
Next: Can you specialize the Template operator==