PDA (Pocke PC) - Serial Write Timeout

[Controlink_Systems]

Hello List,

I am developing serial routines to communicate with external hardware. In many cases, XON/XOFF flow control is used.

I have configured my PDA device to write out a large file. During the transmission, I use my development computer to monitor the transmission. During the transmission, I can send XON/XOFF characters to the PDA. If I send an XOFF, it will "pause" until I send an XON character. It works great unless I wait for more than about 3 seconds. If the PDA is forced to wait for more than 3 seconds, the transmission is terminated with an error. However, if I send an XON character, before the 3 seconds delay, it continues the transmission and no error occurs.

It seems that a 3 second timeout is being enf
orced within the routines but I have not been able to determine if I have control (within the PDA Serial Routines) over the timeout variable. Personally, I would like the timeout to be indefinite unless I want to enforce one.

FYI: Based on industrial experience, for very large files, delays during the transmission of several minutes may be necessary.

TIA,

Guy

[Controlink_Systems]

Hello List,

I modified the PDA Serial Init VI by adding a timeout control. The default was already set to 10 seconds, so I was doubtful that the PDA routines actually use the value since the actual timeout period is about 3 seconds (in every case). I set the value to 2 hours but the routine still terminates after 3 seconds of waiting for the XON character.

It appears that the PDA Serial routines force a 3 second timeout internally and do not use the value specified using the Serial Init VI. This is a serious limitation.

Guy

[GrantM]

Hello,

I apologize for the delay in responding to your post. You are having a timeout issue when using software flow control (XON/XOFF) to transfer data between a PDA and a host computer, right? Are you getting error code 7 when the PDA times out? I was able to duplicate this issue here. This error code is a timeout error and it means that not all bytes have been sent. I spoke with members of the R&D team and they know about the problem. While they were unable to offer a formal solution at this time, they did provide a workaround which I hope works for you.

1. Put a while loop around the serial write VI on the PDA.


2. Continue the while loop until there is no longer an error code 7 (i.e. until all bytes have been sent).

Essentially, this will ignore the repeated timeouts from the serial write VI. You can manually add a timeout mechanism by obtaining the time before the loop and checking it during the loop. However, you mention an infinite timeout is acceptable in which case no additional code is necessary.

I have attached a couple of VIs that implement serial communication using XON/XOFF flow control and that use the above workaround. Please let me know if this solution works for you. If not, can you provide some additional details such as the error code and if the timeout is happening on the PC side or the PDA.

Happy coding,

Grant M.
National Instruments

[Controlink_Systems]

Hello Grant,

Thanks for the reply. I modified my routines, per your PDA attachment, and added a timeout variable within the loop to terminate the session, and alert the user, if a timeout occurs. I also check for a timeout variable of -1 to allow an indefinite timeout period. The workaround is successful!

Since you have access to the R&D Team, I was hoping for an update/workaround concerning another issue I reported on this forum, "PDA (Pocket PC) Serial Read ERROR". It appears that the PDA's port is not being correctly initialized for even parity communications.

Does a workaround exist for this issue?

TIA,

Guy

[GrantM]

Hello Guy,

Thanks for the update. I'm glad the workaround works for you. I have the same access to R&D as other National Instruments applications engineers when a potential problem is discovered. They do know about the even parity issue and are investigating it as well. Unfortunately, at this time, I don't have any information in addition to the workaround you mention (pausing for 25ms between characters).

Happy coding,

Grant M.
National Instruments