JKI-SMO & In-Place Element Structure (loss of reference?)

[Ray.R]

I inherited a project which uses JKI-SMO.  I tried to follow the link to http://jki.net/state-machine-objects/ which resulted in the following page:

The issue is not the missing web page...

The issue is that somehow, the data being pointed to by the reference within an In-Place Element Structure is no longer valid.  The error message 1556 indicates that the reference is invalid.  However, when probing the reference, the numeric value appears to be okay.

The issue first occurred within a Logger function.  After implementing a workaround, the issue migrated to a different VI which uses a different reference for different values also using the In-Place Element Structure.  In other words, the issue is migrating elsewhere and I am sure this is becoming a witch hunt.

I checked the entire code and there are no broken links that would cause the reference to be dropped.  As a matter of fact, the references (at least 3 of them) appear to be okay.  The original author claims having seen similar issues with this or another project and all they needed to to was to remove and replace the In-Place Element Structure which fixed the issue.  The code is full of In-Place Element Structures.  It would be easier to rewrite the entire code than to swap In-Place Element Structures.

Has anyone else seen a strange behavior with error 1556 when using In-Place Element Structure?

[tst]

Well, I don't really have experience with SMOs besides playing with them a little bit, but my guess would be that the reference is automatically cleaned. The most likely option for how this can happen is that the reference was created by a VI hierarchy which has then been unloaded (probably in an dynamically launched process, which SMOs can be).

Seeing the numeric value of the reference in a probe is not an indication that the reference is valid, as that's just a sequence of 32 bits - you could have the value, but if the resource it's pointing to is gone then it doesn't help you.

The easiest way to handle this is to make sure that references are created in a VI in a top level hierarchy which keeps running for the lifetime of the app, but that's a bit of a workaround and requires doing this with each reference.

The other option, which is more complicated, is to manage the creation in another way (for instance, in a dedicated actor which stays alive, or by making sure each reference is created in a place which stays alive).

[Ray.R]

Thanks for the reply. 

It appears that there was corruption in the source code that I received.  Older versions did not have the issue that I was observing and a new receipt of the latest source code appears to be better.  I am waiting for the customer to confirm.  The issue was unlikely related to the SMO.