How Large Can I Make the Read and Write Queues for NI-CAN? Hardware: Industrial Communications>>CAN
Problem: I want to increase the length of my read and write queues for NI-CAN objects, but I don't know the limits. Solution: Note: NI-CAN version 1.5 fixed some problems related to the limits for read and write queues. This article assumes that you are using NI-CAN 1.5 or higher. Every NI-CAN object uses a read queue (FIFO) to exchange received frames with your application, and a write queue to exchange frames for transmission. The lengths of these queues are specified using the appropriate ncConfig function. The lengths that you pass to ncConfig are specified in frames, not in bytes. The following queue lengths are sufficient for most NI-CAN applications: Network Interface read queue length: 100Unless you are encountering problems, it is recommended that you use the queue lengths specified above, as these lengths will remain within limits for a variety of applications. Increasing queue lengths to the maximum requires an understanding of how these queues are implemented within NI-CAN. The remaining text of this article outlines this implementation. For maximum speed of data transfer, every read and write queue is implemented in the memory that is shared between the Windows NI-CAN driver and the embedded microprocessor on the CAN card. This memory is used for all ports on the CAN card, so if you are using a 2-port card, all read/write queues for both ports (such as CAN0 and CAN1) are allocated from the same pool of memory. Each CAN card (1 or 2 port) has 6600 bytes available for read and write queues. For a given queue, the following formula determines the amount used from available memory: Memory_used = ((Queue_length + 1) * Entry_size) + 30;The 30 bytes are used for a header. Queue_length is the number of frames that you specify using ncConfig. Entry_size is determined by the datatype used with each read/write, as follows: Network Interface read queue: 22 bytesAs you can see from the formula for Memory_used, setting the queue length to zero does not mean that the queue is not allocated. As described in the NI-CAN manuals, a zero-length queue provides most-recent data, and therefore memory is still required. A zero-length queue allocates 30 bytes for a header, plus one entry (Entry_size bytes). This is true even if the object is configured, but not opened by your application (such as the Network Interface when only CAN Objects are used). The following examples help to illustrate how to calculate maximum queue lengths for specific applications. Example 1: Single Network Interface If you only open one Network Interface for reading and writing, you normally set the write queue length to the recommended value of 10, then try to maximize the read queue length. The write queue length of 10 requires: Memory_used = ((10 + 1) * 14) + 30 = 184 bytesThis leaves (6600 - 184) = 6416 bytes for the read queue. 30 bytes will be used for the read queue's header, leaving (6416 - 30) = 6386 bytes. Dividing this number by the Entry_size gives us (6386 / 22) = 290 frames, which means that we can set the read queue length to one less: 289. Example 2: Two Network Interfaces If each Network Interface is on its own CAN card, you can use the same read queue length as in Example 1. But if you are opening both ports on a 2-port CAN card, the read queue length of each Network Interface must be half (144). This is due to the fact that the 6600 bytes of memory is shared among both ports on the CAN card. Example 3: CAN Objects We configure 3 CAN Objects, 2 with communication type Periodic Transmit (transmt data), and 1 with type Receive Periodic Using Remote (receive data). We wish to maximize the queues used for data frames (write queue for transmit, read queue for receive). We do not open the Network Interface in the application. Nevertheless, the Network Interface must still be configured, including the read and write queue. To minimize the memory allocated to the Network Interface, we set its queue lengths to zero. The following lists the Memory_used for unused queues: Network InterfaceThe total Memory_used for these queues is 226 bytes, leaving (6600 - 226) = 6374 for the remaining queues. For simplicity, we divide the remaining memory into 3 parts, one for each CAN Object. This provides (6374 / 3) = 2124 bytes for each queue. First we allocate the read queue for the Receive Periodic CAN Object. 30 bytes will be used for the read queue's header, leaving (2124 - 30) = 2094 bytes. Dividing this number by the Entry_size gives us (2094 / 16) = 130 frames, which means that we can set the read queue length to one less: 129. Next we allocate the write queue for the 2 Periodic Transmit CAN Objects. 30 bytes will be used for the read queue's header, leaving (2124 - 30) = 2094 bytes. Dividing this number by the Entry_size gives us (2094 / 8) = 261 frames, which means that we can set each write queue length to one less: 260. Note that if the CAN Objects are split between both ports of a 2-port card (such as transmit on CAN0, and receive on CAN1), we need to allocate zero-length read and write queues for the extra Network Interface, but the remaining allocations are the same. As you can see, determining optimal queue lengths for CAN Objects is a relatively complex process. For CAN Objects that transmit data, the recommended write queue length of 10 is adequate for most applications. By filling the write queue with frames until full, then waiting and writing again, you can easily transmit large waveforms of data onto the CAN bus. For CAN Objects that receive data, the recommended read queue length of 10 is also adequate for most applications, especially when each frame is arriving periodically. The overall guideline is to use the recommended queue lengths (at the top of this article) unless your application has specific needs, or is encountering read queue overflows. Related Links: Drivers and Updates: Latest NI-CAN driver Product Manuals: Current NI-CAN documentation KnowledgeBase 1YL9E1RM: What Causes Queue Overflow with NI-CAN? Attachments:
Report Date: 06/14/2000 Last Updated: 01/05/2005 Document ID: 1YD93QRM |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
