Shared Variable Error -1950679023 in LabVIEW 8.6.1

[FRG]

I had this problem also and the patch fixed it OK. My program works and reads the shared varaible.

However, I still am getting a warning after reading the variable. Warning is 180121602. Indicating the read buffer is empty and it is using the last known value.

Is this normal ? I havn't really got my head around how the buffers work. I seem to get this warning even having previously written a new value.

cheers

Frank

NZ

[Hillman]

Hi Frank,

Thanks for the post and I hope your well today.

I am glad you've managed to fix your original error.

This error isn't normal.

This is usually caused by one of two things:

1.  You are reading data from the variable too fast.

2.  You are attempting to read the value before anything has been written to the variable.

When using shared variables, it is always good practice to write a default value to the variable so that it is initialized.  This will help to avoid this error or any others caused by reading data before a value has been written to it.  This is most important when using network-published shared variables.  Single-process shared variables are similar to LabVIEW global variables and generally do not return errors.

I hope this helps,

[FRG]

Hi James,

My setup is (1) a pc running windows xp with only Labview Run Time  and  (2) a  PXI chassis with only Labview RT. Both connected on a LAN.

The shared variables are hosted on the PC.

I did a test. 

Firstly dummy write on PC and reads on PXI to  initialise the variables.

Then a single write to the shared variable (written by exe on the PC) then a single read on the PXI.

The code on the PXI returns the new value of the shared variable but its accompanied with the warning 180121602.

I have a delay on the read varaible node of 200mS. Anything less and the read does not return any value whatsover. So I think the delay is OK.

So my code works but the warning doesn't seem relevant.

kind regards

Frank Greenslade

Christchurch

New Zealand

[Hillman]

Hi Frank,

Good Morning and I hope your well today.

Thanks for the update.

The error code normally means the variable buffer is empty - but if your getting the value you passed in then this warning does seem rather unexpected. 

I just want to check how your setting your variables up,

To properly configure the slave variables, in the Variable category of the Shared Variable Properties window, you should check Enable Aliasing and bind to a PSP URL.  Point the URL to the master variable.  In the Network category, enable Use Buffering and specify the number of elements to buffer.

The slave variables subscribe to the values of the master variables when the slave VI is run.  As the value of the master variable changes, the new value and timestamp are published to each and every slave aliased with PSP.

The slaves will read the timestamp when the master wrote to the variable.

You should enable buffering at least on the slave variables.  If the master writes new values faster than the slave can consume them, the values are buffered in the slave's buffer.

The binding mention above is where the fix for LabVIEW 8.6.1 is required.

Please let me know more about how you've setup your variables,

[FRG]

Hi James,

Thanks for your reply. You have clarified for me the process which is great.

I do have all the aliases and buffers set up correctly as you have advised.

There is one thing however that I am doing which is a bit out of the ordinary. 

The vaiable that I am passing has been typed from a Custom Control. I am passing a table. This is a 2D array of string. Not a normal data type from the list of shared variable types.

In some cases some of the cells in the table may be empty. Perhaps this is  causing the error message.

kind regards

Frank

[RVallieu]

I finally found this post after searching for any information regarding problems with bound shared variables after having issues with bound shared variables in 8.6.1 using a windows PC to communicate with a cRIO unit.

This should be added to the KNOWN ISSUE WITH LABVIEW 8.6.1 page.

Also I would highly recommend adding a link to the Patch Page on the following Knowledge Base article

http://digital.ni.com/public.nsf/allkb/AED9E710A06A6C56862574EF0053DFA1

Since this article is the one that discusses the need to use Shared Variable PSP binding in the first place.  It would have been nice to know after checking that article (to verify I was doing things correctly) that there was a patch needed for 8.6.1.

[Hillman]

Hi Ryan,

Good Morning and I hope your well today.

I have been out of the office for the last few days - so sorry for the late reply.

I agree that this link should be added. This is a small world because I wrote that Knowledgebase you have linked on your post. The article was written before I was aware of the bug in LabVIEW 8.6.1. I will make the alterations and you should see it update soon. 

Thanks for your feedback and best wishes with your applications,

[RVallieu]

Thanks (Kudos given!) for taking point on updating that Knowledge Base article, James.

I realize it was written before this bug was known as I was referencing that article back in 8.5 when setting up cRIO units with Shared Variable communication and using the cRIO with an RT EXE started remotely. 

Message Edited by RVallieu on 03-31-2009 09:22 AM

[Hillman]

Hi Ryan,

I just wanted to mention the change has been now been approved - and it will be pushed live in the coming days, thanks again for your keen eye! 

[BEHajder]

Hi James,

I wonder if there has been any further attention given to the fact, posted earlier by Sarah, that even after updating the development system with the new version of nitaglv.dll, that building and subsequently using an application (executable) installer still requires manual modification of the installed file structure - we need to manually add the new version of nitaglv.dll to the target PC. Is there any way that the new version of nitaglv.dll can be automatically installed? Do we really need to rename the older version with the ".bak" extension, or can that file be deleted?

Thanks - Brian