06-06-2013 12:23 PM
I seem to have found a slight issue using InstallComCallback() between WinXP and Win7 target machines.
I developed my initial software on WinXP. The following two bits of code worked fine in WinXP with an eventMask = LWRS_RXFLAG | LWRS_RECEIVE. But when I distributed the final software to Win7 machines, I was observing the callback getting called twice each time.
Here's my callback:
// Callback scanner COM function void BarcodeScanner(int scannerPortNumber, int eventMask, void *callbackdata) { // re-init the output buffer memset(scannerData,0,SCANNER_MAX_BYTES); // go get the buffer ComRdTerm(scannerPortNumber,scannerData,SCANNER_MAX_BYTES,SCANNER_EOS); // raise the data flag scannerDataFlag = TRUE; // empty the buffer FlushInQ(scannerPortNumber); }
And here's my use of InstallComCallback():
void InitScannerComm(void) { int notifyCount = SCANNER_MIN_BYTES; int eventChar = SCANNER_EOS; // terminator charactor //int eventMask = LWRS_RXFLAG | LWRS_RECEIVE; // callback event won't happen unless the eventChar is received after notifyCount characters int eventMask = LWRS_RXFLAG; // TODO: the InstallComCallback() function seems to be calling the callback twice each time, even though I get a verified buffer of only N number of bytes int dataBits = SCANNER_DATABITS; int stopBits = SCANNER_STOPBITS; int inputQueueSize = SCANNER_MAX_BYTES; int parity = SCANNER_PARITY; int comportRing = 0; int i; // close port if it's already open: CloseCom(scannerPortNumber); // open COM port one time OpenComConfig(scannerPortNumber,scannerDeviceName,scannerBaudRate,parity,dataBits,stopBits,inputQueueSize,-1); // Make sure Serial buffers are empty FlushInQ(scannerPortNumber); FlushOutQ(scannerPortNumber); // look up how many COM options there are in the control GetNumListItems(tabPage2Handle,TABPANEL2_COMPORT,&comportRing); // set up callback function for COM for (i=1; i<=comportRing; i++) { if (i != scannerPortNumber) // disable all the other callbacks InstallComCallback(i, 0, notifyCount, eventChar, BarcodeScanner, NULL); else // enable the port that's been selected InstallComCallback(i, eventMask, notifyCount, eventChar, BarcodeScanner, NULL); } }
A bit of background... the device sending COM traffic is a barcode scanner from Motorola/Symbol. I have it set up in a virtual COM mode. Using RealTerm in hex display mode, I can confirm that this hardware is set up correctly, i.e., it is sending what it should be (a string in the form: "012345" with a CR at the end).
And I know that the string is correct in that the callback gets called. The puzzling thing is that in Win7 only, the callback gets called twice and then it's done. The second time through, the string is all nulls.
My fix was to eliminate the LWRS_RECEIVE option in the eventMask (i.e., remove the notifyCount threshold). Phew!
Is this a bug?
Solved! Go to Solution.
06-07-2013 10:27 AM
At this point it is hard to tell. We have seen some issues in COM port behavior when comparing between XP and 7. In order for us to verify that it is a bug, we would need to be able to reproduce this on our end. If you could think of a way for us to reproduce this behavior without your hardware (the scanner) then we'd be glad to test this out and file a corrective action request to R&D to look into. We do appreciate your time to post to or forums and making a note of this as this may happen to fellow developers and at least they can look at your workaround for a working solution.
06-07-2013 11:44 AM
Thanks for the reply, Daniel. I suppose if I was ambitious, I would try to replicate this without my hardware, using RealTerm to send from one serial port to the input port of my LabWindows software.
But it's Friday and I'm not feeling ambitious today. Perhaps next week.
06-07-2013 12:59 PM
Friday it is and we definintely know the feeling. If you do feel ambitious in the future I'd be glad to assist. Have a great weekend!
Regards,