Shared Variables Issues

[Dave_Thomson]

Note: (Will Denman - National Instruments) 

Final Update:  4/29/09:   The shared variable team will not be able to join us for the next Alarm meeting so we will be holding this conference call with R/D on Thursday, May 7th at 5:00 PM.   I have scheduled a conference call for this meeting and you can join the call at CONFERENCE INFORMATION:   phone number 877 326 2337 or 303 928 3232 and enter ID 1970260.  Please email me at will.denman@ni.com to be added as an attendee to the internet presentation.  Thanks!

Second Post:  4/20/09   Dave Thompson has suggested using some time during our next Alarm meeting to have a conference call with R/D.  I will be working on these details and will let you all know if this will work for the R/D team. 

First Post:  4/10/09 or so:  Hello Everyone - I have talked with the Shared Varialble R/D team and they are available for an evening conference call to address each of the questions posted in this document.  I have scheduled this meeting on Thursday, May 7th at 5:00 PM and I will post information about the conference call soon.  We will all be able to join the call remotely.

The purpose of this document is to list issues that ALARM members have with Shared Variables.  These issues can be bugs, misunderstandings, wish-list items, functionality questions, etc.  These issues will form the basis of a continued discussion of Shared Variables with NI engineers, based on the presentation given on March 19th.

ALARM members are encouraged to edit this document so as to add their own issues to this list.  Please do not delete or edit other people's content.  Please mark you content with your name.

A follow up discussion will be arranged with NI to discuss these issues.  Documenting them here ahead of time will facilitate and optimize that discussion.

Cheers,

   Dave Thomson

