Jon Kokott Posted November 28, 2011 Report Share Posted November 28, 2011 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 Quote Link to comment
FraggerFox Posted November 28, 2011 Report Share Posted November 28, 2011 (edited) 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 November 28, 2011 by FraggerFox Quote Link to comment
Jon Kokott Posted November 28, 2011 Author Report Share Posted November 28, 2011 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... Quote Link to comment
SuperS_5 Posted November 28, 2011 Report Share Posted November 28, 2011 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. 1 Quote Link to comment
Jon Kokott Posted November 28, 2011 Author Report Share Posted November 28, 2011 I'd love to dump 2010 upgrade to 2011, just gotta get the right people on board... Quote Link to comment
ShaunR Posted November 29, 2011 Report Share Posted November 29, 2011 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 Quote Link to comment
asbo Posted November 29, 2011 Report Share Posted November 29, 2011 Naaah. Downgrade to 2009. It's faster and you probably already have it Are you just trolling or does 2009 actually outpace 2011? I haven't used it enough to know ... Quote Link to comment
Aristos Queue Posted November 29, 2011 Report Share Posted November 29, 2011 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. Quote Link to comment
ShaunR Posted November 29, 2011 Report Share Posted November 29, 2011 Are you just trolling or does 2009 actually outpace 2011? 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. Quote Link to comment
GregSands Posted November 29, 2011 Report Share Posted November 29, 2011 9 times out of 10...Yes. But don't go comparing 2011 x64 with 2009 x32. It'll make you cry. 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? Quote Link to comment
ShaunR Posted November 30, 2011 Report Share Posted November 30, 2011 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 Quote Link to comment
0_o Posted January 9, 2012 Report Share Posted January 9, 2012 (edited) 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 January 9, 2012 by 0_o Quote Link to comment
0_o Posted January 9, 2012 Report Share Posted January 9, 2012 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. Quote Link to comment
SuperS_5 Posted January 9, 2012 Report Share Posted January 9, 2012 (edited) 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 January 9, 2012 by SuperS_5 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.