|
The Com1 port is closed in my app when I receive a Time_Out event (CloseHandle). So when opening the Hyperterminal after this event shouldn't generate a problem (otherwise HyperTerminal creates an error message). Also, as far as I know, if I try to create a handle to an open COM port, C++ generates an errorcode. But, please correct me if I am wrong.
|
|
|
|
|
FPeeters wrote: if I try to create a handle to an open COM port, C++ generates an errorcode
What do you mean with that ?
In fact, if you are trying to open a port which is already opened, the CreateFile function will return an invalid handle (check the documentation of this function). So, before trying to read on the port, you should verify that your handle is valid (handle != INVALID_HANDLE_VALUE).
|
|
|
|
|
Cedric Moonen wrote: In fact, if you are trying to open a port which is already opened, the CreateFile function will return an invalid handle (check the documentation of this function). So, before trying to read on the port, you should verify that your handle is valid (handle != INVALID_HANDLE_VALUE).
Sorry for the confusion, but this is what I was trying to say...
|
|
|
|
|
When I look at an article written by Konchat (Creating a Serial Communication on WIN32) he shows a screenshot (figure 2) where he sets portName as "COM1", but in the presented watch screen that portname has a value (0x00421a2c "COM1"). I assume that the hex code is in fact the real adress of the port. I haven't declared anything like this is my app, and I don't know what to declare and where.
|
|
|
|
|
Did you check all return values?
CreateFile returns a valid handle?
GetCommState and SetCommState return TRUE?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
As far as I can tell CreateFile returns a valid Handle and GetCommState and SetCommState are true.
Here is in pseudo-code how I did it:
hComm=CreateFile(("COM1"), GENERIC_READ|GERERIC_WRITE,0,0,OPEN_EXISTING,FILE_FLAG_OVERLAPPED,0);
if (hComm == INVALID_HANDLE_VALUE)
//ERROR MESSAGE TO LISTBOX
else
//OK MESSAGE TO LISTBOX
if (!GetCommState(hComm,&dcb))
//ERROR MESSAGE TO LISTBOX
else
//OK MESSAGE TO LISTBOX
if (!SetCommState(hComm, &dcb))
//ERROR MESSAGE TO LISTBOX
else
//OK MESSAGE TO LISTBOX
if(osReader.hEvent == NULL)
//ERROR MESSAGE TOLISTBOX
else
while (ReadActive)
if(!ReadFile(hComm,lpBuff,sizeof(lpBuff),&dwRead,&osReader))
//ERROR MESSAGE TO LISTBOX
else
dwResult = WaitForSingleObject(osReader.hEvent, READ_TIMEOUT);
switch(dwResult)
case WAIT_OBJECT_0
case WAIT_TIMEOUT
default
So if I get an INVALID_HANDLE_VALUE the rest of the code is skipped and an errormessage is written in a ListBox, also if either the GetCommState() and SetCommState() function restuns FALSE I should receive an error message in this ListBox. But I don't receive an error message and the app reports a Time-out on the Listbox.
|
|
|
|
|
Maybe the read operation was completed before the wait starts. Why don't you call GetOverlappedResult?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
My question is:
Why is he opening a bar code scanner with FILE_FLAG_OVERLAPPED in the first place. I have never seen a bar code scanner which required overlapped I/O.
Best Wishes,
David Delaune
|
|
|
|
|
Maybe his application requires it.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
No the reason why I used this kind of IO is quit simple: I couldn't find any explanation on how to run the COM port otherwise... So if there is any suggestion on how to work with a barcode scanner I would like to know.
|
|
|
|
|
You can simply use COM synchronously.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
In all the articles I've found everyone says you can use com synchronously but no-one explains it.
I am a starter on C++ (formerly programming PLC's and slowly changing over to PC control for some machines).
|
|
|
|
|
If you configure a COM for synchronous operations (see for instance [^]) then each call to ReadFile becomes a blocking one (until timeout expires, see [^]).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Thanks for the info, but to go back to my original problem: Does this solve it, or is it a better way to communicate for me with the com port?
|
|
|
|
|
At least, you can try.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
OK I deserved that one, ofcourse I can try, and I will..
|
|
|
|
|
Okay, I've tried the synchrounous approach but there is no change in the situation.
|
|
|
|
|
FPeeters wrote: I configure a connection between my app and the COM1 port of a PC using the following piece of code:
hComm = CreateFile(("COM1"),
Shouldn't this be:
CreateFile("\\\\.\\COM1", ...);
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Both methods are correct. You could consider "COM1" as a mapping to "\\\\.\\COM1" such as is created by DefineDosDevice[^]
Best Wishes,
-David Delaune
|
|
|
|
|
DavidCrow wrote: Shouldn't this be:
CreateFile("\\\\.\\COM1", ...);
This is, sadly enough, not the solution to my problem. But I'm curious: what is the meaning of "\\\\.\\"
|
|
|
|
|
FPeeters wrote: But I'm curious: what is the meaning of "\\\\.\\"
It's just a format that some arguments to CreateFile() must have. COM1 must not be one of those. Sorry 'bout that.
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
It is the UNC [^] path of COM1.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Hello Frank,
You should paste the contents of your DCB structure so I can take a look at it. There are some combinations of values that do not work. If you are also setting the COMMTIMEOUTS structure please paste that here as well.
Best Wishes,
-David Delaune
|
|
|
|
|
DCB structure:
DCBLength = 28
BaudRate = 38400
fBinary = 1
fParity = 0
fOutxCtsFlow = 0
fOutxDsrFlow = 0
fDtrControl = 1
fDsrSensitivity = 0
fTXContinueOnXoff = 1
fOutX = 0
fInX = 0
fErrorChar = 0
fNull = 0
fRtsControl = 1
fAbortOnError =1
fDummy2 = 0 (this one is not used but added for the complete structure)
wReserved = 0 (this one is not used but added for the complete structure)
XonLim = 2048
XoffLim = 512
ByteSize = 7
Parity = 0
StopBits = 0
XonChar = 17
XoffChar = 19
ErrorChar = 0
EvtChar = 0
wReserved1 = 0 (this one is not used but added for the complete structure)
The current settings for the Barcode reader are:
BaudRate = 38400 (default value)
DataBits = 7
Parity = NONE
StopBits = 1
RTS/CTS HardwareFlowcontrol = Off
Xon/Xoff SoftWareFlowControl = Off
Ack/Nak SoftwareFlowControl = Off
As for the COMMTIMEOUTS structure: I don't know if I am using this structure. I defined a constant (#define READ_TIMEOUT 5000) and use that in "WaitForSingleObject"
I hope you can send my in the right direction on solving this problem. Please explain any recommended changes in these settings so I can learn from it and avoid this in the future.
|
|
|
|
|
Sorry for the delay, I was not in the office yesterday.
You have some things wrong in your DCB structure.
FPeeters wrote: The current settings for the Barcode reader are:
HardwareFlowcontrol should be off according to your statement on the bottom.
You should make the following changes:
if(TRUE == GetCommState(m_hComm, &m_dcb))
{
m_dcb.BaudRate = CBR_38400;
m_dcb.Parity = NOPARITY;
m_dcb.StopBits = ONESTOPBIT;
m_dcb.fDtrControl = DTR_CONTROL_DISABLE;
m_dcb.fRtsControl = RTS_CONTROL_DISABLE;
m_dcb.fOutxCtsFlow = FALSE;
m_dcb.fOutxDsrFlow = FALSE;
m_dcb.fOutX = FALSE;
m_dcb.fInX = FALSE;
m_dcb.ByteSize = 7;
if(FALSE == SetCommState(m_hComm, &m_dcb))
{
TRACE0(_T("FAILED.\n"));
}
}
I am almost positive that you should change FILE_FLAG_OVERLAPPED to NULL when you open the COM port. I highly doubt that you need to do overlapped I/O with a barcode reader. Don't worry about the COMMTIMEOUTS for now, I was asking this question with the assumption that you were possibly performing overlapped i/o and the timeout structure would effect this.
Here is a good MSDN containing the explanation for the DCB fields. It looks like you just need to match what the barcode scanner is expecting.
http://msdn2.microsoft.com/en-us/library/aa363214(VS.85).aspx[^]
Best Wishes,
-David Delaune
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
