Bizarre reference behaviour - any ideas?

[Riggy]

Hi all,
I am using references to manipulate caller front panel controls within subvis directly, and today experienced something odd.

On my calling vi front panel, I have a cluster of time stamp indicators based on a type-defined control. I take a reference to this cluster and pass it to a terminal of a subvi. Within the subvi, I take this control refnum and use the Property Node to extract the Clusters[] property, which is an array of references to each of the time stamp elements of the cluster. This array of references is passed through a for loop to manipulate each one individually. See the attachment for the subvi and a copy of the type defined cluster of time stamps.

All this has worked fine, until about an hour ago when suddenly the wire from my calling vi reference to the terminal of the subvi icon became invalid. Hovering the mouse over the broken wire and inspecting Help showed the error "wire: class conflict". I have no idea why this error occurred as I had altered neither the type def nor the subvi. Playing around for a while, I eventually do the following, which seems to (oddly) recover the wire class conflict issue:
1) In the subvi front panel, right click the control refnum, and change "Select CTRL type > Cluster" to "Select CTRL type > Control".
    This turns the subvi into a non-executable, but resolves the wire class conflict error in the calling vi.
2) In the subvi again, reverse the first action by changing "Select CTRL type > Control" back to "Select CTRL type > Cluster".
    This of course returns the subvi to executable, but, oddly, the calling vi wire class conflict error remains resolved!?

This is bizarre, because the subvi is now exactly as it was before the class conflict error. In fact, everything is as it was before the error, and all I did was switch some property value to a different value and back again. I have no idea why this worked, so perhaps someone can explain to me what on earth happened? I can find no information in the help regarding this "Select CTRL type" to know what this means.

Thanks for reading this, I hope someone has a clue about this odd behaviour...

Riggy.
I am using LV8.0, on Win2000Pro.

[BeejalS]

Hi Riggy

I tried to replicate the behavior that you saw but have not been successful. It appears as though something may have been corrupted and you fixed it by resetting the CTRL type. If you do see the behavior again and can find a method of replicating it please post back on this forum and I will investigate it further.

Best Regards

[Riggy]

Hi Beejal, Thanks for posting.
I have only once since had a recurrence of this peculiarity, and this time it was with a different type defined control (but very similar in nature - a cluster of digitals). That occured in the same day as my original post, and I've not had a recurrence since. Maybe it was a gremlin?

If it happens again, I'll post back!

Many thanks, Riggy.

[Ray.R]

I have seen such strange behaviour while debugging someone's code.

The person was using Local Variables & Global Variables to pass values.  Locals within each & every VI and Globals to pass the refernce values amongst different VIs. 

This is a long shot... but are you using any Global or Local Variables that holds a reference value?

What was happening is that the sw was reading and invalid reference value from the Global..

This may not be related, but unless we see you entire code, it would be difficult to suggest anything.

RayR

[Riggy]

Hi RayR,

Nope, no local or global variables. Just type defined cluster controls.
I'd like to include my code, but it's proprietry. Maybe I can create a slimmed down version, but that may not exhibit the actual problem.

Riggy


Message Edited by Riggy on 05-08-2008 03:38 PM

[Ray.R]

As I mentionned, it was a longshot 🙂

Yeah... those Gremlins can be quite troublesome.. 😄

[pincpanter]

---

@Riggy wrote:
This is bizarre, because the subvi is now exactly as it was before the class conflict error. In fact, everything is as it was before the error, and all I did was switch some property value to a different value and back again. I

---

I don't agree with this point of view. I think that when you change that property value, LV actively updates some internal information (essentially the complete type descriptor of the control whose reference is connected to the input terminal), so it's possible that an information that was corrupted for some reason was eventually restored to the right value by repeating the control ref - CTRL type association.
It remains to explain why the info got corrupted, of course.

[Riggy]

Hi Paolo,

You misunderstood me. When I said "everything was as it was before the error", I meant the final state was observedly identical to the original state. Clearly, throwing the boolean from one value to another value necessitated a change of internal conditions, causing the conflict error to clear. I do agree that it certainly remains to explain why the corruption occured in the first place.

I've failed to get the error conflict to recur. Without this ability it is impossible for anyone to diagnose the fault Therefore, I suspect this issue will remain open.

Riggy

[Ben]

Until you have become bored with making backups, try doing backups regularly in an attempt to have a "before and after" set that included the code before the incident and then after. If you can recreate the bad results from the "before" then contact NI SUpport and let them see what is happening.

This issue sounds a lot like a bug Mike Porter is trying to get a CAR on but we have run into contention with support re: "is it a bug".

Ben

[Riggy]

Thanks Ben, that's excellent advice. I tend never to use backup though, only maybe once at the end of each day if I'm in the mood. A bad philosophy, as one day I'm sure I'll fall foul of a power failure or some other fault that manages to corrupt my entire library set

Thanks,

Riggy