Correct. You cannot connect an indicator to an indicator. They are both data sinks. You need one to be a control (a data source), and the other an indicator (a data sink). You can create a local variable of either a control or indicator, and change the read/write of the local variable so that you could either read or write to a control, or read or write to an indicator. But I wouldn't suggest that to you right now.
You have serious problems with your architecture, and using local variables are only going to make it worse.
In case you haven't seen these links before, I would recommend you learn more about LabVIEW from here. How to Learn LV. I know you are relatively knew to LabVIEW, but I know you've been around in the forums for a while. So I'm really surprised you're having such major problems with some basic concepts about dataflow.
Let's start with your subVI. In general subVI's don't have while loops in them, and don't present a user interface. So get rid of the while loop and the event structure. Having an event structure inside a running while loop subVI, called inside an event structure of your main VI, just has no logic to it. What are you really trying to do with the subVI that you need an OK button for it? Your subVI has a control called clerk. As a control, it can take data into its connector when called. But you have an Indicator called Test string which you are reading from. Indicators are designed to pass data out of subVI's. And why have the two other indicators called array and array2 in the subVI since you never use them there?
In your main VI, why do you have a button that has the word "Submit" on it, but never actually give that button a label? All controls should have names that are different from each other. Because you didn't name it, the terminal has no name above it on the block diagram, and the event case just has empty quotes identifying the Value Change event. Not labeling controls or indicators will cause major problems in trying to interpret and debug your code.
Before you do anymore coding, you should sit down and think about what you want this program to do. Step by step. What is each button or control supposed to do? Create a flow chart. Map out this program. Anything that is a distinctive step, or a function, or a process you repeat multiple times from different parts of your main program is a good candidate for a subVI. So all the items you have in the OK button event in your subVI would make a good subVI. You pass in two pieces of data in through its controls and write them out as a report. But the event structure and While loop have no business being in that subVI.
Message Edited by Ravens Fan on 04-08-2009 11:55 PM
