Problem with COM Callback

[Massimiliano Conti]

I am using a COM Callback to receive some data sent by a microcontroller on the serial port. For some seconds everything works well. But After, I don't succeed in interacting with the program anymore (I am not able to click on the buttons and even I cannot move the program window). All of this, while receiving and to correctly elaborating the data. Why ?

P.S.: I don't have any MainCallback in my program
Thanks

[Al_S]

It sounds like you get into a long loop someplace. If you include a call to ProcessSystemEvents in your loop, it will check for other user events like mouse clicks, etc. Without ProcessSystemEvents, no user events will be recognized until you return from a callback.
Start by looking at any loops in the functions called in your callback. Make sure you don't get into an endless loop. If you have long loops, include ProcessSystemEvents().

[Massimiliano Conti]

Thank you for your answer, at first !
Even if there are no very long loop in the COM Callback, I have tried to insert the function that you have suggested in some points. Unfortunately I have not gotten results. I cannot even suspect that the callback is too frequently called, because on the serial port a packet of 6 bytes arrives one time per second . The thing that makes me perplexed is that for some seconds everything works (this time is apparently casual, it is not fixed), then suddendly what I have described above happens

[Al_S]

Are you debugging the application in the CVI environment when this happens? Can you still get to a CVI code or project window and issue a break (by pressing or by clicking on << Running >> on the menu bar and selecting Break Execution)? If you can issue a break, what statement in what function is displayed? Are you sure you're returning from your callback?

[Massimiliano Conti]

Yes, I'm debugging in the CVI environment. When I break this is the displayed statement:

void COM_Callback(int portNo, int eventMask, void *data)
{
unsigned char i,pacchetto[6],after,before;
unsigned int DeltaZCHigh; double valori_input[5];
double valori_out[3];
pacchetto[5]=0;
for (i=0;i<5;i++) pacchetto[5]+=pacchetto[i]=ComRdByte (2); <--- HERE !!
if ((ComRdByte (2))!=pacchetto[5]) tx_err(); DeltaZCHigh=(pacchetto[4]<<8)+pacchetto[3]; DeltaZCHigh=DeltaZCHigh-(10000-DeltaZCHigh);
SetCtrlVal (panelHandle, PANEL_NUMERIC, (DeltaZCHigh*1E-06)); leggi_valori(valori_input);
Calcola_vera(valori_input,valori_out);
visualizza(valori_out);
before=GetInQLen (2);
FlushInQ (2);
after=
GetInQLen (2);
}

At this point, if I proceed step by step, at the end of the callback, it enter again in the com callback, but I think this is right, bacause in the meantime the serial port has received other bytes.
I'm very confused...

[Al_S]

How long does it take you to process one 6-byte packet? Could you be calling your callback back-to-back even at speed?
What does your tx_err() function do? Do you ever call it?
Why do you call FlushInQ? If there are additional bytes in the queue, why not leave them there for next time?
When you single step through your callback, what are your queue lengths in before and after?
After the user interface apparently freezes, can you stop the transmissions and see if the PC catches up and the user interface starts responding again?

[Pierre_63]

Hi,

the problem is that you have to test the event inside the COM callback. If you don't do that you try to read character from the serial port even if there are no character...so the read is bloquing and exit on timeout....and your application have no time to move the panel...and so on.

See the documentation of the InstallComCallback funtion.

[Massimiliano Conti]

I think this isn't the problem, because the event to enter in the COM callback is the arrive of the start byte of the packet, so I know that after I will have a fix number of bytes.

[Al_S]

I think Pierre may have the right idea.
Here's some of the help for InstallComCallback:
"Since the callback is internally called via a window message, the callback can get called even when there are no bytes in the input queue, even though there were some at the time the message was posted. Calling ComRd multiple times in the callback can lead to this kind of issues. For this reason, It is recommended to always check the input queue size before doing anything in the callback."
Look at the example within the help for InstallComCallback.

[Massimiliano Conti]

Ok, now I understand. It makes me think about a problem I had with an interrupt handler in the microcontroller. Unfortunately I'll be able to work on it not before monday. For now, thank you to both you.