LV2010+Static NSV+Dyn NSV = Watchout! (Revised)

[viSci]

Just a word of warning based on my recent experience...

If your RT code has lots of static NSV nodes and you are also programmatically opening NSV references then

you need to make sure that the behind-the-scenes init code that comes with each static NSV node

has completed before attempting to use the NSV API. If you do not then you may corrupt the SVE

and will have to reboot to recover. Currently I just do a dumb wait (30s in my case), it would

be nice if there was a way to find out programmatically when it was safe to start executing your RT code.

[Aristos Queue]

Have you reported this on ni.com/forums so that a bug report can be filed?

[viSci]

Yes it has been reported.

[viSci]

It appears that all of the strange conflicts I was seeing were being caused by some 'innocuous'

initialization code that contained a call to the RT Set Time and Date vi. Apparently, this is a no-no

when your RT code if first starting up and can cause problems with the static NSV init code

that the LV2010 compiler generates which runs in the background as your RT code begins execution.

So I guess my title should be changed to LV2010+Static NSV+Dyn NSV+RT Set Time and Date=Watchout!

[Mellroth]

Just a word of warning based on my recent experience...

If your RT code has lots of static NSV nodes and you are also programmatically opening NSV references then

you need to make sure that the behind-the-scenes init code that comes with each static NSV node

has completed before attempting to use the NSV API. If you do not then you may corrupt the SVE

and will have to reboot to recover. Currently I just do a dumb wait (30s in my case), it would

be nice if there was a way to find out programmatically when it was safe to start executing your RT code.

I have a similar issue with NSV:s and RT.

If the RT application is executed from development environment, everything works fine, but if the application is built into a rtexe and set as startup the application is broken.

If the rtexe was built with debug enabled and I connect to the rtexe, the panel displays a broken arrow but no information about what caused the application to break.

I've tried the delay before accessing any shared variable, but it is still the same.

The only solution that seems to solve my issue is to replace all static NSV:s with programmatic access. Lucky for me I only have 5-10 static NSV's in the application.

/J

[Neville D]

I have a similar issue with NSV:s and RT.

If the RT application is executed from development environment, everything works fine, but if the application is built into a rtexe and set as startup the application is broken.

If the rtexe was built with debug enabled and I connect to the rtexe, the panel displays a broken arrow but no information about what caused the application to break.

I've tried the delay before accessing any shared variable, but it is still the same.

The only solution that seems to solve my issue is to replace all static NSV:s with programmatic access. Lucky for me I only have 5-10 static NSV's in the application.

/J

Hmm.. not sure what version you are using but I have used 8.6.1, 2009 and 2010 with static and dynamically called Shared variables, with no problems. I have about 80 of them and 3 or so are read dynamically in the PC Host. The SVE is hosted on the RT PXI target.

Neville.

[Mellroth]

Hmm.. not sure what version you are using but I have used 8.6.1, 2009 and 2010 with static and dynamically called Shared variables, with no problems. I have about 80 of them and 3 or so are read dynamically in the PC Host. The SVE is hosted on the RT PXI target.

Neville.

It was LabVIEW 2010.

The problem was that I used a typedef enum to define the NSV type, and this was not accepted by LabVIEW. The typedef was deployed in the same lvlib as the shared variables and was accessible on the RT block diagrams.

Anyway, I managed to get around it, and I believe NI was able to reproduce the issue with my shared variable setup.

/J