Typedef sent as values per index or name?

[wrkcrw00]

I have a situation where the name of a single element within a typedef needs to change. It's only the name of the element, nothing else changes. There are two applications connected with an STM server. The typedef once populated with data is sent through STM to a RT running an EXE. The EXE was compiled with the typedef with the old element name. If I update the typedef element name on the sending side, am I required to update the EXE? I.e., my question, is a typedef composed of values linked to a cluster index? Or are values linked to the name of the element? The index didn't change, but the name did. 

[Ben]

Unless there are potential issues, I would just try it out. I would think the issues, if any, would be with the STM but I am admitedly specualting now.

Ben

[wrkcrw00]

Trying it out on a rocket engine test stand is a little problematic. I did just look at the binary output of a cluster and found it to be simply the bytes of the data values in the index order. Leads me to believe the element name is meaningless in the transmission of the cluster, it's only the way it's defined and used within an application that matters. 

[Ben]

Good to be careful with those.

So what you reported combined with the observation that we can wire two different type defs that have exactly the same elements together with only a coercion dot...

Can you test the basic opertion out with the rocket engine?

Ben

[wrkcrw00]

Here's the basic opperation, using 2 clusters of the same makeup but have different names for one of the elements. The last element is "Bob" when the XML string is created. It's unflatted as "Jane" and works just fine. The data string also confirms that the makeup of the transmitted data is just the 3 bytes. There is no information that describes what it is. So, changing the name has no effect...so long as there is a consistent structure on both sides. Not recommended...but in some cases it's easier to do this and fix the typedef later when there is ongoing testing.

[Bob_Schor]

Words to the Wise -- while I can "believe" that opening a TypeDef and changing only the name of an element would not make much difference, be very careful if you do a "delete/recreate" cycle, where you delete the element "Bob" and add back the element "Jane".  Not only do you need to worry about getting the "types" right, but you also need to ensure that you don't disturb the "cluster order".  In particular, if you delete any but the end element and replace it, your new element will become the end element, and unless you reorder the elements in the Cluster, they won't "line up" properly.

Bob Schor

[Ben]

The form of data transfered in LV can be rather robust.

While not directly related to what you are doing I can tell a war story of when I screwed up big time using a type cast.

I was transfering LVOOP data from one place to another using queues. I wanted to make sure the data type coming out fo the queue would adapt asn teh class changed. Silly Ben used a "Preview Queue" and used the data coming out the bottom to define the data type of used by the type cast. The data was transfered from queue to eventually hitting the data logger and then LV crashed because I was casting a LOOP object as an array of LVOOP objects.

It took the big guy to figure that one and tell me what I had done wrong.

Ben

[wrkcrw00]

Yes, the typedef order and control types are very important, especially if one were to try and delete/recreate one of the controls in the cluster. I normally would not ever do this, but a situation arose that only a name had to change. I highly recommend that if you update a typedef, you update any exe's that were compiled with the old typedef also.

[Ben]

Back in LV 6.1 I developed an application that monitoried Classic FieldPoint nodes using VI server and used a Cluster to trasfer the data using Call by Reference invoking an Action Engine running on the FieldPoint units.

After turning it over to the customer I latter learned that he upgraded the PC side to LV 7 while the image on the FP units were stil running the LV 6.1 image and IT WORKED!

So...

As long as the cluster is unchanged and LV has not undergone a revamp of the data storage typography it may just work.

Ben

[drjdpowell]

That's rather a weakness of the LabVIEW XML format.  Including names, but then ignoring them and only going by order, is confusing at best.