Com Callback is being disabled by windows system events

[rback]

I am tring to write a com routine that services a blind high speed dump from our tool and I am having a varity of com problems with the built in CVI com library.

Application: I know the file size of the data being transfered. I initiate the dump and the data flows from the tool in 250 byte packets at 230,400 baud (approx 750bytes+ every 100ms). Files being transfered can be any size up to 16M.

First try: I malloced the required memory to hold the file in ram. I used a 100ms timer callback and called GetInQLen to determine the number of bytes to transfer out of the buffer using ComRd. These are direct memory transfers only, all processing is being done after the file transfer. On small files this works Ok.
on large file 3M> I start having problems with lost data.

I Found that GetInQLen returned one value and ComRd would return a different count usualy smaller and at the end of the transfer the total byte count would be smaller then the file size. We have eliminated the tool hardware by adding a post transfer status call that indicates the number of byte transfered. This always matches the file size.

Second: I tried using the CVI Com Callback function set up to trigger on 750 bytes (3 packets from the tool). This would also work on smaller files but not on large files. Here again the total byte count would be less then the total file size. Also if the user initiates another task in the system such as opening the browser, or the screensaver becomes active) the CVI callback would stop, even though data is still being transfered.

Any help or guidance would be Appreciated.

Richard Back
Ultima Labs Inc.
(713) 266-9303

[layosh.b]

Your problem may be the timer. It is not reliable, and if you have large
files, the chance that the computer is too busy to handle your function
increases. If it happens it results in skpping a cycle or two and
unpredicteable data loss.
try assinchronous timers or just use a loop with a ProcessSystemCallback ()
activated time totime to prevent the system to becom tool slugish.

Lajos
"rback" wrote in message
news:50650000000800000023E10000-1079395200000@exchange.ni.com...
> I am tring to write a com routine that services a blind high speed
> dump from our tool and I am having a varity of com problems with the
> built in CVI com library.
>
> Application: I know the file size of the data being transfered. I
> initiate the dump and the data flows from the tool in 250 byte packets
> at 230,400 baud (approx 750bytes+ every 100ms). Files being
> transfered can be any size up to 16M.
>
> First try: I malloced the required memory to hold the file in ram. I
> used a 100ms timer callback and called GetInQLen to determine the
> number of bytes to transfer out of the buffer using ComRd. These are
> direct memory transfers only, all processing is being done after the
> file transfer. On small files this works Ok. on large file 3M> I
> start having problems with lost data.
>
> I Found that GetInQLen returned one value and ComRd would return a
> different count usualy smaller and at the end of the transfer the
> total byte count would be smaller then the file size. We have
> eliminated the tool hardware by adding a post transfer status call
> that indicates the number of byte transfered. This always matches the
> file size.
>
> Second: I tried using the CVI Com Callback function set up to trigger
> on 750 bytes (3 packets from the tool). This would also work on
> smaller files but not on large files. Here again the total byte count
> would be less then the total file size. Also if the user initiates
> another task in the system such as opening the browser, or the
> screensaver becomes active) the CVI callback would stop, even though
> data is still being transfered.
>
> Any help or guidance would be Appreciated.
>
> Richard Back
> Ultima Labs Inc.
> (713) 266-9303