typedefs update incorrectly

[SeattleSafety]

I am using LabVIEW Real-Time (RT).
I have three typedef'd clusters, two of them contain a nested typedef that refers to the third typedef. These typedefs are called (omitting the *.ctl suffix for brevity):

1 - Local_RT (used to pass data between states of the RT state machine)
2 - RT_to_Host (used as a message structure for TCP messages bound from the RT machine to my host machine)
3 - ChanInfo (used to hold information concerning the RT's DAQ hardware)

Local_RT contains ChanInfo as a nested typedef. Local_RT also contains RT_to_Host as a nested typedef.
Furthermore, RT_to_Host contains ChanInfo as a nested typedef.
There are other controls within the Local_RT and RT_to_Host typedefs.

Here's a little diagram that shows the structure:

-Local_RT
--ChanInfo
--RT_to_Host
---ChanInfo

You may be asking why I have two instances of ChanInfo (since they hold the same information!). Well...
There's a reason why I have two instances of ChanInfo:
I clear the RT_to_Host message between all TCP transmissions to reduce network traffic, so if I had only Local_RT.RT_to_Host.ChanInfo, then my local RT code would lose ChanInfo data that other RT states need (because Local_RT.RT_to_Host.ChanInfo is cleared after every TCP transmission and Local_RT.ChanInfo would not exist). Stated differently, I use Local_RT.ChanInfo to store current (local) information, and when the host wants that information, I populate Local_RT.RT_to_Host.ChanInfo and send it on its way via TCP, then I clear the entire Local_RT.RT_to_Host message in preparation for the next message (which may or may not have the same information for the next transmission).

OK...

I have encountered the following problem:
When I update the RT_to_Host typedef (because, for example, I am adding or deleting information that needs to be communicated between host and RT), some unbundling that should refer to Local_RT.ChanInfo gets incorrectly updated to Local_RT.RT_to_Host.ChanInfo. Furthermore, this seems to not happen to all instances throughout my code (!?).

The result is that my code is still syntactically correct (and I can run the application), but my data is a bit jumbled up and I have to dig through the code manually to replace all of the incorrect typedef/cluster item name updates wherever I have a bundle or unbundle operation.

One main advantage of typedef'ing is that LabVIEW updates everything for you automatically, throughout all of your code base. But this behavior I am seeing kind of defeats that advantage.

The question: what rules are followed when LabVIEW performs typedef updates? When a typedef changes, does it look for the same name, the closest name, the position within the cluster, or something else? I can't seem to find any information about this on the NI web site. If anybody has any input, that would be great.

Thank you in advance...

[Philip_Courtois]

Hi there,

To get straight to the point about the updating of the typedefs: After changing a typedef, you can choose to 'Apply changes' or you can hope that LabVIEW applies the changes for you automatically.

If you change the name of a control within a typedef cluster, the Unbundle By Name functions will be updated to reflect the name change. In case you remove connected controls from the cluster, the text of the terminal in the Unbundle By Name functions will turn black and you will get a broken arrow. This is because the Unbundle By Name function now doesn't know what control to connect to. In case you switch names of similar controls in the array, the Unbundle By Name functions will link to the control with the previous used name.

I have attached an example using the data type you are describing. Let me know if you have further questions.

[Ben]

Hi Philip,

I was also interested in the answer to the question;

"The question: what rules are followed when LabVIEW performs typedef updates? When a typedef changes, does it look for the same name, the closest name, the position within the cluster, or something else?"

Since the data structure that prompted this Q had the same field name used in two different clusters LV is appaerently looking at the text name ONLY of the element and NOT the structure.

If the bottom level cluster was edited and then the "apply changes" was clicked, I am still fuzzy about how that makes things any better.

Please take a look at the attached mod of your example for illustration.

So how does it decide to use

RT_to_Host.Channel Info.Name

instead of

Channel Info.Name

?

I am curious about the rules re: this behaviour because it will help me control how my application reacts to changes.

Still curious,

Ben

BTW:
What version of LV is doing this?
Please post an example that demonstrates this behaviour.

[Philip_Courtois]

Ben,

Can you please describe what behavior you are referring to? It would make my day much easier if you could post a small example that shows what you mean about the update question. My example seems to be updating correctly in every case.

Thanks!

[Ben]

I attached my example of what I thought the original questioner had in mind.

I was not able to observe the problem myself.

I was curious about the rules used in select fileds to bundle or un-bundle when a type is changed, like in my example. It is nice to know what I am putting in jeopardy ahead of time.

I seem to remeber having trouble in an earlier version of LV where my typedefs acted strange. It may have been 6.0, 6.0.1 or maybe it was BV 2.1, not sure. That is why questioned what version was doing this.

Still curious.

Ben

[Ben]

Hi Philip,

Let's see if I can frame the reason for these Q's.

NI builds the race car.

I drive it.

If I switch to radial tires will my lap times increae or decrease?

Like I said here

http://forums.ni.com/ni/board/message?board.id=130&message.id=296&jump=true

sometimes just a quick peak under the hood would let me know that the un-labeled red switch on the dash board is probably for the nitrous system.

Maybe this should be a LV documentaion change or a Dr. VI article perhaps.

Still curious,

Ben

[SeattleSafety]

Sorry for a bit of a delay in responding...things are busy!

I appreciate the comments that everybody has contributed.

I've attached a few VIs/typedefs which set up the original condition that I observed. The only problem is that I do not see errant behavior with these simple example typedefs/VIs, even though I am performing the same tasks that I originally performed on my much larger typdefs in my real project.

When I saw the problem on my project, the equivalent steps that I took were:

1 - Test_NestedTypedefs.vi contains an unbundling of Local_RT.ChanInfo
2 - Open RT_to_Host.ctl and add another control to this cluster (but do not add it to the ChanInfo typedef nested within Local_RT). For example, add Local_RT.Boolean.
3 - Save RT_to_Host.ctl and close it.
4 - Open Test_NestedTypedefs.vi. At this point in my original project, LabVIEW incorrectly updated the original unbundling of Local_RT.ChanInfo to Local_RT.RT_to_Host.ChanInfo. Unfortunately, the simple example attached does not seem to exhibit this same behavior.

So, perhaps my exact actions on my real typedefs were slightly different, or perhaps there is an issue beyond a certain size of typedef?

What would be very helpful, though, is a technical detail of the algorithm that LabVIEW uses to update typedefs. If I had something like that in hand, and when this problem shows up again, I might be able to trace down the problematic steps.

Thanks!

[SeattleSafety]

BTW, this is on LabVIEW 7.1.

[Ben]

Well that rules out my "Old veriosn" theory.

These kind of issue can be hard to track down if they can not be re-created on demand.

What has worked for me may not work for you but here goes anyway.

1) Go into paranoid mode. Save regularly, and check for problems at every step.

