LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

hardware push button

I edited the cool method to remove the duplications. Could you see if this seems correct? In the mean time I'm trying to figure pass by reference. Thanx!
0 Kudos
Message 41 of 117
(1,350 Views)
by method i meant mode- cool mode Smiley Wink
0 Kudos
Message 42 of 117
(1,349 Views)
I think I understand what you are trying to say regarding the string but the implementation is not clear. I don't know how to do what you are saying
0 Kudos
Message 43 of 117
(1,345 Views)
See the attached 2 VI's.  Main VI passes a reference to its string indicator to the SubVI.  SubVI runs for 10 seconds continually updating the string in the main VI.
Download All
0 Kudos
Message 44 of 117
(1,343 Views)

I think I finally figured out what you were saying for the strings and I have edited the subvi and the main vi. Could you take a look and tell me if it is alright.

I have one question. For the sting indicator in the main VI, it is unwired (on top in the while loop). Only all the server referneces are wired to the subVIs. Is that ok??

 

Download All
0 Kudos
Message 45 of 117
(1,321 Views)


smm wrote:

I think I finally figured out what you were saying for the strings and I have edited the subvi and the main vi. Could you take a look and tell me if it is alright.

I have one question. For the sting indicator in the main VI, it is unwired (on top in the while loop). Only all the server referneces are wired to the subVIs. Is that ok??


That looks much better and cleans up miles of wire from the original Main VI block diagram.
Yes, you can have the string indicator sitting there doing nothing, and only the references wired to the subVI's.
 
You can also eliminate the sequence structure in your main VI because the dataflow of the wires will completely determine the order of execution.
0 Kudos
Message 46 of 117
(1,310 Views)

Thanks a ton for all your help. I appreciate it. I especially appreciate how patient you have nbeen with me through this entire VI building. I have troubled you with really small and maybe stupid issues but I hv learnt a lot.Thank You so much. My hardware should be ready soon. I'll test the code and will get back to you if I have any other problems.

Thanks again Ravens Fan and everyone else who helped me.

0 Kudos
Message 47 of 117
(1,295 Views)
While reviewing the VI, I came across one problem.
In my subvi, I have used index arrays to chosse certain lines form the read array. The read Vi reads close to 28 lines, but it indexes and uses lines as requred. Thus the index for every index array have to be different for each T'stat. With my current VI, this will not happen, becuase each subvi will cause the chage in the same line and hence only one T'stat as opposed to 6.
How do I change this. I was wondering if I should make multiple tasks for each T'stat. But then the problem of the error due to multiple tasks arises. How do I edit this? Please help.
0 Kudos
Message 48 of 117
(1,274 Views)
I have looked at your efforts and I think that some structural or architectural changes could make a big difference for you.

1. Your string messages to the user will be overwritten by the various Tstat states in complicated ways which will be confusing to the user. Possible solutions: A. Separate string indicator for each Unit. (Takes space on front panel). B. Have each Tstat subVI write a Unit Number along with the message and have each subVI only delete the parts written by that subVI. (Messy record keeping). C. Add another boolean to each Unit. Make the boolean True when the message relates to that Unit. (Less space than A and much less messy than B).

2. Rather than one while loop with six state machine-like case structures inside, I would make the Tstat subVIs complete state machines in themselves (with the while loops inside) and make all of them run in parallel with the GUI routine.

3. The DAQ routine would also be in parallel and feed the data to the six state machines via an action engine. You would have several options for separating the data. I do not know how the data is currently configured, so I cannot offer a suggestion on the format.

4. I would change the wait to a method which looks at the tick count and an End of Wait Time passed via shift registers. This will make the system much more responsive to user inputs during the long waits.

Lynn
0 Kudos
Message 49 of 117
(1,268 Views)


johnsold wrote:

2. Rather than one while loop with six state machine-like case structures inside, I would make the Tstat subVIs complete state machines in themselves (with the while loops inside) and make all of them run in parallel with the GUI routine.


The thing is, I tried doing what you are saying, but then the universal stop, for which this discussion was started goes away. I have a hardware start/stop button. On removing the while loop from the main VI, I lose the stop (right at the bottom) of the VI. Is there a solution for that
 


johnsold wrote:

4. I would change the wait to a method which looks at the tick count and an End of Wait Time passed via shift registers. This will make the system much more responsive to user inputs during the long waits.


What exactly do you do for this?
 


johnsold wrote:
1. Your string messages to the user will be overwritten by the various Tstat states in complicated ways which will be confusing to the user. Possible solutions: A. Separate string indicator for each Unit. (Takes space on front panel). B. Have each Tstat subVI write a Unit Number along with the message and have each subVI only delete the parts written by that subVI. (Messy record keeping). C. Add another boolean to each Unit. Make the boolean True when the message relates to that Unit. (Less space than A and much less messy than B).

The same messages need to flash for every unit simultaneously. So do I still need to separate the strings. I did what ravens fan told me.
 
Please help me. I'm super confused and stuck like there's no tomorrow. This project has been going on forever Smiley Sad

0 Kudos
Message 50 of 117
(1,256 Views)