indicator refresh

[km76107]

Hi,
I am trying to read a long ASCII String from 2 different PCs using TCP/IP. Each string has alpha numeric information such as "Sensor 1{[(HVACTemp1,70.00,dF),(HVACPres1,1000.00,psi),(HVACPres2,828.00,psi),(HVACVib1,500.00,mv)],[],[]};Sensor 2{[(HVACTemp2,94.00,dF),(HVACPres3,3.00,psi),(HVACPres4,5.00,psi),(HVACVib2,3.00,mV)]"

I am using a case structure to read the data from 2 different computers. The problem I am having right now is that when I read data from Computer B and display it on my front panel indicators, the data from Computer A resets to zero. Similarly, when i read from Computer B, the data on the front panel indicators belonging to computer A reset to zero.

I checked my code a million times and I have not reset anything to
zero during the transition.

I would appreciate if anyone can help me and let me know what I am doing wrong. Thanks in advance.

[Shan]

Pretty tough to guess without seeing what you're doing. If you post your code so we can see what you're doing.

One possbile cause would be setting the tunnel out of the case structure to "Use Default If Unwired". This option allows you to not have to wire an output from each case, but will use the default value for the control if you don't.

Tim

[AllenP]

Hi,

It sounds like Shan is pointing in the right direction. If your indicator is inside of your case structure, it will not reset its value. However, if your indicator is outside of the case structure, it will update its value every time. Unless you are using a shift register to retain the values, this will be reset to either the default value or whatever value you wire to it in the case structure. I have attached an example VI that should show you the difference.

Regards,
Allen P.
Applications Engineer
National Instruments

[km76107]

Thank you for the prompt response. I am attaching the code that I developed. I think I did not put my question in the right way. Please see code and the comments I have put in the block diagram. Thanks again and looking forward to a solution.

[Shan]

I took a look at your code. I am a bit confused. I don't see the case statement that you referred to. Is this a subvi that is called in the case statment? There aren't any inputs or outputs in the icon's connector. If this is a subvi, the problem may still be in the case statement that calls this subvi(?).

A couple things I noticed:
1. You update your indicators regardless of the TCP Read Error output. If you have a TCP Read Error (as your posted code does) the text string output of the read would be an empty string. That is a possible reason for the indicators resetting to zero.

2. You'll want to use the TCP Close Connection when you're done with the vi (or subvi).

Hope this helps. If there is a higher level vi that calls this one, po
st it so we can see what you're doing.

Tim

[km76107]

Hi Shan,
I am sorry I had mentioned the case structure earlier. There is no case structure in this program. I am trying to read a set of IP addresses from a flat file and then feeding the IP addresses into the TCP open connection to read the data from that IP address. I do the same procedure for each IP address obtained from the file. During the transition from one IP to other IP, the indicator doesn't store the value of the former IP, instead it shows a value zero until the next IP address is fed in and tcp read occurs.

Hope I have made my question clear this time and sorry about earlier confusions.

Looking forward to your reply.Thanks.

[Shan]

Please see my comment #1 from my last post. If you get an TCP Read Error, you should not be updating your display. Try putting the parsing subvi's and indicators in a case statement - wired to the TCP Read Error Out.

[km76107]

Thanks for you reply Shan. You are right about the empty string related to the TCP read error. I have alrady accounted for that. As you see in the code, the Data string is converted to an array and is fed into a sub vi that splits the array into individual components for display. I have attached the subvi that takes in the array(which is same as the data string) and manipulates the data to provide desired output. This is where I use the case structure and i have wired in local variables that are supposed to store the previous value of the indicator. I appreciate your suggestions and response.

Thanks

[Shan]

If I understand what you're saying - you expect a local variable in a subvi to hold their last value upon each call to the subvi. This is an incorrect assumption. Each time you call a subvi, the variables will be reset to their default values. So for example in your subvi you determine that it's "computer A", you still do a read local for the cluster from "computer B". This will return the default value, not the last value that was calculated the last time. This is why you are seeing the non-active computer string reset to zeros.

There are a several ways to fix what you're doing. One way would be to split up your vi into two vi's and putting them in a case statement. This way it only updates the cluster from
the appropriate computer.

A way to make your vi to work the way you want is to put a loop around the whole process and store each cluster in an uninitialized shift register. The loop only runs once each call and has the purpose of storing the last value. In this scenario, when the data comes from "computer A", use the shift register value for "computer B" to update "computer B's" output cluster.

Lastly, you could use Globals intead of Locals. A Global variable would behave the way you expect. I would urge you to use great caution however. You could very easily create a race condition (competing vi's updating and reading from the global) if you're not careful. There are ways to do what you need without resorting to Globals.

Sorry if this is confusing. It's easier to do than write.

Tim

[Greg_McKaskle2]

> If I understand what you're saying - you expect a local variable in a
> subvi to hold their last value upon each call to the subvi. This is
> an incorrect assumption. Each time you call a subvi, the variables
> will be reset to their default values. So for example in your subvi
> you determine that it's "computer A", you still do a read local for
> the cluster from "computer B". This will return the default value,
> not the last value that was calculated the last time. This is why you
> are seeing the non-active computer string reset to zeros.

Good advice. But to be a little clearer with locals, a control attached
to the connector pane will be reset to its default each time the VI is
c
alled and it isn't passed a value. If it is wired and a value is
passed in, then the local gets the control's value. If the control is
not on the connector, then it will retain its value across calls as long
as the VI stays in memory.

Again, shift registers are a better storage solution in general -- they
don't have problems with race conditions or performance.

Greg McKaskle