Change notifycount dynamically

[nkgavali]

Dear All,

We are using Labwindows/CVI 9.0 for our GUI development. We are trying to implement Communication protocol with our own hardware on RS-232.

Our code arch is such a that, a timer of 100 ms (async timer) is running and sending commands to the hardware. The hardware is sending reply based on different command. We want to use ComCallBack with event LWRS_RECEIVE. As reply from hardware has of different length so we are setting notifyCount as following,

    -----

    // Timer event  Async Timer of 100ms  
 if (event == EVENT_TIMER_TICK)  

{

    // If echo is enable then NotifyCoun @ Default state else it will only wait for
    // receive frame
    notifyCount = isEchoStatus ? notifyCount : (notifyCount - noOfBytesToSend);
  
    /*  Make sure Serial buffers are empty */
    FlushInQ  (selectedCOMport);
    FlushOutQ (selectedCOMport);
    
    // Install COM callback                                                        //
    InstallComCallback (selectedCOMport, LWRS_RECEIVE, (notifyCount), 0, ComCallback, 0);  <------ Setting NotifyCount
    
    // Send data to COM port
    if(ComWrt (selectedCOMport, message, noOfBytesToSend) == 13)
    {
        MessagePopup("Error", "COM write failed!!!");
    }
    // Process the thread Events
    ProcessSystemEvents ();

}

We found that calling  'InstallComCallback' in the timer causing some delay so that 100ms timing is disturbed. We wanted to keep exact 100ms time between two consecutive packates.

In brief, We want to know that is there any other method through which we can set notifyCount dynamically.

Regards

-- NKG

[nkgavali]

Any suggestions?

-- NKG

[ebalci]

Hi NKG,

Com callbacks are primarily used to avoid polling.

When you do not know when data will arrive to your com port, you either check its status periodically (that is polling) or create a callback (an interrupt) so that you are informed when some data arrives.

However, in your case, you actually know you will get the response right after you send a command.

So instead of waiting for the callback to catch the event, you can simply read the response after you send your command.

ComWrt (selectedCOMport, message, noOfBytesToSend);

ComRd (selectedCOMport, inbuf, notifyCount);

I also would not recommend using message popups inside a 100ms loop, because a popup will stop your loop when displayed.

You also do not need to call ProcessSystemEvents. The async timers run in their own thread and it will process events once you return from your callback.

Do you have any specific reason for using com callbacks?

[nkgavali]

Dear ebalci,

Thanks for the reply. Actually I wanted to implement the serial standard protocol. As per standard, the reply would be received from 25ms to 8.5 sec depends on the reply from hardware. So, it is difficult to do the polling after sending message. Serial ISR is working fine in this case. But at every command sending I've to re-installed the ComCallBack just to change the notifyCount.

I've also checked the fix valued notifyCount and InstallCOMcallback called once at the time of initialisation. In this exp. I found that data packets are sending and receiving in evry 100ms time. But for other commands in which there is different value of notifyCount then data would be lost.

This application obviously is multithreaded. GUI is updated in main thread while async timer and communnication is running in different threads. The commands are transffered to Thread Safe queues from main thread. These commands are taken from TSQs in timer event and send to COM port. This concept is working fine but disturbs the timing.

 Also I would like to know if there is any way to change the notifyCount through WIN32 APIs?

Any futher suggestion?

--- Regards

NKG

[nkgavali]

is there any update/help over this?

-- NKG

[nkgavali]

is there any solution available or there is no way to do this in Labwindows?

Any expert?

-- NKG

[RobertoBozzolo]

In a situation similar to this one I have structured the COM thread so that is always retrieves all characers and appends to a buffer. A global variable set by the operating thread informs the COM thread how many characters to expect: when that many characters are ready in the buffers they are retrieved from it and decoded depending on the expected message structure.

In practice:

1. Operating thread sends a query to the device and loads the 'expectedChars' variables with the desired number of characters
2. COM thread reads bytes as they arrive and appends to the buffer
3. When the expected number of characters are present in the buffer:
1. message is retrieved from he buffer and buffer flushed
2. message is decoded
3. a signal is sent to the operating thread to inform that device has answered and is ready to receive a new message
4. Operating thread prepares the new query and process restarts from 1.

As an alternative, COM thread can simply wait that at least enough characters are present in the queue (GetInQLen); when ready discards the exact amount of bytes from the queue (ComRd) and decode them.

[nkgavali]

Thanks Roberto,

     I'll program this logic and update the results.

--- NKG

[nkgavali]

Dear Roberto and All,

   Thanks for the nice suggestion. I did the changes as suggested by Roberto and found software working very fine. I removed all GUI components from timer thread. GUI is changes strictly into Main Thread. Timer thread did COM communication (sending and receiving into polling mode) and update frame into a queue. The updated from is analysed by the intermidiate thread and put frame into sorted queue. The sorted queue is then transfferd to main thread for GUI update by differed callback.

Thanks and Regards,

NKG.