Having a variable number of input ports on a subVI

[RavensFan]

Based on your question you asked in this thread. http://forums.ni.com/t5/LabVIEW/Run-sub-VI-in-another-VI/m-p/3347761/highlight/false#M983658, I don't think you are ready to work with VI scripting yet.

[Mmehrabin]

Maybe I am not ready enough but I should do that asap. I have some experience in VI scripting but as my project I should implement some easy cases in VI Scripting. So please let me know if you can, how can I have a variable number input ports in VI scripting. However, I should start.

[natasftw]

The answer you want  was already given in this thread.  Just make an input of an array type.  Send in as many signals as you'd like using this. 

The scripting method is going to be a mess to do well, if at all.

Not only would you need to learn enough about scripting to make this work, you'd also need to create scripting for the caller VI to change how it's wiring things into the subVI you're looking to script.  You couldn't make these changes at the runtime of these VIs.  You'd have to build another VI on top of both the caller and the subVI JUST to get this functionality to work.  In the end, it'd be virtually the same performance as if you had made a loop to work through the array of data sets.  You can even parallelize the loop to make it more optimized in performance.

Are there people here who could help you find a way to script this?  Probably.  Should they?  Not likely.  An overengineered solution is rarely the best solution for the problem you face.

[Daikataro]

---

@natasftw wrote:

Are there people here who could help you find a way to script this?  Probably.  Should they?  Not likely.  An overengineered solution is rarely the best solution for the problem you face.

---

This. Overengineering is, more often than not, bad engineering. If you have a lot of different signals, why not use the array solution that has been mentioned or, if they are too different of a type to be an array, why not make a cluster with the absolute maximum amount of signals and work from that? A single, ellegant cluster wire is often better than an "octopus SubVI" anyway.

[Mmehrabin]

Actually, I am coding for a program in which the exact number of inputs are not defined. The action on all inputs is the same. For example, assume I get 2 signals and show the summation of them. I want to that for 3 or more inputs with the same functionality. 

[billko]

I have no idea what you mean.  Please share some simplified code to illustrate your problem.

[natasftw]

Actually, this is exactly the problem solved by an auto-indexed for loop.  It takes an array as an input (which isn't of a defined size in LV) and executes once per element.

Again, your solution is over engineering something that's pretty basic to resolve.

The problem isn't the advice you're being given.  It's the lack of your willingness to follow the advice. In your other threads, basic tutorial classes were recommended.  Start with those before continuing with your project.  Based on the questions you're initially asking and the follow up questions, it's readily apparent that you're making things harder on yourself. 

We're not telling you to take those basic tutorials to be cruel.  We're telling you because you're wasting YOUR time by not doing so.  How many hours have you already invested in this single attempt that honestly doesn't make sense?  How long do the courses take?  After taking them, you'd program the application in a time combined with the time used to take the courses.  That time will STILL be less than the amount of time you've spent on trying to go about this in a way that simply doesn't make sense.

Programming an application is a lot like writing a novel in more traditional languages.  If someone saw you struggling to put together a novel in Japanese, they'd likely suggest you take Japanese lessons to save you from frustration.  We're doing something similar here.  You're not in a place to write your novel.  Take a few hours to understand the language (your primary tool) first.  THEN jump into writing your novel.

[Mmehrabin]

I think it is the misunderstanding of you. I know about auto index but my question is completely different. I have passed Core 1 & 2 and FPGA in LabVIEW courses. I am not perfect in them but I know the basics. 

My exact question is:

I want to design a subVI with variable input ports. e.g Array index or compound arithmetic in which by putting the mouse pointer on the bottom edge of them we can add more same input ports or reduce the number of them such as the attached files.

I hope you can get my exact question.

By the way, thank you for your advice.

[RavensFan · Accepted solution]

No.  The people responding to this thread are not misunderstanding.  They have a lot of experience and know what can be done and can't be done.  What should be done and what shouldn't be done.  You have the misunderstanding.

The fact is what you are asking for shouldn't be done, and in all honestly, can't be done (at least not without a far more complicated understanding that you don't have, and the vast majority of us don't have.)  The correct for a a subVI that handles an undefined number of inputs is what you've already been told.  Have the subVI take in an array and work on that.

[natasftw]

 Read the replies before you even begin to suggest we're the ones with the misunderstanding.

We get your question.  It's very simple to understand.  Here's what YOU'RE not understanding.  It's a poor way to approach the problem.  If it performs the function, it will be incredibly janky, at best. 

I'll give you another analogy.  I'll give you a question and ask for your advice.  I have two 16 bit values.  Can you explain a way for me to use bitwise logic to isoloate each individual bit and then find a method for me to combine these individual bits I now have to find out exactly what would happen if I try to combine these values?

Or, would you suggest I use the add function because it makes far more sense for what I'm trying to do?

What you're trying to do simply doesn't make sense.  You can't do it easily.  If you do it at run time, you'll be making things temporary and having 3 layers of complexity to handle a simple task.  You're forgetting PCs have cores so they cannot handle all of these signals in true parallel.  That's the purpose of threading.

There is exactly ZERO advantages to the way you're approaching this problem.  There's countless disadvantages.  What part of that is so difficult for you to understand?  Or, do you want to tell us again that we're not understanding that you're asking for advice on how to do something in a nonsensical way?  This isn't how you "scale" your application.  This is how you make it such a mess that you can't maintain it moving forward.  You're looking to do something counterproductive to your goal.  Stop being stubborn about a bad idea and listen for those that have seen how this works in the past and learn from it.  Being stubborn about a bad idea doesn't mean others don't understand the idea.  It just means we don't understand why you ask for help and refuse to listen to reason.  THAT is what we don't understand.