Configuration of "Read Queue Length" does not work

[RyanJ]

I maintain a proprietary CAN monitoring application built upon the NI CAN Driver that was originally created, oh I'd say, 2000 to 2001 timeframe.  The application was originally built upon driver version 1.5 and I have had minimal problems through the years using the latest version of the driver and new releases of Windows (WinNT, 2000, XP).  NI, Thanks a million for this.

But, there is one minor finding:

About Version 2.0 of the driver (I don't remember exactly), The "Read Queue Length" transmitted in the ncConfig method stopped having an impact.  The method call is successful (the response code = 0 and the monitored baud rate is updated), but the read queue length maximum is not enforced the same way as in earlier driver version.

What happens is that when the Network Interface Object is opened and nothing is read from the buffer for a period of time, the "Read Entries Pending" attribute value reported and the available number of unique messages available in the buffer will grow beyond the configured read queue length (max value is 0x407D).

Again, this is not a major issue and a change in the tool was implemented to remove the impact of this change, but continues to occur in version 2.4.

[DirkW]

With NI-CAN 2.1 we introduced a second queue which is running in Host memory directly. This memory is used to buffer incomming messages from the shared memory which represents the Network Interface Queue. With 2.1 the treshold was half the queue and whenever the queue became filled half, the driver initiated a download to the mentioned host queue. Today with 2.5 it is the treshold is 30 % for all plug in boards and USB CAN is fully independed of any queue configuration.
The additional buffer was needed because we experienced more and more high busload situations with our customers and there was no other way to overcome the device shared memory limitations.

DirkW