LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Shared Variables Errors, Custom, Error 91

I seem to be having a unique problem with Network Published, Custom Data, Shared Variables (SV).  I say it is unique because I am not finding any information and most issue seem to be associated with older versions of LabVIEW.  I am using LabVIEW 8.2.1, using network published but for now both applications are running on the same PC (no network cable).  I am getting random, “Error 91 occurred at Variant to Data”.  Stop the program and restart and everything is OK sometime.

 

I have run the program with the Variable Manager open and it is reporting no errors.  I have tired Refresh, Remove All Processed, and rebooting my PC.  This seems to fix the problem for awhile then it comes back.  I am not using data binding to controls but polling the variables and read / writing them through out the program.  The custom data type includes clusters with a few elements to 20 elements of mixed data types.  We have changed the custom data type several times during the program development.

 

Even more disturbing I have witnessed using debug mode while updating one SV seeing it changing the value of a different SV.   Are my SVs corrupt, data types too big for custom, polling too often, misusing SVs?  Should I rebuild them, make them smaller, use front panel binding?  I am looking for some suggestions otherwise going to ripe them out of the code and starting over ;(

 

Disappointed but have hope it can be resolved,

 

Thanks!

 

Matt

Matt Fitzsimons
NI Alliance Member
LabVIEW Champion
NI Certified LabVIEW Architect
LabVIEW, LV-RT, Vision, DAQ, Motion, and FPGA
0 Kudos
Message 1 of 10
(4,940 Views)

All,

I am going to try a new project and rebuild the custum data type Shared Variables.  Any ideas on what is causing the issue would be appreciated!  I am using LV 8.2.1.

Matt

Matt Fitzsimons
NI Alliance Member
LabVIEW Champion
NI Certified LabVIEW Architect
LabVIEW, LV-RT, Vision, DAQ, Motion, and FPGA
0 Kudos
Message 2 of 10
(4,904 Views)
Where is the actual variant to data being used?  Have you tracked down exactly where the error originates from, and does this code get executed during periods of it working, such as after a reboot?

Do you have any anti-virus software or firewalls that could be blocking communication?  While you are not using a network cable, network-published shared variables are still using network protocols.  Here's a KB that reviews setting up Windows Firewall for network communication:

http://digital.ni.com/public.nsf/websearch/0D7B86F4B4D19A5E86256F9A006EECB1?OpenDocument

Trey B
Applications Engineering
National Instruments
0 Kudos
Message 3 of 10
(4,884 Views)

Trey,

The variant error is caused by the shared variable engine trying to decode the custom data type (AKA Cluster).  The error originates from the SV call to read variable (see images attached in first post).  Yes, works sometimes and other times it bombs out with an error.  I will look over the attached link to network document.

Thanks!

Matt

Matthew Fitzsimons

Certified LabVIEW Architect
LabVIEW 6.1 ... 2013, LVOOP, GOOP, TestStand, DAQ, and Vison
0 Kudos
Message 4 of 10
(4,883 Views)
It looks like Error 91 in this case is a known issue.  The internal ID for this is 4A0E7FFK.

It only seems to give this error when you read before you write to the shared variable.  Your code likely is reading before writing on occasion, causing this to happen sporadically (if you experience race condition symptoms later, this would be a starting place).

The work around is to have an initialization phase where you write a dummy value to the shared variable at the beginning.

Trey B
Applications Engineering
National Instruments
0 Kudos
Message 5 of 10
(4,864 Views)

Trey,

Thanks for the information!

Matt

Matt Fitzsimons
NI Alliance Member
LabVIEW Champion
NI Certified LabVIEW Architect
LabVIEW, LV-RT, Vision, DAQ, Motion, and FPGA
0 Kudos
Message 6 of 10
(4,862 Views)
Hi,
 
I am have the same problem, using Labview 8.50 on a Win2000pro local PC,testing local. (seen attachment).
Errors in this examples always returns an error 1 or 91 ,depending on wether you connect the error input or not.
 
In my application, which is more complicated, the error does not return when running as sub-vi, but does return an error running the sub-vi in a main vi.
At first I tried several delay's on several locations but this did not help.
Strange story.
Do we have to do some special property-setting for the vi?
 
kind regards,
 
Frank
 
0 Kudos
Message 7 of 10
(4,797 Views)

You need to initialize all variable (write a vale to all of them) before using them.  That was tech support's answer tot he issue.  In our application we ended up removing the Shared Variables.

Matt

Matthew Fitzsimons

Certified LabVIEW Architect
LabVIEW 6.1 ... 2013, LVOOP, GOOP, TestStand, DAQ, and Vison
0 Kudos
Message 8 of 10
(4,785 Views)

In my previous example I used an array of strings to the variant, which causes error 1 or or 91 when reading the variable, because property setting "array of strings" was not there in Labview 8.2.(I can't remember).

Variants probably cannot handle "array of string" very well ?

Setting the shared variable property  to "array of strings" and not using the " to and from variant" option, solved my problem.

Frank

 

 

 

0 Kudos
Message 9 of 10
(4,771 Views)

@Engelenfve wrote:
Hi,
 
I am have the same problem, using Labview 8.50 on a Win2000pro local PC,testing local. (seen attachment).
Errors in this examples always returns an error 1 or 91 ,depending on wether you connect the error input or not.
 
In my application, which is more complicated, the error does not return when running as sub-vi, but does return an error running the sub-vi in a main vi.
At first I tried several delay's on several locations but this did not help.
Strange story.
Do we have to do some special property-setting for the vi?
 
kind regards,
 
Frank
 


Looks like a bug.  I was able to run the attached VI (with a project that has the shared variable) in 8.21, but not 8.5.  This was reported to R&D (# 4E3E35Z3) for further investigation.  It looks like you've got a work around in the mean time.
 
Trey B | Applications Engineering | National Instruments

Message Edited by Trey B on 10-04-2007 03:26 PM

0 Kudos
Message 10 of 10
(4,752 Views)