Pulling Hair Out - CVI CALLBACK Why am I able to Xmit from Com 3 to Com 59 if CALLBACK is in main but not if isn't?

[PaulSwEng]

Im working on pproject that has NI Chassis with bunch of DAQs and Serial channels:

I have simple code I writen in main ( ) involving two serial com ports and single threaded with exception of CALLBACK to handle rceipts of bytes from one of the com ports.  Basic strip down of code involves com 3 sending "Hello World" to com 59.

Basically code set up does the following:

status = OpenComConfig (3, "", 921600, 0, 8, 1, 512, 512);

status = OpenComConfig (59, "", 921600, 0, 8, 1, 512, 512);

FlushInQ (59);
FlushOutQ (3);

status = InstallComCallback (59, LWRS_RECEIVE, NOTIFYCOUNT, 0, readMessages, NULL);

Then I write :

writeError = ComWrt (3, "Hello, World!", 26);

Call Back written in same main module looks something like this:

void CVICALLBACK readMessages()
{
int bytesRead
char msgBuffer[20];
// Reading data sent to COM59
bytesRead = ComRd (59, msgBuffer, sizeof(msgBuffer));
if (bytesRead < 0) {
printf ("ComRd error!!!, Bytes read = %d \n", bytesRead);
return;
}

I also all trimmings of checking and reporting status and errors.

The code works fine....

Then I cut and paste CALLBACK function in another .c module in a much bigger software project and declare CALLBACK prototype in a gloabal  header.  Everything compiled just fine. I lefteverything else in main.   But when I run, the callback never indicated that it happen and nothing gets printed. 

The only differences in this bigger project there is a more elaborate thread manager managing a pool of threads that are also running. Is it possible that this other thread system affecting my com experiment?

[RobertoBozzolo]

I suppose inconsistencies in the code you posted depend on strippind down actuale lines of code to a simpler aspect just for posting (I'm referring to writing 26 characters to the port and reading 20, wtiting more characters that there are in the message in ComWrt).

What I can think of to address your situation is that the callback gets installed within a thread which is not processing events, so that the callback is never fired, or is busy in a tight loop that does not permit events to be handled.

[ebalci]

I would set the output queue size to -1 in both OpenComConfig calls.

That chages a lot of things especially in such "much bigger software projects" 😉

If you do not set it to -1, then all "writes" are actually made into a FIFO, which is flushed whenever it is convenient for Windows.

If you set it to -1, then ComWrt directly writes to the TX pin of the serial port.

Hope this helps.

[Jattie]

It is not clear from your code snippit, and I've seen this happen a lot in serial comms apps. Modern PC's are a lot faster thn serial hardware, so if you keep on opening and closing com ports and flushing out the buffers, the serial data never gets out.

In CVI you write to the UART and not to the physical port and the windows OS clocks out the buffer. I ran into this issue years ago trying to develop a real time data interception routine between serial devices.

The best way to approach a serial project in seperate threads or using the CVI COM Callbacks is to open the serial ports and leave them open. If you dont want to do that, monitor the output queue length and wait for it to be empty before closing.

I use this very handy PortMon utility that is now part of Microsoft to debug and develop serial comms applications. It helps you track what happens in real time. http://technet.microsoft.com/en-us/sysinternals/bb896644 

[RobertoBozzolo]

Hi Jattie,

the link you posted is not complete: the correct one should be this one.