2) Save often enough that you can recall the edit sequence.

3) Backup to zips at at high rate.

I had to do this to chase down an issue in LV 6.0.1 that confused shift register that stored WF data types.

I was able to supply a before and after set of VI's and the sequence required to re-create the issue.

NI was then able to track down the failure and had the problem fixed in LV 6.0.2.

I will continue to check this thread because I am still curious.

Ben

[SeattleSafety]

I just wanted to correct some typos on one of my last replies, for future reference and clarity.

On the post stamped 02-11-2005 11:49AM, I said:

"
When I saw the problem on my project, the equivalent steps that I took were:

1 - Test_NestedTypedefs.vi contains an unbundling of Local_RT.ChanInfo
2 - Open RT_to_Host.ctl and add another control to this cluster (but do not add it to the ChanInfo typedef nested within Local_RT). For example, add Local_RT.Boolean.
3 - Save RT_to_Host.ctl and close it.
4 - Open Test_NestedTypedefs.vi. At this point in my original project, LabVIEW incorrectly updated the original unbundling of Local_RT.ChanInfo to Local_RT.RT_to_Host.ChanInfo. Unfortunately, the simple example attached does not seem to exhibit this same behavior.
"

What it SHOULD read is (the corrections are surrounded by 3 asterisks [***]):

"
When I saw the problem on my project, the equivalent steps that I took were:

1 - Test_NestedTypedefs.vi contains an unbundling of Local_RT.ChanInfo
2 - Open RT_to_Host.ctl and add another control to this cluster (but do not add it to the ChanInfo typedef nested within ***RT_to_Host***). For example, add ***RT_to_Host***.Boolean.
3 - Save RT_to_Host.ctl and close it.
4 - Open Test_NestedTypedefs.vi. At this point in my original project, LabVIEW incorrectly updated the original unbundling of Local_RT.ChanInfo to Local_RT.RT_to_Host.ChanInfo. Unfortunately, the simple example attached does not seem to exhibit this same behavior.
"