Click here to Skip to main content
15,070,613 members
Home / Discussions / C / C++ / MFC
   

C / C++ / MFC

 
GeneralRe: Device on RS232 only responds to first send request (Visual C++) Pin
David MacKinnon27-Sep-16 11:38
MemberDavid MacKinnon27-Sep-16 11:38 
GeneralRe: Device on RS232 only responds to first send request (Visual C++) Pin
jeron127-Sep-16 11:44
Memberjeron127-Sep-16 11:44 
GeneralRe: Device on RS232 only responds to first send request (Visual C++) Pin
David MacKinnon27-Sep-16 12:10
MemberDavid MacKinnon27-Sep-16 12:10 
GeneralRe: Device on RS232 only responds to first send request (Visual C++) Pin
jeron127-Sep-16 13:28
Memberjeron127-Sep-16 13:28 
GeneralRe: Device on RS232 only responds to first send request (Visual C++) Pin
David MacKinnon28-Sep-16 12:30
MemberDavid MacKinnon28-Sep-16 12:30 
GeneralRe: Device on RS232 only responds to first send request (Visual C++) Pin
jeron129-Sep-16 4:19
Memberjeron129-Sep-16 4:19 
GeneralRe: Device on RS232 only responds to first send request (Visual C++) Pin
David MacKinnon29-Sep-16 4:43
MemberDavid MacKinnon29-Sep-16 4:43 
AnswerRe: Device on RS232 only responds to first send request (Visual C++) Pin
leon de boer27-Sep-16 17:18
Memberleon de boer27-Sep-16 17:18 
First housekeeping when you open a comport you really need to put the colon in ... its "COM1:".
Yes your string works on some versions of Windows but not all, the documentation spells it out
To open a serial port
    - Insert a colon after the communication port pointed to with the first parameter, lpzPortName.
    For example, specify COM1: as the communication port.


In the ReadFile documentation it spells out the blocking function.
ReadFile function (Windows)[^]

You will have an error which will be a Readtimeout. Why because you set the read timeout to
1 second and execute a read and there won't be any data because you haven't yet sent another
command.

From that moment on you are toast as your code does not ever clear the error condition and
ReadFile will always return with reading zero bytes because you haven't cleared the error.
The big obvious is there isn't even a single GetLastError in your code much less dealing
with the error. The reason the terminal program fixes the problem is at some point they go
and clear the error.

You could try brutal and SetLastError to zero just before the ReadFile .. I don't like it
but it will probably work Smile | :)

While the thread error variable has an error value I am pretty sure that none of the IO
functions will work so I am pretty sure WriteFile will also bail always writing zero
bytes while it's set. It should also return success but the actual bytes written will
always be zero because the fail out is for pre-existing error that hasn't been cleared.

I don't particually like the way you are using the com port but probably the easiest way
to fix you problem is make the ReadFile timeout bail immediately .. so set no timeout on
the read. How to do that is given in the documentation
COMMTIMEOUTS structure (Windows)[^]

Quote => "A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant
and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return
immediately with the bytes that have already been received, even if no bytes have been
received."

That should stop you getting a read timeout which should fix your problem with your current code
and it getting into a block condition. It just means it will spin around your do loop like a crazy
person rather than slow 1 second pace it currently is.

On the plus side it will be more responsive Smile | :)

However you really need to actually put in code to deal with errors, you set the com timeouts
but do nothing if the timeout or any other error actually occurs.
In vino veritas


modified 28-Sep-16 0:32am.

GeneralRe: Device on RS232 only responds to first send request (Visual C++) Pin
David MacKinnon29-Sep-16 4:45
MemberDavid MacKinnon29-Sep-16 4:45 
AnswerRe: Device on RS232 only responds to first send request (Visual C++) Pin
David MacKinnon29-Sep-16 4:40
MemberDavid MacKinnon29-Sep-16 4:40 
Question_tcscpy_s and unused buffer part Pin
leon de boer27-Sep-16 5:39
Memberleon de boer27-Sep-16 5:39 
AnswerRe: _tcscpy_s and unused buffer part Pin
Richard MacCutchan27-Sep-16 6:26
mveRichard MacCutchan27-Sep-16 6:26 
GeneralRe: _tcscpy_s and unused buffer part Pin
leon de boer27-Sep-16 18:36
Memberleon de boer27-Sep-16 18:36 
AnswerRe: _tcscpy_s and unused buffer part Pin
Richard MacCutchan27-Sep-16 6:33
mveRichard MacCutchan27-Sep-16 6:33 
AnswerRe: _tcscpy_s and unused buffer part Pin
Chris Losinger27-Sep-16 7:28
professionalChris Losinger27-Sep-16 7:28 
GeneralRe: _tcscpy_s and unused buffer part Pin
leon de boer27-Sep-16 20:24
Memberleon de boer27-Sep-16 20:24 
GeneralRe: _tcscpy_s and unused buffer part Pin
David Crow27-Sep-16 8:20
MemberDavid Crow27-Sep-16 8:20 
GeneralRe: _tcscpy_s and unused buffer part Pin
leon de boer27-Sep-16 18:35
Memberleon de boer27-Sep-16 18:35 
QuestionRe: _tcscpy_s and unused buffer part Pin
David Crow28-Sep-16 2:35
MemberDavid Crow28-Sep-16 2:35 
AnswerRe: _tcscpy_s and unused buffer part Pin
leon de boer28-Sep-16 17:47
Memberleon de boer28-Sep-16 17:47 
GeneralRe: _tcscpy_s and unused buffer part Pin
David Crow28-Sep-16 18:09
MemberDavid Crow28-Sep-16 18:09 
GeneralRe: _tcscpy_s and unused buffer part Pin
leon de boer28-Sep-16 18:14
Memberleon de boer28-Sep-16 18:14 
GeneralRe: _tcscpy_s and unused buffer part Pin
David Crow29-Sep-16 3:10
MemberDavid Crow29-Sep-16 3:10 
AnswerRe: _tcscpy_s and unused buffer part Pin
Joe Woodbury24-Oct-16 14:36
professionalJoe Woodbury24-Oct-16 14:36 
QuestionArrow Key use in MFC vc++ Application Pin
rajmohan 12327-Sep-16 2:38
Memberrajmohan 12327-Sep-16 2:38 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.