Jump to content

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


viSci

Recommended Posts

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.

  • Like 1
Link to comment

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!

Link to comment
  • 3 months later...

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

Link to comment
  • 5 months later...

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.

Link to comment

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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.