Limitations of Veristand on Number of channels

[SriVidya]

Hi,

We are using NI Versitand 2011 and LabVIEW 2011 in our project. The NI Veristand currently has support to GE Reflective Memory Card. We are using GE FAUNAC 5565 Reflective memory card in our project. We have more than 1000 reflective memory channels to be communicating with our LabVIEW application on host PC from an RT target. We started using Veristand as a means of communication between RT PXI and Host PC through Reflective memory.

But the native veristand support for reflective memory card is limiting the number of IOs to not more than 50 as it is resulting in performance issues for real time systems. For each of the reflective memory channel in Veristand it would perform the read and write operation instead of performing read/write operation on the entire reflective memory chunk at once. For this reason we have to create our own wrapper in LabVIEW to communicate with veristand and map the channel data to UI controls instead of sending the data through reflective memory. This is again resulting in limitations on the number of channels. If the number is beyond 300 the communication performance is unpredictable and instable.

Please let me know if there is a workaround to have RTPXI communicate with Host PC through Reflective memory and using veristand for more than 1000 channels.

[thumble]

For the 1rst point you'll need to write your own custom device to overcome the performance issue. For the second point there is a change in configuration that may bypass the limit: put the joined xml file in the folder "C:\ProgramData\National Instruments\NI VeriStand 2011" to extend the WCF message size.

[SriVidya]

This did not help me to overcome the instability. Even if I add this xml file to my Veristand 2011 folder I still get the instability and unpredictable performance issue.

[StephenB]

I'm not quite clear what you are doing here... are you upset at the host performance or the RT performance?

Why do you want to interface the host with the RT target over reflective memory instead of just using the default TCP connection exposed over the .NET interface? Typically Reflective Memory is used for its determinism, which a windows host computer does not have... so its a bit odd to pair windows + reflective memory.

If you're concerned with RT performance, I can provide some guidelines. Most of the time you can operate in chunks instead of one at a time, but you have to be very careful how you set it up or you can have very different performance. I copy pasted this from a performance oriented document:

Reflective memory setup for high performance on RT:

1. Dynamic Data in Reflective Memory: Dynamic data is used to map stimulus profiles and log triggers across targets.  This can take 5-20 us per iteration.  If you are not using dynamic data, reduce the dynamic data size to 0.
2. For communicating from NI VeriStand RT systems to NI VeriStand RT systems, use the mapping tool to make cross-target mappings between the different targets in the same system definition. Under the hood, this implicitly uses reflective memory but is done so in a way that is optimized (DMA). To prevent this implicit use from overlapping with any non NI VeriStand traffic on the bus, use the reflective memory network node (under data sharing network) in the system definition to limit the range of addresses the NI systems can use.
3. For communicating from NI VeriStand RT systems to non-NI VeriStand RT systems, use the "export channels" button on the "Data Sharing/Reflective Memory" node for each target to select which channels to place onto the reflective memory bus. Under the hood, these channels will be added to the DMA block write that each NI VeriStand target is using, therefore it is high performance. Make sure to select this for each target. However, you will not know the addresses used until the system definition is compiled. To get this information, select export memory table to file on the reflective memory node (under data sharing network). The non-NI system will have to parse this text file to know what addresses to read.
4. For communication to NI VeriStand RT systems from non-NI VeriStand RT systems, use explicitly defined reflective memory "data channels" under the "Data Sharing/Reflective memory" node in the system definition for each target. Here you define the data type and address of the network the NI VeriStand target will read. You should only configure data channels for each target that needs the data. For example, target 5 may only need 1/10th of all the data from the non-NI system, and target 3 may need some other 1/10. This way the NI VeriStand targets only read what they need to. Under the hood, since NI VeriStand 2011, these addresses are read explicitly one address at a time so reading a lot of addresses will be slow, but reading a few addresses scattered over a large addresses space will be fast.

[joshe]

We have also had the same issue with Ref Mem and using the packaged Veristand custom device.  The built in RM custom device works well between VeriStand systems (PXI to PXI), but if you have an external system that also is on the RM network, using the VeriStand RM Custum Device does decrease performance and increase CPU use.  There is a CAR open for this at NI, but haven't seen any fixes.  We have writen a Custom device that works with the built in RM custom device to add blocks for Read and Write (to increase performance).  This was based off code NI was able to provide (Kyle Thornton), unforturnately I can't post our custom device, but if you contact NI they may give you the original code I think it was called 'RefMem DMA'.

[SriVidya]

Thankyou for replying.

Could someone from NI provide me the Reflective memory custom device ( RefMem DMA) source code that joshe was mentioning in the above post?

Also it would be of great help, if someone can provide the Reflective memory custom device with the Read/Write wrapper(to overcome this limitation of Veristand) as mentioned in the above post.