Shared Variable Issues circa 2010

[viScience]

Anybody up for another discussion on our collective love/hate relationship with SV's and NI's PSP.

Has LV2010 lived up to your expectations?

[nancyj]

I'm in!  Using the new purple dots on an application right now.  Additionally using the tag API and DSC for another application.  My experience is that the NI PSP SV's work very well, once they have been configured correctly.  The learning curve was a little steeper than I would have preferred.  I'm also using the IO SVs on RT and the Scan Engine.  I have a dynamic environment in which the name, metadata, number and everything about and IO point can change for each test.  The one glaringly missing feature is the ability to easily convert a string to the appropriate SV. 

As we continue this discussion, do you propose a thread here or an online meeting?

N

[viScience]

Hi Nancy,

Thanks for chiming in. I am not really sure where the best location would

be for this discussion. I initially choose ALARM in the hopes that some of

our SV veterans like yourself would

be interested to continue the previous discussion on the subject. I have

been knee - waist deep in LV2010 for a solid month now and have come across

quite a few confounding issues in regards to NSV's and would very much like

to compare notes with others. I also have created a 'dynamic' environment

where I can reconfigure my cRIO environment during runtime and do alot with

the SV and PSP API. What do you mean about the missing feature to convert a

string to the appropriate SV? This sounds like something I do quite a bit

when building NSV URL's.

[Christian_L]

Thanks Mike,

I'll be interested in feedback and any discussion as well, and can hopefully provide more NI insights and behind the scenes information where necessary.

I did a session on Alliance Day looking at dynamic use of SVs, but focused on LV 2009. I haven't had much time to work with these features in LV 2010 yet, but can test out anything you'd like.

Christian

[nancyj]

Mike, feel free to buzz me anytime 303-359-4356.  But in interest of keeping the discussion open for others:

• I did not find a "string to SV" function (checked with NI on this) like we have in the DSC API.  I had to cobble together a solution that does work.  Will send screenshot over the weekend
• I was doing a lot of development on prerelease 2010 and due to scheduling issues, I did not return to a few gotchas that I had For instance, I cannot get the same information out of the PSP API that I can get from the IO API
• I am curious about your dynamic environment.  My client edits channels and their meta data in the MS Office ActiveX component (ocw12 - I think) in LabVIEW.  Then in another screen we do a drag and drop to assign the detected channels to the spreadsheet.  At anytime the client may pause a test, search for new modules, reassign items, and then restart the test.  So on the RT I have the channel ordered appropriately for the NI Scan Engine and then I have another order for all client displays (all channels are by Val OOP).  Managing this is working great, but was tricky.  NI has a CVT reference architecture that could help, but I was far enough in my development that I continued with my design. 
• As part of the "auto detect" feature of the NI hardware, I had to filter some SVs that were returned and I had to reorder the channels so that the RT code could be optimized. (Christian, this might be a nice addition to the API).
• The only current "issue" that I have is a performance issue.  I have some configuration screens that slowly read current values so the user can select channels for displays and alarming.  I use the read that is in the main SV palette.  This first time I read all 200+ channels it is real slow.  All subsequent reads are very quick.  Have you run into this.  Christian, any thoughts?

Like I said, I'll send some screenshots this weekend. 

Mike, are you running into any specific issues right now?

[viScience]

Here are some issues I have found recently...

1. Setting the RT system time to 00:00:00 at the very beginning of your app can hose up the SVE and create weird interactions between static NSV initialization and the use of the SV API.
I wish I could submit an example but I was not able to recreate it other than in a large app.  Just trust me...don't do it!
2. I have found that the SVE, over repeated 'soft re-starts' of an RT app, can accumulate stale transaction references that can add significant cpu burden.  In my case I often see 7-8%
increased loading upon subsequent restarts of my rt app.  HW resets and SV deployment always fixes the problem until the next software restart.  I am still working to create a small scale example of this phenomenon.  Just putting it out there to see if anyone else has seen anything like this.
3. NSV and IOV urls have changed from LV2009->LV2010 in that you are now REQUIRED to prepend the string 'ni.var.psp:' or 'ni.var.io:' to all URL's.  Previously you could get away without doing this.

Some other thoughts:

1. What happened to the promise of being able to programmatically deploy SV's in an RT app in LV 2010?
2. Why can't we have native LV SV events?  It appears that the SVE natively supports this, could we roll our own?