Shared Variables & LVOOP bug

[luke]

I have not be able to create a (simple) VI to generate the error, but sometimes I have an error 91 or -1967362020 when I try to read a shared variable from inside a LVOOP class method.

I don't think that the bus is in my code because the error 91 description is "The data type of the variant is not compatible with the data type wired to the type input." and I do not use "variant to data", just read from a shared variable. And the error -1967362020 description is "The provided refnum is invalid." and I do not know what it has to do with shared variables.

The erros appear just after the shared variable node.

[LAVA 1.0 Content]

I have not be able to create a (simple) VI to generate the error, but sometimes I have an error 91 or -1967362020 when I try to read a shared variable from inside a LVOOP class method.

I don't think that the bus is in my code because the error 91 description is "The data type of the variant is not compatible with the data type wired to the type input." and I do not use "variant to data", just read from a shared variable. And the error -1967362020 description is "The provided refnum is invalid." and I do not know what it has to do with shared variables.

The erros appear just after the shared variable node.

Just curious, do you store an object or any structure containing an object to the shared variable, read the variable and try to call dynamic method to this object stored in shared variable?

[luke]

Just curious, do you store an object or any structure containing an object to the shared variable, read the variable and try to call dynamic method to this object stored in shared variable?

No, I access a shared variable containing a cluster (of strings and integers) from inside a dynamic method.

I also noticed that labview always asks for saving that type of VIs when I close the project, even if I neither open that VI!!!!

I also tried to store an object in a shared variable, and I had other problems, but I solved them by flattening the object before storing it in the shared variable (not much elegant, but it works). Have you tried to do this?

[PJM_labview]

...

I also noticed that labview always asks for saving that type of VIs when I close the project, even if I neither open that VI!!!!

...

I also noticed that too. I was just opening and closing a LVOOP project (nothing with share variable) and there was a VI that constantly asked to be saved (I was doing nothing on the project just open and close). It last a couple days then it stopped (for no apparent reason).

PJM

[Aristos Queue]

I have not be able to create a (simple) VI to generate the error, but sometimes I have an error 91 or -1967362020 when I try to read a shared variable from inside a LVOOP class method.

There is nothing that I know of that would make a VI that is a member of a LV class interact with shared variables in any way different from any other VI. To the best of my knowledge there is no special functionality anywhere in the shared variables relating to LV classes. If you manage to create a VI that replicates the problem, you should report it as a bug to NI.

I have absolutely no knowledge as to what those error codes mean if they're coming from a shared variable. Nothing LV class related, I'm pretty sure.

If you move the VI outside of the LV class, does the shared variable have the same behavior?

:!: As for the VI that always needs saving... this is a known issue. I'd list a bug report number here but I don't have the database in front of me at this time. My suggestion is that if a VI is a member of an LV class and thinks it needs to save, go ahead and let it save. I know that's not desirable behavior, but not saving it has been shown to lead to corruption over time (the info saved in the VI drifts out of sync with the info in the .lvclass file). This bug will be fixed, I assure you.

[luke]

There is nothing that I know of that would make a VI that is a member of a LV class interact with shared variables in any way different from any other VI. To the best of my knowledge there is no special functionality anywhere in the shared variables relating to LV classes. If you manage to create a VI that replicates the problem, you should report it as a bug to NI.

I have absolutely no knowledge as to what those error codes mean if they're coming from a shared variable. Nothing LV class related, I'm pretty sure.

If you move the VI outside of the LV class, does the shared variable have the same behavior?

:!: As for the VI that always needs saving... this is a known issue. I'd list a bug report number here but I don't have the database in front of me at this time. My suggestion is that if a VI is a member of an LV class and thinks it needs to save, go ahead and let it save. I know that's not desirable behavior, but not saving it has been shown to lead to corruption over time (the info saved in the VI drifts out of sync with the info in the .lvclass file). This bug will be fixed, I assure you.

I made more experiments... You are right: it should be not class-related, but I'm still having the error 91 coming out of a shared-variable-read-node outside classes too. There is a thing that I noticed: the first time that I run my program I usually do not have errors. It can be related to the fact that I use shared variables in VIs started by the VIServer method "Run VI" with the "wait until done" option to FALSE?

One note: I do not use autodeploy because every time I use the "Run VI" method LV re-deploys the library and it takes a long time. I also tried using autodeploy and I've got the same behaviour, but I have the suspect that this behaviour can be related to deployment.

I think that in a couple of days I will pass from :headbang: to