Issue 1 - David Thomson - There is no way to search for shared variables.  (I love NI.  You guys are brilliant.  But frankly, this is incredible.  It simply astounds me that Shared Variables would be released without a Search feature being implemented.  SV's are basically globals, right?  You KNOW what the problem with globals is - race conditions.  How can one ever hope to debug those when you can't find where the heck all the SV are?)  (And yes, I'm aware of the ugly kludge of deleting the varibable so as to search for the resulting errors.)

Black eye on the variable.  Well, needed other features.  In 09, part of that feature is added.  Not in traditional ctl-f.  Some right click options on the node in project and the variable nodes themselves.  Will point to all VI's that have the SV, but not the node itself.  Feature is in the beta.  Choice between that and nothing.  David:  "Something is better than nothing"  NI still trying to envision the full search.  Battle of the resources.  NI recognizes this is important. 

Issue 2 - David Thomson - SV's cannot be type-def'ed.  Make a SV with a custom data type.  Update the data type type-def.  The SV now breaks the code...  Probably has to do with propagating the type-def to all the possible receivers across the network...

Same question asked by Steve.  NI trying to hash out plans for working on down the road.  NI wants to work on it.  Need full relationship with the type-def linker.  The plan is 2010, not 09.  David glad to see it's on the roadmap.  NI does not want to do it half-baked

Issue 3 - David Thomson - The first time a SV is read, it returns meaningless default data and sets the connection.  http://digital.ni.com/public.nsf/allkb/7DBC2C3E95AFD85C86257442005CF74C  Whoa!  I should hope we could do better than that.  Also, I don't understand what is meant by "relative to the target" on the dev zone article.

CAR has been assigned.  Dev zone article needed updating, error code was not accurate.  Error should be neg.  Has improved in 8.6.  Hopefully in 09 only return when no value really exists. 

To avoid, show timeouts, can block on the value.  Right click on terminal to set a timeout and then use the boolean "timeout?" to act accordingly. 

Warning will happen when no value has been writtenm, or when there is a connection time lag (first read when hit run button and the vi will try to open connection, but by time get to node, might not have connected in time)

For 2009 will have programatice API to talk to variables other than Data Socket, still an Open, Read, Write, Close.  DS has DS specific stuff.  NI will build API that will evolve that will do all SVE stuff.  Initial release in 09 will not have all features (logging and alarming) but is a #1 priority.  Nancy:  "Very Nice!!!"

There is a TAG API on the NI Labs.  The user can type in url of lib in project and it will open reference to all shared variables in the lib and the user can read and write all properties and the values.  (ni.com/labs)  Called the LV DSC Module Tag API. 

Issue 4 - David Thomson - I created an app on my desktop which deployed SV's to the desktop and communicated with the RT on a cRIO.  Worked fine.  Took the code to the customer, copied the code to their laptop, didn't work.  Tried deploying SV's to the RT as well as to the Windows host.  No difference.  (Details:  I wrote three different RT apps, then loaded them all onto the RT memory.  The host app connects to the RT and starts one of the apps (selected by a config file) that is already on the RT.  The app starts, but the SV's never connect.  To resolve this, I gave up on precompiling and loading the RT apps and I have the user start the RT app from the host every time.  Then the SV's work.  But this is not acceptable for fully autonomous systems.)

Also issue #15.  Similar to issue #23.  The problem is the step of deployment and the step of run-time variable use.  Deployment sends configuration to where the variable is.  But is deploymen is not done, the RT app will have problems.  Need a self contained app that will deploy it's own variables.  Will really solve in 2010.  In short term, there is a web-downloadable RT system replication VI (and in 09).  Will go to live RT target and will know what to look for on the system.  Will take along all the right varibles and settings.  That is one approach that works for RT.  In 09 can include libraries and variable to deploy when the EXE executes on Windows (not RT).  When build the EXE, when useing SV libraries, will automatically pull them in.   On RT and manually include lib.

WRT David's issues:  Watch the CPU usage and memory usage.  If they are deployed and windows says they are deployed then it sounds like a CPU usage issue.

Issue 5 - David Thomson - Totally bizzarro - probably impossible to duplicate.  Third party spectroscopy software uses a key file based on NIC address.  So LV has to init that device with a particular NIC enabled.  But due to the local network environoment, we need to run with that NIC off and another NIC on.  However, depending on which NIC is on, we get different SV behavior.  In one case, all SV's work.  In another case, all (about 3 dozen) but two SV's work.  Those two just never get updated values.  The workaround is to very carefully sequence which NIC is on when as the system comes up.

Need to work with support team to try to reproduce.  David:  "how chose NIC and how connect seems to have effect".  NI says try to restart the service. 

Issue 6 - David Thomson - Probably impossible to duplicate, but I swear it was real.  I made a new SV of an array of Booleans.  I initialized it to 4 Falses in the host program.  The RT program reads them and sets four FPGA relays appropriately.  Probing the RT program showed that it had an array of 4 Falses.  Then in the Host, to change one, I read the SV and insert a new value into the array of 4, then write the resulting new array back to the SV.  (The SV serves as my memory of the relay states.)  When this happens, the Read in the host gets an empty array.  The insert does nothing, resulting in an empty array, and the Write from the Host then sends an empty array to the RT.  The RT sees that empty array and the Index function pulls out False for every value.  Turns all the relays off.  Can't turn them on.  It appears that RT can read it, host can write it, but host can't read it.  To fix this, I had to delete the SV and create a new one.  Different name but exactly the same programming.  Then it worked!

NI can't really comment without getting hands on it.  Make sure watching the error terminals.  Make sure wire the error cluster, data will be the default for data type on error.  New religion at NI, wire the error cluster on the shared variable.  This is not just a global variable.

Issue 7 - David Thomson - In order for the host laptop to talk to the cRIO RT with SV's, I had to edit the Windows Firewall to allow certain exceptions.  These were documented on the dev zone.  This was 6 months ago.  A few months later, a Windows Update was pushed out and SV's stopped working again.  I could not find any updated info on the dev zone, nor could I find what else to change on the Windows Firewall.  We had to disable the Firewall.

Exceptions should still be the same.  David 8.2.  With improvement in 8.5 and the transport, then could be different set of ports.  NI will look at the dev zone. 

Issue 8 - Nancy Hollenback - So why is the Distributed System Manager so pokey at times.

How many.  Probably hundreds of vars.  Just a basic network traffic issues.  NI has not seen performance issue.  Steve:  "had window task manager open and DSM - SQL Server was consuming 80% of desktop, support said that in certain situations, SQL server just takes over"  Yes, DSC installed and 8.6.1. 

Issue 9 - Nancy Hollenback - There are some very good examples in the Datalogging and Monitoring Reference architecture, but for Joe LV Programmer to dig through this and find the goodies is well.. time consuming to say the least.  But then, again I can make $$$ helping clients wade through this large app to get to the golden egg.

NI.com/dsc has some getting started material.  Yes it's on the roadmap for Arun. Arun and Nancy will talk offline. 

Issue 10 - Steve Drouilhet - The multi-variable editor allows one to easily edit the properties of many shared variables at once.  Why not all properties?  I especially would like to be able to enable or disable RT FIFO from the multi-variable editor.  Currently, I have to do it one by one, which is a real pain in the butt.

CAR has been filed.  Fixed in 2010.  The work around is to export to Excel, the edit and then reimport.  Then do it.  Yes, NI says is a kludge.  Right click on library in project to export to Excel.  Steve: "setting something to be target relative or not - not accessible from MVE - is this an oversight?" "Would like to be able to create target relative by default"  NI will look into. 

The reason SP SV is always target relative, scope is within the target.  At one point default was this, but broke other stuff, so NI had to roll it back. 

NI needs to work on this a bit more.

Issue 11 - Steve Drouilhet - Why can't a cluster shared variable have the RT FIFO enabled?

Should support any data type the RT FIFO supports.  Will never be able to support clusters with variable sized.  Must be fixed sized.  2009 will allow fized sized clusters, but no array or string. 

Issue 12 - Steve Drouilhet - I would like to be able to highlight a group of controls or indicators on the block diagram and do a bulk creation of shared variables from them and also be able to specify whether they will be created as single process or network published shared variables.  This is currently a cumbersome one at a time procedure.

8.6 introduced a function block.  All inputs and outputs are variables.  NI looking for feedback.  NI says good feedback.

Issue 13 - Steve Drouilhet - From what I read, there is only upside to using the RT FIFO with shared variables and no downside.  When would you NOT want to enable the RT FIFO when creating a shared variable?

Small memory hit and performance issue.  Depending on the app, could be a performance improvement.

Also. it appears that you cannot use RT FIFO NSV's within a built application when the build has the "Enabled Enhanced DSC support" this will crash the exe.

Issue 14 - Nancy Hollenback - I want access to the value of a SV from the property node!!!

Incomplete API at this time.  Have not absorbed all DSC functionality in LV.  Not there yet.

enableSVDynamicAPI=True will give you the ability to use SV tags with a URL input.  I have been using this to read scan engine IOV's

Issue 15 - Chris Clark - Hey we need John McGlaughlin sp? to say "Issue Number Four!" Dave Thomson's Issue 4 is a classic. I have SVs deployed on an RT FieldPoint target, works great. Change host computer, copy host exe over, check aliases file. Doesn't work, SV error SVs not found. I have to fuss around like a blind woodsman hacking away to get it to work. I can always get it to work but I don't know how.

Issue 16 - Steve Drouilhet - I have created shared variables from a strict type definition custom control.  I would expect the shared variable to update if I change the strict type definition, however it does not.  The data type of the shared variable is static, i.e. it remains the same even if the strict type definition is modified.  This is inconvenient and defeats the purpose of using a strict type definition.

Issue 17.  Disable Autodeploy Variables in the project does not seem to work.  Actually, it is just confusing, I thought that disabling autodeploy on 'My Computer' would prevent autodeployment of bound variables to a RT target but you need to also disable autodeploy on each RT target referenced in your windows vi.

Issue 18.  Please remove old documents and KB articles about NSV's that are not current. 

Issue 17 - Martin Keller - When I have a Runtime Menu pulled out (eg. click on "File" on my running VI and leave it pulled out), the VI "DataSocket Open" blocks the execution of my code first, then times out returning error code 56. Why does this happen? Am I doing something wrong or could this be a bug?

This is a bug and will file a CAR. 

Issue 18 - Scot Blackford - It would be very helpful for those of us off site to have conference shared the so that questions and answers could be addressed real time.

Issue 19 - Steve Drouilhet - LabVIEW shouldn't allow you to delete a shared variable from a project if it is used in a VI in the project.

Want to build a programmatice API to allow users control of the variable configuration and now have the control under the project.

Issue 20 - Nancy Hollenback - Why does the Create Shared Variable.vi (with DSC) not allow me to specify a variant data type.  The work around is very cumbersom and I have not seen direct NI documentation on how to do this.

2009 API.

Issue 21  Nancy Hollenback - need to dynamically create a process with SVs that will be varients.  I then need to be able to read the actual value back out.  I noticed that the SVE (via the distributed system manager) will recognize a number/boolen and other types even when they are created as a variant.  How ever it does not distinguish an array (ie need the basic data types in the properties dialog when statically creating a SV).  So the only way I know to get the data type for conversion is to save the information in the description of the SVE.  Is there a better way?

VI.lib, some VI's in there.  /Utility/Varient.  Will give enum with all the types.  Not promoted as there are some rought edges.  2009 will have API to get property node as variant.

Not smart to change data types programmatically.

Issue 22  Nancy Hollenback - why is it faster to use the Citadel Writing API to store data to Citadel than to have the SVE log it automatically?

Small performance hit with SVE, Citadel API is just faster.

Issue 23 Brandon Settles - Why can't SV's be programmatically deployed from an RT environment? If there is some trick that doesn't involve running an app in Windows, please let me know.

Look at 2010. 

David, Steve and Nancy say thanks to Arun, Darren, Will, and Paul!!!  SVE has tremendous value and we look forward to the upcoming improvements.

PS - John G and Erik A were also on the call and say thanks!

20091019 - There has recently been a discussion of some issues with Shared Variables on Info-LV.  In anticipation of the Nov 3rd meeting, here are some excerpts from that discussion:

Message: 2
Date: Tue, 13 Oct 2009 11:08:27 +0100
From: "Parkinson, Andy"
Subject: timeouts and timestamps on shared variables
To: <info-labview@labview.nhmfl.gov>
Message-ID:
    <8720B1699A81EA41A78E91F8FCFDA704418773@crystaloxs05.pv-crystalox.local>
   
Content-Type: text/plain;    charset="us-ascii"

Dear List.

I'm having a spot of trouble with both the timeouts and the timestamp
element of network-published shared variables between remote machines.
I'm using LV2009.

1. Timeouts.  There are three methods for opening a shared variable
found in the shared variable palette under data communications.  They
all take several seconds (about 5 in my experience) to time-out if the
shared variable at the specified url is not available.  This is
regardless of the timeout setting on the 'open and verify' version -
this setting seems to do nothing at all.  I have resorted to using
datasocket, which does successfully timeout after the specified time.
This works so I'm happy to go on using this method.

2. Timestamps.  I want to know if the shared variable data I'm reading
from remote machines is old/stale.  The timestamp element is supposed to
indicate when the data was last written, so this seems ideal for that
purpose.  However, what I have found is that the timestamp value on the
'reading' end of the network just keeps ticking up regardless of whether
or not the remote writer has stopped updating the shared variable.  I
have experimented with numerous settings on the variable itself, e.g.
single writer, buffered, etc., and have found only one state in which
the timestamp 'works'.  That is when the variable is itself being
continually read inside a loop on the writer machine.  My tests have the
writing machine write a new shared variable value then enter a read
loop.  Whilst being read on the writing machine in this manner, the
other remote reader does indeed see that the timestamp has frozen at the
last write.  Unfortunately this doesn't provide a solution for me as the
moment the loop or vi, etc. is terminated, the timestamp on the remote
reader starts ticking up again, and I have no idea if my data is stale.
The only solution I have so far found to this problem is to include an
explicit second timestamp for bundling with the data being written to my
shared variable - hardly ideal as this at least doubles my network
traffic and renders the native timestamp redundant.

So, I am planning to use datasocket to read my shared variable because
the time-outs work, and I am planning to send my own timestamp alongside
my data.  If anyone has experience with these things and has found a
better method than these clumsy work-arounds I would be grateful for
your advice.

Thanks,

Andrew Parkinson
Crystalox Limited
175 Milton Park
Abingdon
Oxon OX14 4SE
UK
Tel: +44(0)1235 448706
Fax: +44(0)1235 448718
e-mail:

------------------------------

Message: 3
Date: Tue, 13 Oct 2009 10:38:20 -0500
From: Mike Sachs
Subject: Re: timeouts and timestamps on shared variables
To: Info-LabVIEW <info-labview@labview.nhmfl.gov>
Message-ID:
    <6a6223990910130838q808e3dp23dc52428c60b3ef@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Well all I can say is that I use buffered NSV's all the time as
command/response FIFO's and use the timestamp output to tell me when I have
new messages to process.
In my case the NSV is being hosted and read on the cRIO and being written to
on the PC.  BTW, I am using the SV API (without timeout) to open the
connection and then read or write.
--------------------------------------
Message: 3
Date: Wed, 14 Oct 2009 14:48:20 +1100
From: Peter Badcock
Subject: Re: timeouts and timestamps on shared variables
To: Info-LabVIEW <info-labview@labview.nhmfl.gov>,

Message-ID:
    <adcb5aa80910132048n1e6b6deewf543d6072af6e608@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi Andy,

I posed your q. to a colleague of mine who initially went down the path of
NSV then changed to using Datasockets for many reasons - you just gave him
two more !

*In summary*: I would encourage you to use Datasockets rather than NSV

*More details*:  We use timestamp parameters in a lot of our Datasockets.
Have you actually calculated the network overhead of adding a timestamp
channel/parameter ? I don't think it will be much unless you have an
incredibly fast data rate or hundreds/thousands of parameters to transfer.

NSV's seemed to have too much overhead to be used in one cRIO LV-RT system
my colleague implemented.

NSV's don't have the ability to allow you to wait for new data without
polling the value to see if it changed.  OTOH Datasockets do allow you to
read data and if there is nothing new there the Datasocket Read primitive
will wait until data arrives (set *wait for updated value=True ) *and once
it does that part of the diagram continues on (if the timeout hasn't already
been reached). The act of waiting Does NOT consume CPU cycles ! Whereas with
NSV the act of polling it to see if more data has come will consume CPU
cycles.

NSV's don't have all the information about buffer sizes that a DS has. A DS
allows you to read exactly how many bytes are in its buffer while a NSV only
has Full/Half Full and Overflow flags.  To see this DS property check out
this<http://zone.ni.com/reference/en-XX/help/371361F-01/lvhowto/using_ds_buffering/>and
this
<http://zone.ni.com/reference/en-XX/help/371361F-01/lvhowto/monitor_buffer_size/>
link.

cheers

Peter Badcock
Product Development
ResMed Ltd

   2. Re: timeouts and timestamps on shared variables (Peter Badcock)

----------------------------------------------------------------------

Message: 1
Date: Sat, 17 Oct 2009 10:26:06 -0700
From: Jack Hamilton
Subject: Re: timeouts and timestamps on shared variables
To: Info-LabVIEW <info-labview@labview.nhmfl.gov>
Message-ID:
Content-Type: text/plain; charset="windows-1252"

Peter

I just wanted to comment on cRIO issues, as I have had some experience
with this. They might be very useful to all.

The cRIO is sensitive to full CPU load situations especially where a FOR
or While loop is implemented without ANY timing delay. Even of the loop
is running a few iterations - it will consume 100% of the CPU for that
burst. On multi-thread applications - the problem may not manifest
itself until a random synchronization of those loops occur and the cRIO
my lockup or hang. (I've had this happen)

As I've never seen this on the Windows OS. I was resistant to believe
that this was a potential cause - but with 50+ cRIO exhibiting random
hangs. I diligently added 1 ms delay to all FOR and While loops...and
the problem went away completely, I mean completely...

In RT systems, were programing are at a lower-level and have to manage
CPU loading.

Regards
Jack

------------------------------------------------------------------------------------------------------------

Additional issues posted on the LabVIEW forum, e.g. how to automatically launch a VI that uses SV's without opening its project, and how to use SV's between two PC running LabVIEW.

[Earentzen]

Thanks for the summary, Nancy!  I was present on the call, but I haven't made use of Shared Variables and thus had nothing to add.  Learning through osmosis.

[Ed_McC]

Your comments about the Shared Variable technology has been heard by R&D, and they have listened and responded.

Tony Vento, the VP of Applications and Systems Engineering, along with Christian Loew, Senior Systems Engineer, what to meet you in person on TUESDAY, November 3rd. They want to discuss how NI is working on Shared Variable.

This is a great opportunity to meet key leaders from NI and to give them feedback and to make special requests.

The logistics for the meeting are

     Date: Tuesday, November 3rd

     Time: 6 to 8 PM

     Place:

          Colorado School of Mines
           1600 Arapahoe
           CSM Annex
           Building # 3F SPACE Conference Room
           Golden, CO  

Pizza and sodas will be provided.

Please register your intent to attend by going to http://sine.ni.com/nievents/app/offering/p/offeringId/523275/site/nic/country/us/lang/en

[viScience]

It would be nice to have this seminar also include a netmeeting for those of us that are interested in the topic but do not live in Colorado.