Xmodem calls do not yield to system and UI events

[San Jose Test]

 RE - LabWindows CVI, Xmodem

    X_Modem_Err = OpenComConfig (X_Modem_Com_Port, "", 115200, 0, 8, 1, 2048, 2048);   
    X_Modem_Err = XModemConfig  (X_Modem_Com_Port, 5, 3, 5, packet_size);
    X_Modem_Err = XModemSend    (X_Modem_Com_Port, X_Modem_File_Name);

I have no problem getting the above CVI Xmodem functions called and doing what I want to do...  however, while the functions are in process (i.e. a file is being uploaded and I'm waiting for the function to return), all other CVI GUIs (and possibly all CVI  processes) are "frozen"  .. (however all other non-CVI windows, like internet explorer, network, mail, .. are all still running ....  just CVI is frozen). 

It seems to me that the xmodem functions do not yield at any time to any other running CVI GUI ..  typically, I can include the statement ProcessSystemEvents to get functions to yield to the GUI every now and again...  
 
Here's the description of  ProcessSystemEvents
When a program executes in a callback function or in code that does not call RunUserInterface or GetUserEvent, LabWindows/CVI does not process user interface and system events. Functions that are overly time-consuming can "lock out" user interface and system events. To allow LabWindows/CVI to process events, call ProcessSystemEvents. Take care when using ProcessSystemEvents, because it can allow other callback functions to execute before it completes.

It sure seems as if the NI programmers did not include this function in the xmodem calls ....   I really, really, really, need to be able to run other CVI GUIs while I am uploading a 2 megabit file via xmodem...   this is because the test system has more than one UUT and while I am programming one unit, I need to run tests and do other tasks on other units as well as update the various GUI screens ... I can't tell my client that the entire system is going to be locked out for 20 minutes to program all four of the UUTs "one-at-a-time" ...   that's completely unacceptable.....

Also, there seems to be no way to get a status on how many packets have been sent, how many are yet to be sent... you know, common useful information... 

Short of having to actually write a complete set of xmodem calls, I'm open to any suggestions...... 

[Mert_A.]

The CVI XModem functions are very simple functions. Send and receive are both single, "atomic," function calls which do not return until the entire file has been sent/received. As you have discovered, they also do not do any event processing. If you are going to be sending large files and want to have an interactive UI going at the same time, I would strongly suggest using a separate thread. This is generally the approach to take whenever you want to do any sort of time consuming task and keep a responsive UI. The easiest way to do this is to use the thread pool functions in the Utility library (i.e. CmtScheduleThreadPoolFunction). Instead of directly setting up your COM and initiating the transfer, schedule a separate function to do that stuff in another thread. Let me know if you have questions.

Mert A.
National Instruments

[Jervin Justin]

Hi San Jose,

I sent you an email regarding this as well, but I thought I'd post here in case other people had a similar question.

Pretty much the same thing as Mert said,

From what you describe, it really sounds like all that's happening is the UI doesn't respond because the XModem function calls are blocking calls, ie they run synchronously, and don't get to the next line of code until it finishes execution.

Using a ProcessSystemEvents would work except for the fact that you don't actually get to the ProcessSystemEvents function call because the code is waiting for the XModem call to finish execution.

What you would probably want to do in this situation is run the XModem functions in a separate thread. That way, your UI and XModem code run 'simultaneously' on separate threads.

Spawning off separate threads is made fairly easy in CVI through the Multithreading class in the Utility Library. There are also several examples available in the CVI Example Finder. To get to these:
Click Help»Find Examples...»Optimizing Applications»Multithreading.

Here are a couple of good resources as well:
Developer Zone Tutorial: Multithreading in LabWindows/CVI
http://zone.ni.com/devzone/cda/tut/p/id/3663

Developer Zone Tutorial: Building Multithreading Applications with LabWindows/CVI
http://zone.ni.com/devzone/cda/tut/p/id/3066

Developer Zone Tutorial: Easy Multithreading Programming in LabWindows/CVI
http://zone.ni.com/devzone/cda/tut/p/id/5153

Hope this helps!

[San Jose Test]

Hello Jervin,

So... how about someone at NI update the Xmodem functions so that after every few packets the function would yield to system processes (i.e. include the ProcessSystemEvents call in the Xmodem function) ....   this would make a lot more sense to me as to spawn threads is just treating the symptom of the problem and not the root...  we buy CVI because it is supposed to make things easier for us and our clients, not harder and more complex ...

I do appreciate your answer, but it seems that every time I have a problem with CVI, it boils back to some very obvious issue within the CVI library that no one at NI wants to actually go back and fix (the root cause) as opposed to me and my team having to do more work on our end .....   we've already paid for what is supposed to be a developer suite and support for the same... and not to diminish your quick response or your knowledge of CVI (which is highly appreciated),  but we only seem to get recommendations that say we (our company in San Jose) need to do more work to resolve the issue and never that NI will resolve the issue and hand us a corrected library function..... 

In fact, if you actually handed me the source code for the functions, I could resolve the issue in about 10 minutes... not in days and trials of threaded functions we have never implemented...

So, I guess I'll just let my support subscriptions lapse.... and rather than me having to spend hours and hours learning how to do something I don't want to do (i.e. threading with CVI) I'll just go out and buy a third party DLL that actually works and that comes with simple, well documented, and easy to understand instructions...  Of course this does not make me happy at all, but it's sure more cost effective than having to re-train myself and my engineers every time we find a problem in CVI....  (hint... I've used LabView and CVI since inception, I make very, very (and I mean really) complex software solutions, and never once have I ever needed to do multi-threading...   there is something to be said for simplicity and well planned code  ....

BTW... I already looked at the multi-threading examples you suggested ...  and as I mentioned I'm not a "new-bee" to programming (I hold six different engineering degrees - one of which is in computer science and I've 20+ years of solid engineering experience),   however, the NI examples are seldom clear, seldom concise, marginally documented, and they do not convey any amount of simplicity as far as I can tell ......

In short, I, a well trained and well informed user of CVI for many years, spent about 2 hours looking at the threaded examples last night and I still have no idea how to implement it for my intended use....   (although I have to say the example with the number guessing game sure looks pretty neat)...

Where do we go from here?   I am sorry to make a one-man-rant....  I'm just continually frustrated by these issues and really hate to hear that I have to do more work for an obvious problem with a CVI library....

Many Regards in frustration  😉

[Mert_A.]

I do understand your position, but there are good reasons why we often can't make functional changes to existing features. Any change we make to an existing library function can potentially affect the behavior of all the existing CVI programs out there today. I also disagree that the absence of event processing inside the XModem functions is an "obvious problem."  In this case (as well as other time-sensitive operations), processing events could very easily jeopardize the successful completion of the file transfer. Imagine that someone's working, deployed application now suddenly can't complete a file transfer because one of their event callbacks is suddenly being processed in the middle of an XModem transfer. Their callback interrupts the communication for a few seconds, and so it times out. Sometimes we do make subtle implementation changes -- or even just bug fixes -- that end up breaking existing applications, but that's something we try very hard to avoid.

CVI's multithreading libraries make it very easy to execute code in a separate thread. Multithreading is a very valuable tool for all programmers, from newbies to veterans. Below is a little example of how you would change your existing code to utilize a second thread.

int CVICALLBACK SendFileThreadFunc(void *functionData)
{
    // For simplicity, no error handling is shown
    OpenComConfig (X_Modem_Com_Port, "", 115200, 0, 8, 1, 2048, 2048);   
    XModemConfig  (X_Modem_Com_Port, 5, 3, 5, packet_size);
    XModemSend    (X_Modem_Com_Port, X_Modem_File_Name);
    return 0;
}

// Put the following code where you previously were directly calling the XModem functions.
    ...
    CmtScheduleThreadPoolFunction(DEFAULT_THREAD_POOL_HANDLE, SendFileThreadFunc, 0, &threadFuncID);
    CmtWaitForThreadPoolFunctionCompletion(DEFAULT_THREAD_POOL_HANDLE,
        threadFuncID, OPT_TP_PROCESS_EVENTS_WHILE_WAIITING);
    ...

If there's any other way we can try to help, please let us know.

Mert A.
National Instruments


Message Edited by Mert A. on 05-29-2008 07:43 PM

[San Jose Test]

I do appreciate the feedback and the information. I'll be sure to give your suggested implementation a go...    what you have posted is exactly the kind of example I would want and need to see... simple and concise ... for simple minded engineers like myself 😉     

And now, since this can-o-worms is open, I suppose I'll have to eventually satisfy my curiosity and play with the thread functions at some point in time (drat) ...    it's just that this is a terrible efficiency buster when we find these totally unexpected issues....  

Cheers !

[San Jose Test]

Please ignore this post, my son (a budding 3 year old Engineer) was playing with my keyboard !

Message Edited by San Jose Test Engineering on 05-29-2008 09:45 PM

Message Edited by San Jose Test Engineering on 05-29-2008 09:47 PM

[San Jose Test]

Please ignore this post, my son (a budding 3 year old Engineer) was playing with my keyboard !

Message Edited by San Jose Test Engineering on 05-29-2008 09:47 PM

[San Jose Test]

Please ignore this post, my son (a budding 3 year old Engineer) was playing with my keyboard !

Message Edited by San Jose Test Engineering on 05-29-2008 09:48 PM

[San Jose Test]

Need to make a correction in one of my above posts ---

BTW... I already looked at the multi-threading examples you suggested ... 

Actually, I did not at the time of the original post... ....  I had actually looked at the examples that came with the CVi developer and those examples were not easy to follow ... 

However, I found one of the links very useful ......  http://zone.ni.com/devzone/cda/tut/p/id/3663#toc2

The other links, not so much 😉 

...Cheers...

Message Edited by San Jose Test Engineering on 05-29-2008 09:45 PM