To be or not to be - Variant Array LV2's in RT

[bbean]

I found the design pattern for a LV RT Local Machine on the website that looks promising (although its a b@#$h to get set up because they don't provide all the links / dependencies on one page). Part of the design pattern uses a Current Value Table (CVT) that facilitates storing, tagging and passing different type data points between the RT target and the host. Essentially you set up all your variables for the application with another NI tool called the Tag Configuration Editor (TCE) and save them to a .tcf file. The RT Target and Host read this file to set everything up. The attached CVT Double shows how the data is stored for single point double tags.

However, the TCE currently doesn't look like it has support for arrays of each data type. Under the hood in the LabVIEW code the Tag Configuration cluster has a flag for array and an array size integer, but tagged arrays aren't implemented anywhere else.

So... I was going to create an current value table for arrays of data. I would like to keep the CVT for arrays generic so that I can store all tags that have an array data type in one shift register (even if they are different sized arrays). I thought of using a shift register with an array of variants. Each variant in the array would hold an array of say doubles as shown in the attached method 1. The thing I'm worried about is memory allocation in RT on the "read" since the Variant to array conversion won't be able to use the replace array and have a preallocated array size.

So the only thing I can think of is to use method 3 and build a specific shift LV2 style VI for EACH tag that has an array data type. This does not seem very flexible though. I would prefer to use Method 2. Any suggestions?

[LAVA 1.0 Content]

bbean,

I wrote the original code for the TCE and CVT and would be glad to help out with any extra information and explanations as well as the TCE source code.

The machine control architecture was created by the Systems Engineering group at NI in conjunction with a customer to solve a particular application. At the same time we wanted to create a LV reference design that we could share with a wider audience and would hopefully help (more than confuse) other LV developers. We know we can't satisfy everyone's needs with our code, which is why (almost) everything is supplied in source to allow you to make changes and additions as need by your application.

So while we tried to keep things as general as possible, some of the things done and not done are due to the specific application we worked on. Lack of support for arrays was one of these. We knew we wanted support for arrays in the long term but the particular application did not require it. So we added support for arrays to the data structure but did not get the chance to implement it in the CVT. As you mentioned supporting arrays of different sizes in one functional global and perform well in RT is far form trivial and we not open that can of worms. In the TCE it will be a very simple change to add support for arrays.

My plan for the TCE is to release an updated version in a few months (after NIWeek) including the source code and to make a lot more of it configurable (list of cRIO modules supported, list of protocols/interfaces supported, etc.) . Ideally I'd like to create a plug-in model where users/developers can create plug-ins for new protocols and interfaces they want to add. The TCE may become a much more generic tag and channel configuration tool for use in applications beyond machine control. We have many request for such tools in applications with channel counts in the 1000's and we would like to supply some generic tool for this purpose.

Please let me know any specific questions you have and how I can help you out.

[viSci]

I was wondering why this architecture is not based on Shared Variables. It seems (with the DSC) it is possible to programmatically create and read Network Shared variables of any type.

More and more it seems that the DSC is being melded into LV itself, so why not just absorb it completely and not have to reinvent the wheel here. The CIE component makes alot of sense but again it would be better if NI would just build this functionality into LVRT/FPGA to be able to read cRIO I/O directly in LVRT. Also was wondering why the CVT does not use Variant attributes to store tags, it seems like it would be faster than indexing through an array.

[LAVA 1.0 Content]

Hello Michael,

QUOTE (sachsm @ Jun 27 2008, 04:32 PM)

I was wondering why this architecture is not based on Shared Variables. It seems (with the DSC) it is possible to programmatically create and read Network Shared variables of any type.

We considered the Shared Variable, but for various reasons we could not use it in this particular implementation and meet the application requirements. Our primary platform for this architecture is LV RT as well as LV Touchpanel so anything we consider has to work in LV Windows/DSC, LV RT and LV Touchpanel.

On the network communication side we were able to achieve better throughput than the networked Shared Variable by using our own simpler protocol based on TCP. This is encapsulated in the STM (Simple TCP Messaging) and CCC (CVT Client Communication) components. This is to be expected, balancing ease of use with performance.

On the controller side one of the requirements we had for local data storage was to have dynamic access by name, i.e. the application can ask for any tag value by passing in a dynamic string. This is not possible using the current variable interface for the Shared Variable. It is possible using DataSocket but at a much lower performance than the CVT implementation we made.

QUOTE

The CIE component makes alot of sense but again it would be better if NI would just build this functionality into LVRT/FPGA to be able to read cRIO I/O directly in LVRT.

This is something we are investigating.

QUOTE

Also was wondering why the CVT does not use Variant attributes to store tags, it seems like it would be faster than indexing through an array.

I'm not sure exactly what implementation you are thinking about here, but I did a simple test and the Variant Attribute version I came up with was a lot slower than accessing a value in an array of a function global. I attached my quick and dirty implementation for reference.

http://lavag.org/old_files/post-3370-1214609959.vi'>Download File:post-3370-1214609959.vi

Our rough benchmark for accessing scalar values using the current CVT implementation is 7-10 microseconds per read on a cRIO-900x controller. This is about the most time we can spend to meet the needs of typical machine control applications, which may contain 100s of tags and have loop rates around 10-100 Hz.

I really apreciate all the feedback and ideas. Please keep them coming.

[Aristos Queue]

QUOTE (LV_FPGA_SE @ Jun 27 2008, 06:42 PM)

I'm not sure exactly what implementation you are thinking about here, but I did a simple test and the Variant Attribute version I came up with was a lot slower than accessing a value in an array of a function global. I attached my quick and dirty implementation for reference.

Most benchmarks have found that the variant attribute (like the one you implemented here) is a fairly efficient lookup table mechanism in LV8.2 and later (it was dog slow before that). I'm surprised if the array version was able to keep up. I can say that the variant attribute model will get a further speed improvement in the next version of LV -- not much, but a bit. You might retry benchmarks when that becomes available.

[David Wisti]

QUOTE (LV_FPGA_SE @ Jun 27 2008, 10:51 AM)

We know we can't satisfy everyone's needs with our code, which is why (almost) everything is supplied in source to allow you to make changes and additions as need by your application.

My plan for the TCE is to release an updated version in a few months (after NIWeek) including the source code and to make a lot more of it configurable (list of cRIO modules supported, list of protocols/interfaces supported, etc.) .

I appreciate NI for releasing the source code with CVT. I'm not very fond of STM (Simple TCP Messaging) and I would love to see this converted to a more open protocol like Modbus TCP. Since I have the source code, I guess I could accomplish this myself.

[LAVA 1.0 Content]

QUOTE (David Wisti @ Jun 28 2008, 09:37 AM)

I'm not very fond of STM (Simple TCP Messaging) and I would love to see this converted to a more open protocol like Modbus TCP. Since I have the source code, I guess I could accomplish this myself.

David,

I would love to hear more about what you don't like about STM. What features/functionality would you like to see? I agree that it is not the right solution for all applications, and is just one of many options you can choose for network communication, ranging from the Shared Variable down to TCP. The original goal of STM was to make TCP just a little easier to use, while keeping data streaming performance as high as possible.

For Modbus please take a look at the http://sine.ni.com/devzone/cda/epd/p/id/4756' target="_blank">Modbus Library for LabVIEW.

[bbean]

QUOTE (Aristos Queue @ Jun 27 2008, 09:30 PM)

Most benchmarks have found that the variant attribute (like the one you implemented here) is a fairly efficient lookup table mechanism in LV8.2 and later (it was dog slow before that). I'm surprised if the array version was able to keep up. I can say that the variant attribute model will get a further speed improvement in the next version of LV -- not much, but a bit. You might retry benchmarks when that becomes available.

I don't have the cRIO target yet so I can't test these things out. Is there any benefit to the False case over the True case in the Write operation of the attached attempt at using variant attributes to store arrays?

[Norm Kirchner]

QUOTE (Aristos Queue @ Jun 27 2008, 08:30 PM)

Most benchmarks have found that the variant attribute (like the one you implemented here) is a fairly efficient lookup table mechanism in LV8.2 and later (it was dog slow before that). I'm surprised if the array version was able to keep up. I can say that the variant attribute model will get a further speed improvement in the next version of LV -- not much, but a bit. You might retry benchmarks when that becomes available.

But will we be able to use it w/ the "In-Place" element structure?!!!!"

[Aristos Queue]

QUOTE (bbean @ Jun 29 2008, 06:48 PM)

Is there any benefit to the False case over the True case in the Write operation of the attached attempt at using variant attributes to store arrays?

No, there's not, but...

QUOTE (Norm Kirchner @ Jun 29 2008, 10:53 PM)

But will we be able to use it w/ the "In-Place" element structure?!!!!"

No. Until this post, I never thought about it. But that would give us another major performance boost for the variant attrib storage mechanism. I'll pass along the request to the owners of that structure. If we did this, then, yes, there would be an advantage to the True case over the False case.

[LAVA 1.0 Content]

QUOTE (LV_FPGA_SE @ Jun 28 2008, 06:56 PM)

... just one of many options you can choose for network communication, ranging from the Shared Variable down to TCP. ...

For Modbus please take a look at the http://sine.ni.com/devzone/cda/epd/p/id/4756' target="_blank">Modbus Library for LabVIEW.

SCRAMNet has performance specs that I am going to try and measure but it looks like even with the fastest counter timer rig NI sells I'll only be able to time bulk transfers.

RE:

The Modbus Library...

I worked with one of those down-loaded from the NI site (somewhere) that did not play well witl parallel process on a cFP unit. I ended up having to sprinkle waits all over the place to get it to share the CPU. Just trying to help,

Ben

[David Wisti]

Sorry if this is bit off-topic...

LV_FPGA_SE,

STM is fine if the host application is Labview. Modbus TCP is widely know protocol in the automation industry. If I have a cRIO that needs to talk to a PLC or HMI, then STM is not going to work. Modbus TCP is also and easy way to get a cRIO to communicate with an OPC server, like Kepware for example.

In all of my LV-RT applications, their is a Modbus TCP server running and any Modbus TCP client can communicate to this device. I have a crude system, much like TCE that is employed to expose the memory map (i.e. CVT) of the Modbus TCP server.

David

QUOTE (LV_FPGA_SE @ Jun 28 2008, 06:56 PM)

David,

I would love to hear more about what you don't like about STM. What features/functionality would you like to see? I agree that it is not the right solution for all applications, and is just one of many options you can choose for network communication, ranging from the Shared Variable down to TCP. The original goal of STM was to make TCP just a little easier to use, while keeping data streaming performance as high as possible.

For Modbus please take a look at the http://sine.ni.com/devzone/cda/epd/p/id/4756' target="_blank">Modbus Library for LabVIEW.

[LAVA 1.0 Content]

QUOTE (Aristos Queue @ Jun 27 2008, 08:30 PM)

Most benchmarks have found that the variant attribute (like the one you implemented here) is a fairly efficient lookup table mechanism in LV8.2 and later (it was dog slow before that). I'm surprised if the array version was able to keep up. I can say that the variant attribute model will get a further speed improvement in the next version of LV -- not much, but a bit. You might retry benchmarks when that becomes available.

I did some more testing comparing the Variant Attribute (VA) method to the CVT. VA and the dynamic interface to the CVT give about the same performance, however, the static and index interface of the CVT provide a lot better performance (10-25x better on cRIO). So if the need for dynamic name-based data access is not required, then using a traditional functional global will give better performance.

Download File:post-3370-1214837047.llb

QUOTE

I worked with one of those down-loaded from the NI site (somewhere) that did not play well witl parallel process on a cFP unit. I ended up having to sprinkle waits all over the place to get it to share the CPU.

QUOTE ( @ Jun 30 2008, 09:01 AM)

STM is fine if the host application is Labview. Modbus TCP is widely know protocol in the automation industry. If I have a cRIO that needs to talk to a PLC or HMI, then STM is not going to work. Modbus TCP is also and easy way to get a cRIO to communicate with an OPC server, like Kepware for example.

In all of my

LV

-RT applications, their is a Modbus TCP server running and any Modbus TCP client can communicate to this device. I have a crude system, much like TCE that is employed to expose the memory map (i.e. CVT) of the Modbus TCP server.

David,

Thank you for the feedback. In the case of cRIO talking to a PLC I assume you will use the Modbus Client VIs on cRIO. I will take a look at the current VI library to address the issues mentioned by Ben.

On the Modbus server side I will take a look at developing a Modbus implementation inside of the remote CVT interface (CVT Client Communication) as an altenrate to STM, though this will be more of a long term project. In the short term it may be easier to update the server soie VIs of the Modbus library and develop a seperate reference design to show the use of the CVT with the server side Modbus implementation to expose the controller data to the network.

Christian