03-30-2010 11:44 AM
03-30-2010 12:17 PM
You've already moved past this a bit, but...
Starting with your original VI... If you know the max number of encoders -- the absolute max times the for loop will loop, then just create a case statement around the encoder vi in the for loop controlled by the for loops iteration counter. Duplicate the case enough times for every encoder to have its own case and the the reentrant property will work.
Randy
03-30-2010 12:53 PM
RandyR wrote:You've already moved past this a bit, but...
Starting with your original VI... If you know the max number of encoders -- the absolute max times the for loop will loop, then just create a case statement around the encoder vi in the for loop controlled by the for loops iteration counter. Duplicate the case enough times for every encoder to have its own case and the the reentrant property will work.
Randy
While agree that this can work for the short term it would not be my prefered method for resolving this issue. I don't like to set absolute limits for resources in my applications. I prefer a more generalized approach that won't require code modifications that allow more resources to be added. Picking some hard limit might work today but it can often burn you in the future when they need to add another encoder. Rather than some simple config file change or code that can detect the resources automatically you have to spin a new version of the code because it has to be modified in order to add that next encoder. Using templates and dynamically spawning the tasks is definitely a prefered method.
03-30-2010 03:22 PM
Mark,
I generally agree. Although there's something to be said for simple. I have use both methods, it all depends on the situation. I wouldn't dismiss it out-of-hand.
Randy
03-30-2010 03:52 PM
An autoindexing loop with use the smallest array to determine the number of runs. If you didn't know that don't worry, it took me about 7 years of LabVIEW programming before I actually found that out.....
Shane
03-30-2010 04:58 PM - edited 03-30-2010 04:59 PM
Intaris wrote:An autoindexing loop with use the smallest array to determine the number of runs. If you didn't know that don't worry, it took me about 7 years of LabVIEW programming before I actually found that out.....
Shane
Hahahaha ok 😄 I just made a test case and I verify it with the for-loop, it didn't even worked when used a array size tool connected to the count terminal. Tomorrow I will test it on the other VI, hope it will work then.
And yes I didn't know that, but I'm not worried now because I'm not really an professional labVIEW programmer, just a homble student who has a thing for labVIEW 🙂
03-31-2010 07:53 AM
03-31-2010 07:59 AM
WouterG wrote:Hey! I just tried it and it worked 😄 WOOOOOOOOO I'm very happy now! I want to thank you all for helping me, I'm very glad now that I know how to handle this problem. Because I can think of 10000 of usecases where this comes out handy....Here is btw a snippet from the code I've now :), in the outercase when close reentrents is true it closes the references, and in the innercase if it isn't the first call anymore it passes the shiftregister.![]()
Nice work for a noob!
Thanks for sharing your solution.
Ben
03-31-2010 09:58 AM
Ben a question for you, I saw a thread in which you replied, http://forums.ni.com/ni/board/message?board.id=170&thread.id=449810, I just found out that I still have trouble with that error 7. The "open vi reference" still creates that error (when I disconnect it from the error line the application works fine btw).
Error 7 occurred at Open VI Reference in NBG - Encoder read array.vi->main - rapid prototype.vi
Possible reason(s):
LabVIEW: File not found. The file might have been moved or deleted, or the file path might be incorrectly formatted for the operating system. For example, use \ as path separators on Windows, : on Mac OS, and / on Linux. Verify that the path is correct using the command prompt or file explorer.
VI Path: C:\ni-rt\startup\NBG - Encoder read.vi
LabVIEW Real-Time: VIs built into executables cannot be accessed through VI Server calls. Use Source Distributions to dynamically call VIs on Real-Time targets.
Now I do and don't understand this error at the same time. Because I'm not using any executables on my target, I only have my VI's and that's it, not any exe's. The path is 100% correct. Why do I get this error? I tried solutions:
- http://digital.ni.com/public.nsf/allkb/A7DBA869C000B5AE862570B2007C4170?OpenDocument
- http://digital.ni.com/public.nsf/allkb/EEE8A5650DAC28558625762F0070A384?OpenDocument
But none (ofcourse) worked because I'm not even using an executable...
Or does this error mean that I need to create an executable, http://digital.ni.com/public.nsf/allkb/CD3C7A3F58CBBAAA862570F8007D8D06?
03-31-2010 10:23 AM
Ben wrote:Nice work for a noob!
Thanks for sharing your solution.
Ben
I was thinking the same thing. Nifty code for a beginner to be sure! Makes me want to ask the question whether you're a beginner at all or if this is simply a bad assumption. Straight wires and no overlapping structures. Even Altenbach would find little (He always finds SOMETHING) wrong with this code.
Keep it up.
Shane
Glad you got it working.