Jump to content
Jon Kokott

Inline SubVIs inside rentrant DD causes bad behavior?

Recommended Posts

I have inline subvi calls inside a reentrant Dynamic dispatch. It worked for a while, then it started crashing labview. I believe this started happening when I modified the contents of the class being dispatched.

Once I removed the re-entrancy it seems to be solved. Anyone encountered anything like this?

~Jon

Share this post


Link to post
Share on other sites

From what I think, when you say "inline subVI", labview will add the inlining code to the top level code where it is called, while its compiled. Now, if you have changed the contents of the class later, and have kept the option of keeping compiled code separate of VIs, it shouldn't automatically add the inlining code to the top level of your VI.

Did you have the option of separating the compiled code from the main VI enabled when you encountered this problem?

-FraggerFox

Edited by FraggerFox

Share this post


Link to post
Share on other sites

I don't separate compiled code. Additionally I've forced recompile many, many times.

From what I think, when you say "inline subVI", labview will add the inlining code to the top level code where it is called, while its compiled. Now, if you have changed the contents of the class later, and have kept the option of keeping compiled code separate of VIs, it shouldn't automatically add the inlining code to the top level of your VI.

Did you have the option of separating the compiled code from the main VI enabled when you encountered this problem?

-FraggerFox

That doesn't sound right...

Share this post


Link to post
Share on other sites

I assume that you are using LV2010. (From your profile) We just recently upgraded to LV2011, and it a lot more stable. We had a lot of problems where LV would become very flaky when editing classes. (particularly if you tried to click faster then LV could finish loading screens, or had a lot of windows open. I never tried too hard to isolate the problems) Of course, there may be limitations, but if it is possible, I recommend upgrading.

  • Like 1

Share this post


Link to post
Share on other sites

I'd love to dump 2010 upgrade to 2011, just gotta get the right people on board...

Naaah. Downgrade to 2009. It's faster and you probably already have it :P

Share this post


Link to post
Share on other sites

Naaah. Downgrade to 2009. It's faster and you probably already have it :P

Are you just trolling or does 2009 actually outpace 2011? :P I haven't used it enough to know ...

Share this post


Link to post
Share on other sites

does 2009 actually outpace 2011?

If Shaun is talking run time performance, this claim is extraordinarily unlikely given that 2009 includes none of the modern compiler optimizations. If Shaun is talking edit time performance, the claim is generally unlikely but there may be some particular edit operation that he does frequently that may be slower, but mostly 2011 fixes the commonly sighted editor slow spots.

Share this post


Link to post
Share on other sites

Are you just trolling or does 2009 actually outpace 2011? :P I haven't used it enough to know ...

9 times out of 10...Yes. :) But don't go comparing 2011 x64 with 2009 x32. It'll make you cry. :D

Share this post


Link to post
Share on other sites

9 times out of 10...Yes. :) But don't go comparing 2011 x64 with 2009 x32. It'll make you cry. :D

I've been using 2011x64 a bit lately, and the speed hasn't been an issue at all. Now, the functions don't always work, but that's a separate issue. What have you found?

Share this post


Link to post
Share on other sites

I've been using 2011x64 a bit lately, and the speed hasn't been an issue at all. Now, the functions don't always work, but that's a separate issue. What have you found?

Not an issue. Comparatively. X64 is slower in most (all?) of my use cases than X32 (regardless of LV version) So I was simply implying compare apples with apples.

Don't get me started on the "don't always work". Still can't back-save to <8.5 and 2011 x32 just crashes on start-up since it was installed :shifty:

Share this post


Link to post
Share on other sites

Back to topic (a month later)...

I'm using LV 2011 and I have kinda the same problem.

I added the same subvi to all my write member access vis with property nodes.

Even though is was a regular subvi, once I tried writing to multiple property nodes from the same property node block LV said I tried a recursive call and stopped the execution of my project without even getting to an error wire, simply finished the execution on the spot.

I guess inline should solve it since once I copy/pasted the code it wirked just fine.

However, for some reason, I can't find the inline subvi option anymore under the execution option in the properties menu.

I can understand why LV didn't like me doing it, even though it should have been more polite, yet, turning the vi into reentrant should have solved it and it doesn't.

You simply can't call a recursion from inside a member access vis and from what Jon wrote it seems it is not the only place this option causes problems.

To sum it up, I guess LV can't handle a parallel recursive call to the same class from inside some blocks and NI needs to document this scenario more.

P.S. - moreover, you can't call a property node of the same class from within a member access vi of the same class that has a property node.

Edited by 0_o

Share this post


Link to post
Share on other sites

I solved one of the problems:

in the initialization I entered values to a list of property nodes on a single block while one of the initialized values was a queue that the rest of the property nodes were using and thus if a property node was accessed before the queue was initialized all the rest didn't run because error 1 was propagated between them.

a property node of several properties is executed from the top down.

Share this post


Link to post
Share on other sites

The property node can be set to "ignore errors." This stops this propagating the error down to the other properties. (Incoming errors still cause the node to skip execution though.) In this mode, the first error is outputted, while execution continues.

P.S. - moreover, you can't call a property node of the same class from within a member access vi of the same class that has a property node.

I believe we have done this in LV2010. The same code works in LV2011, but I don't think I have tried creating this scenario in LV2011. (Property node>property node of the same class.)

Edited by SuperS_5

Share this post


Link to post
Share on other sites

Join the conversation

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

Guest
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.