How to indicate the ComFromFile process ...

[JDG]

Hi,

my application uses the RS232 serial port for download the binary executable code to our hardware. The program was developed in LabWindows/CVI (from 4.0.1 / 5.5.1 / 7.0 / 7.1) and I used the ComFromFile (Port, hFLoad, 0, -1) function with the parameters as described (no count, unspecified termination byte). After invoking this function I was able to indicate the download progress by polling the GetOutQLen () function and set the progress bar on some panel. There was also the possibility to cancel the download by the close button of this panel.

After my migration to LabWindows/CVI 8.1.x the behaviour was changed, the download process indication does'n work (the panel indicate only the end of process) and the cancel of operation also does't work. Tests are revealed the function ComFromFile "hang" the execution of system/user events until the serial transfer is almost finished.

Have anybody some suggestions - maybe I'm using unoptimal approach to indicate the download process (using different thread? how? ...)

Thanks,
George

[ebalci]

George,

How do you exactly use the GetOutQLen function to determine the completion percentage? Is it something like [(current_q_len / max_q_len)*100]?
If it is, I think it is not the best way to do it because the number of bytes in the output queue at any time is indeterminate.
Its length may vary greatly during a serial communication.

I suggest you to use for example [(cumulative_number_of_bytes_written / file_size)*100].

Hope this helps.

[JDG]

Hi, Eren,

thanks for your reply.

1) I used the first way - I follow the function help of GetOutQLen ("Returns the number of characters in the output queue of the specified port."). I have no knowledge how to determine the number of bytes has been sent by ither way.

2) But the main problem now is the "hanging" of the execution during the call of ComFromFile function. In the preceede version of LW/CVI this function was able to accept the file (and sent the bytes out) and immediately continue the program. By using the timer callback and polling the output queue length the progress was indicated in acceptable quality.

So, the core of my question is how to overcame the "hanging" of ComFromFile to be able perform other events.

George

[Mert_A.]

Hi George,

I suspect that the difference in behavior you're seeing is not a change in the function's semantics, but rather due to disabling the output queue (passing -1 in OpenComConfig) in your program.  With the output queue enabled, the file is opened, all the bytes are read into a buffer, and the function returns, while a separate thread transfers those buffered bytes to the driver.  If you are not doing any other output at the time, repeatedly calling GetOutQLen to see how much of that file data is still waiting to be transfered would give you a pretty decent progress measure.  However, if you disable the output queue, the function does not buffer the bytes, but instead passes them directly to the driver.  This means that when the function returns, it has already passed all the file data on to the driver.

The ComFromFile and ComToFile functions are not really designed to support a progress estimate or aborting the transfer.  You could try using an output queue again, even though there are known issues in with crashes in the 8.1.x runtime engine when the output queue is enabled.  Unfortunately the crash happens sometimes when calling FlushOutQ while bytes from the output queue are still being written, and I assume that this is exactly how you implement aborting the file download.  I think it would probably be safe to enable the output queue if you did not allow your user to abort the file transfer.  If the abort ability is important to you, then honestly, I would just do your own simple implementation of ComFromFile.  Because you are just writing the whole file in binary mode, and you don't watch for a termination character, you could just open the file, read a chunk, call ComWrt on that chunk, and repeat until the entire file has been transferred.  This way, you know exactly how many bytes you've written, and you can break the transfer between chunks.  If you want a smooth and responsive progress bar and abort button, you would want to use a fairly small chunk size and be sure to call ProcessSystemEvents in your loop.

Hope this helps.

Mert A.
National Instruments

Message Edited by Mert A. on 07-02-2007 11:05 AM

[JDG]

Hi, Mert,

Thank you for your reply and explanation of some features of GetOutQLen and ComFromFile functions behavoiur. Now it is more clear how to implement my ideas (eg. cancelation of download).
But for my correct understanding - is the basic of "hanging" of the execution of system/user events caused by disabling of output queue?

Thankx,

George

[Mert_A.]

Essentially, yes.  With the queue disabled, functions that write data won't return until all the data has been passed to the serial driver.  Since the functions don't do any event processing internally, so while the function is still writing data, no events (UI or others) will be processed. This will seem, as you put it, like "hanging".  On the other hand, when the output queue is enabled, write functions only transfer the data into an intermediary buffer, and there is a separate thread dedicated to emptying this buffer to the driver.  This means that the function returns before the data has actually been written to the driver, and your main program thread can go back to processing events.  The downside of using the output queue is that it introduces extra delays in the entire writing process, so it can be slower overall, and the delays can result in confusion unless the programmer is conscious of them.

Mert A.
National Instruments