LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Unexpected effect of the VISA General Timeout setting on Bytes at Port

In short:

Does the VISA General Timeout property affect the (serial) Bytes at port property in any way? It seems to cause the Bytes at Port property to not detect changes in the number of bytes, if the baud rate is low (here 9600) and the total number of bytes i high (around 120 bytes or higher)..

 

The longer version:

Due to experiments with event based serial IO earlier in a projecta serial port (port 4 - the RS485 port on a cFP-2220 to be specific), the initialization of the port included a setting of the VISA General Timeout to a value of 10 ms. Buffer lengths (in and out) is set to 4096 bytes.

 

Now, instead of using events (due to various protocol and performance issues), the Bytes at port property is polled instead, and we run a Read operation on the port only when an incoming byte stream has begun, and then stopped for a given period. This works fine at 115200 for messages of as much as 2000 bytes, with 20 ms wait between each read of the Bytes at Port property, but at 9600 baud we started seeing clipping regardless of how long we wait between each pol if the message is bigger than around 80 bytes.

 

The root cause of this seems to be the remnant 10 ms setting o fthe General VISA IO Timeout during port initialization. If that value is increased to let's say 1000 ms we can successfully detect the end of messages by polling Bytes at Port with delays down to 30 ms.

 

I cannot see why the 10 ms timeout property should come into play though. Unless it affects the inner workings of the Bytes at Port property in some way that causes it to miss incoming data or something (even though again it is not called quicker than once every 30 ms, or even 100-200 ms).

0 Kudos
Message 1 of 4
(2,510 Views)

Having such a short timeout value is like calling someone on the phone and hanging up after half a ring because they did not pick up.  Let the phone ring for a few rings before deciding the person isn't answering - i.e., set the timeout to a second or two at least.

 

[edit] I now remember there was a post where I saw very small timeout value coupled with continuously polling and throwing out timeout errors until no error but I can't remember why this was done - but it seemed reasonable at the time. I wouldn't recommend that strategy in general though. [/edit]

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 2 of 4
(2,490 Views)

To extend on your allegory; in this case you are trying to see when the stream of people to your doorstep has stopped by checking how many is outside your door every 30 seconds. Now someone is calling you and hanging up every 10 seconds, so instead of opening the door to count the number of people every 30 seconds, you run to the phone in between too...Due to this you end up checking the number of people every 50 or 60 seconds instead. But the goal here is just to detect when the flow of people has stopped for *at least 30 seconds*...so you are still fine when you detect that it has in fact stopped for 60 seconds (no new people / messages will be sent until you have given an ACK after that end). That is why it seems counterinutitive...unless the short timeout in fact has more complex effects (giving you poor eye-sight  for example Smiley Wink ).

 

As it turns out, setting the timeout to 1000 ms still left me with a problem. With a Bytes at port poll rate of 30 ms it would still report the same number of bytes on two consecutive runs if  the message got above 160 bytes...To not prematurely detect a stop in the traffic when the message is 5-600 bytes, the Bytes at port function had to be polled as slow as 70 ms. Polling it with 100 ms intervals moved the maximum to above 3000 bytes (so the final solution is to use that, but it does not provide an explanation).

 

To check if the Bytes at port function has a problem reporting data continously I did a test where the number of bytes was polled more frequently, and only assumed end of transmission after X reads without a change...At a poll rate of 10 ms at 9600 baud one might assume that it should see steps of as little as 9 or 10 bytes per read...but the steps varied between 15 and 64 bytes. Does that explain why I seem to read no change at all between two polls with as much as 30-80 ms in between...No. It might mean that Bytes at port is not in fact updated as fast as it is polled, which could be a lead...But it does not explain why I seem to get no change in the number of bytes when the poll rates is as slow as 30-70 ms.. Nor why it is linked to the number of bytes in the message (other of course than the increased possibility of something to happen within a message due to the longer transfer time involved).

0 Kudos
Message 3 of 4
(2,478 Views)
Just a guess here. Have you tried changing VISA from Asynchronous mode to Synchronous mode? I had errors appear in NI trace but not my VIs with Asynchronous mode, changing it cured the unreported errors. Cheers, mcduff
0 Kudos
Message 4 of 4
(2,464 Views)