9 replies to this topic

[mje]

Anyone seen behavior like this before? I've seen stuff like this happen before when mucking about with field names in clusters, but never before just by changing what computer I'm opening a VI on.

Here's the code for a VI when it's opened on my main development machine. Note the unbundle by name primitive is selecting the ER field:


Now here's the same code opened up on my laptop:


Yeah, somehow the unbundle by name prim now selecting the DN field and the corresponding case structure has also mutated its type. Fixing this is dead simple, I just re-select the ER field, but the more important question is why is my source code changing as a function of which computer opens the VI? This scares me...

[Aristos Queue]

If I had to wager, I'd suggest that your VI is saved with a path to the typedef like c:\typedef.ctl. On Machine A, this typedef is found and loaded. On Machine B, this typedef is missing, so LV searches for it, but finds it almost instantaneously so the Find dialog never even pops up at d:\typedef.ctl. The tricky part is that d:\typedef.ctl exists on both machines, so when you open both typedefs, they look exactly the same and you can't figure out why LV thinks there's a difference.


That might not be your problem, but it is a situation that would result in the weirdness you're seeing that I have actually had happen to me in the past.

[mje]

I like your idea, but unfortunately saw no evidence of this. Looking at the paths of files loaded in the project explorer showed no hint of things creeping in from unexpected locations. I also expect that since in this case we had an lvclass file, loading an out of date copy would have caused other issues.

Clearing the object cache or forcing a recompile had not showed any sign of working either. I also verified the issue on a pair of development virtual machines I run, both had the wrong field selected when opening thier copy of the same source code revision.

It seems the only instance where the correct field was selected was on my main development machine. After saving the VI on another machine, committing to SCC, and updating my main development version the problem seems to have vanished. Yay?

[Aristos Queue]

No idea. Just assume LabVIEW was out for a night of heavy drinking and was hungover the next day. Dock its pay and put it back to work.

[Phillip Brooks]

No idea. Just assume LabVIEW was out for a night of heavy drinking and was hungover the next day. Dock its pay and put it back to work.

But NI week isn't until August...

[neil]

I have seen this before, but never in a situation I could recreate. It is a bit scary as luckily in your case the code got broken by the type of the unbundle output changing, but it could have changed to another cluster element with the same type.

[mje]

I have seen this before, but never in a situation I could recreate. It is a bit scary as luckily in your case the code got broken by the type of the unbundle output changing, but it could have changed to another cluster element with the same type.

Indeed, that's what I find scary. Had the type not changed it would have been one hell of a bug to hunt down.

[GregR]

The most likely situation I can think of is that there are typedef updates happening during the load. The node knows it is looking for the name "ER". At some intermediate point in the load, the node sees a version of the cluster that has no field named "ER". It could decide to fall back to the index, which is now named "DN". After all the updates are complete, the cluster now has both the "ER" field and the "DN" field but it now thinks that "DN" is the right name so it stays there.

This is mostly just conjecture, but it is along the lines of what I could imagine our implementation doing. Are all your VIs saved in a state that is consistent with all your typedefs?

[mje]

The most likely situation I can think of is that there are typedef updates happening during the load. The node knows it is looking for the name "ER". At some intermediate point in the load, the node sees a version of the cluster that has no field named "ER". It could decide to fall back to the index, which is now named "DN". After all the updates are complete, the cluster now has both the "ER" field and the "DN" field but it now thinks that "DN" is the right name so it stays there.

That makes sense as I recall the history of the control pretty much followed what you assumed.

Are all your VIs saved in a state that is consistent with all your typedefs?

They should be. The typedef in question is actually the ctl that defines the private members of a class, so I imagine all of the member methods would have been in memory and saved along with the class by the save all operation, and I had not been playing around with the files outside of the LabVIEW context. This might be another instance of the history information carried around by LabVIEW classes causing unintended problems.

For what it's worth, the offending file is attached (without the containing class library). Not sure if you can pull any information out of it. When opened on my desktop computer, the UBN node picks the ER field, but any other system I have tested it on the UBN node picks the DN field. If relevant, I can get you (or anyone at NI) the whole class library if you contact me via PM, I've taken note of the SCC revision number where I captured the problem.

Edit: Scratch that, reverting to the revision I had noted no longer shows the problem. The VI seems to always select the DN field now...argh.

Attached Files

•  Validate Error.vi   26.34K   31 downloads

[Albert Geven]

Hi
This is happening because of objects. There has been a discussion on the NI-site and Steven mentioned not to use typedefs in objects.
I hesitated to do this but when thinking along I accepted that typedefs are not necessary in objects. In fact the object itself is the typedefinition.
I now only use typedefs when interfacing to an object but not in the object definition itself and no problems anymore.
I beleive I had this problem in five different situations and getting it fixed took a lot of editing.
I don't say it is a bug and indeed should be solved but for now I can live with it because indeed a typedef is not necessary in an object.