LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Property Nodes & Labview on RT Target

I've got a 1D array of double data that I need to dynamically put into clusters of various composition. Some of them contain a few controls, some contain many. See photo below for example.

 

We wrote some really nice code using property nodes to dynamically determine the composition of cluster and data types and inserted the appropriate data from the array into the cluster. It would look at the control type, and pull out the appropriate double fields from the array, do any necessary conversions, and then put them into the cluster. However, it was all for naught as we eventually found out that none of that works because you can't use property nodes to read and write values to controls on a RT system.

 

I tried to re-write everything using variants and all kinds of Vis in that palette, but it was too slow for our application and some of those VIs also didn't work on RT system.

 

The cluster is important because it defines the shape of a message that is then send out using some other VIs on the RT target, and the adherence to this structure is pretty strict (i.e. cluster must be exact, even down to array size).

 

The best solution we have now is to use a constant of the cluster and put data into the cluster constant using bundle by name by hand, but this is very time consuming and prone to error (we have over 100 different clusters).

 

We've also considered using a constant in a non-running VI and VI scripting, but not sure if that will work on RT target or not.

 

 

 

To break it down into pseudo code:

1. Pass in generic cluster.

2. Iterate through each element within cluster in order.

3. For each element, determine data type and/or number of values necessary.

4. Remove data from array that is needed for the element, format appropriately, and insert into cluster element.

5. Move on to next cluster element.

6. Repeat until end of cluster.

 

Here is a stripped down example of how were trying to this using property nodes.

 

SampleArray2Cluster.PNG

Download All
0 Kudos
Message 1 of 5
(2,108 Views)

This sounds like a good time to switch those controls to classes. It may wind up being a pain to write handlers for each one, but you'll have much better control over the specific operations you do.

 

If you don't want to rewrite your messaging VI's, you can have your classes convert to a cluster as a final step before sending out the message. If you have over 100 different clusters, I'd suggest a rethink of your architecture, as I would put money on some duplication of features between cluster sets.

 

If you can't switch to classes, you *should* be able to make all of your individual bundle-by-name VI's using VI Scripting. I haven't done it before, but I don't see why you couldn't do what you're doing now by hand with a script to auto-generate a VI with the right class in it, then wire up the appropriate Bundle By Name function.

 

(Disclaimer- I've never used VI Scripting at all ;))

0 Kudos
Message 2 of 5
(2,057 Views)

Do you have any idea if LV classes will run on a RT cRIO running Veristand? I've never done anything with them before but will look into it. This code is specifically for developing a Custom Device for NI Veristand, which has its own quirks and limitations.

 

I cannot edit the messaging VIs. They are automatically generated using some scripting, and made by a 3rd party tool that password protects their block diagrams. The inputs to them must be a cluster.

 

I cannot change the architecture to reduce the number of clusters. I'm sure there is some duplication, but this is a very complex system with lots of varying cluster types (each cluster represents a message structure).

 

My concern with VI Scripting is speed. We have a lot going on already on our RT system, and our current execution rate is roughly every 5 ms it needs parse the array, populate the cluster, and then send a message out (in addition to a bunch of other stuff). Seems like our Custom Device software is just barely keeping up with that timing already.

0 Kudos
Message 3 of 5
(2,054 Views)

VI Scripting is done in the development environment- I don't think it works in RT. Even if it did that's not how you'd want to create things. You'd run the scripting VI's on your development machine to make the 100 or so VI's you need to translate your clusters instead of coding each of them by hand. You can even make groups of them polymorphic so they auto-choose the right one based on which inputs you feed it.

 

AFAIK cRIO handles classes OK, but I haven't actually tried it. Googling it doesn't show anything too scary but I'd double check.

0 Kudos
Message 4 of 5
(2,050 Views)

@BertMcMahan wrote:

VI Scripting is done in the development environment- I don't think it works in RT. Even if it did that's not how you'd want to create things. You'd run the scripting VI's on your development machine to make the 100 or so VI's you need to translate your clusters instead of coding each of them by hand. You can even make groups of them polymorphic so they auto-choose the right one based on which inputs you feed it.


Hmm...interesting. I know we've done some simple VI Scripting in the past. Might look into this to see if it's worth pursuing.

0 Kudos
Message 5 of 5
(2,047 Views)