Jump to content

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

Link to comment

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
Link to comment

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

Link to comment

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
Link to comment

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.
Link to comment

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:

Link to comment
  • 1 month later...

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
Link to comment

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.

Link to comment

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