Volunteer at the American Museum of Natural History

[altenbach]

---

@exo wrote:
Okay, Thanks, So I got this far but I want to run it continously and have the Object string remain in the window until I'm ready to change it.

---

remain in what window? What do you mean by that? 🙂

Your code is deadlocked, because the loop can never finish. This means that your string indicator will never receive any data. Data cannot flow out of a structure until everything in it has completed.

Try something like the following (the insert shows the "other" event case.

Also look it my comments in the other thread. Use execution highlighting to get a better feeling for the dataflow process. 🙂

Message Edited by altenbach on 09-06-2007 12:08 PM

[Gabi1]

here is another event which wait until you decide you have finished writing the object.

edit: Altenbach has it already 🙂

Message Edited by Gabi1 on 09-06-2007 09:05 PM

[altenbach]

Gabi, he's apparently using LabVIEW 7.1, so won't be able to see your code. 😞

[exo]

Thanks but your version is not backward compatible wih mine.

[exo]

Sorry don't quite understand. But, on the other hand, I probably didn't make myself clear. The new code will demonstrate.
I input a star name and the vi returns certain information. Then it sits there and waits. I want to be able to either push the run button, or go back and input another star name. Just push me in the right direction. Big pushes are, of course, greatly appreciated.

Thanks.

[Gabi1]

lucky i still have 7.1 on my laptop 🙂

here is a little bit cleaned software:

1) you do not need to feed both the indicator and the local variable of the same indicator. in general, you do not need locals for such operations.

2)you do not need to connect control to hidden indicator just for keeping the values. value is kept in the control already.

3)until your software knows what it should do, there is no necessity to empty indicators and controls, especially not with local variables. as your software and skills evolves, you will learn better ways to do so, and even maybe different approach to the user interface. at this stage keep to the essential - minimise code, wires and clutter to core functionality only.

4) try and depict what overall should do your software - it seems to me at this point, that a single loop with event structure well arranged might answer all your needs. for example:
- event 0 - timeout
- event 1 - wait on write object - event is "continue"boolean - save data in this event case
- event 2 -.run some specific external loop - User interface might be : "run experiment".
.....
-event x - stop/finish

note: post all subvis so we can run it. best is to keep your overall project in a llb (save with options -> development distribution)

[RavensFan]

---

@Gabi1 wrote:

note: post all subvis so we can run it. best is to keep your overall project in a llb (save with options -> development distribution)

---

Good points on all of your comments.  Except I would suggest not keeping the project in a .llb.  Okay for posting to the forum.  But there have been many messages about people losing work with corrupted .llb's when they have been storing and working on their projects out of them.

[Gabi1]

---

@Ravens Fan wrote:

I would suggest not keeping the project in a .llb.  Okay for posting to the forum.  But there have been many messages about people losing work with corrupted .llb's when they have been storing and working on their projects out of them.

---

you are right. however, at this point of his LV skills, it soes not yet make sense to evolve towards a LV project. the llb still ensures a minimum of organisation, without confusing the user.

[exo]

Your code didn't run. I'm checking to see if I did anything wrong. But what I really want to know is how to I write a program that doesn't need the stop button. I put in an object and the vi returns some information from a file. If I want run with it, I could hit a button. But if I don't want to run with it, I want to be able to put in a new object without having to hit another button. To me another button is a big deal. Look at the attached vi. Don't worry about the sub vi's. Just look at the size and complexity of the program. Anything button and loop I can eliminate is good.

[RavensFan]

That color hurts my eyes! 

I see your program has evolved quite a bit.

One thing I noticed is that if you hit the bit Terminate Execution button, it stops your big loop.  Good.  But the loops at the top with TCP/IP listen don't stop unless there is a communication error.  So if communication is good, those loops will continue to run and your program will never actually stop.

 And the loops at the lower left embedded in the big loop don't stop unless their stop conditions happen to be true.  But what would happen if you hit "Terminate" while those loops are running?  They would continue to execute until their stop conditions are met, and (I am not going to try to figure out all the code) there is a possibility that would never happen if the other parts of the code have already stopped running.