LabVIEW
valves
Thanks for the clarification.
Do you have a method of determining which pipes are sources and which are sinks? And some indication of the direction of flow?
Regarding your code, you do not need to AND the control with its 'new value' element node. You can just wire the control, as its value is read when the event executes. You can easily do away with all the local variables you have used by updating the boolean values outside of the event structure. Lastly your code is all encapsulated with a frame, which does nothing.
Changing the direction of flow, is just a matter of routing gasses through available hardware, or replacing key pieces of hardware. I am not sure what more you are asking for.
Below is a diagram showing a possible way to reverse a pipe's flow. I have shown using 2 way and 4 way valves.
Message Edited by yenknip on 08-05-2008 02:29 PM
Do you have a method of determining which pipes are sources and which are sinks? And some indication of the direction of flow?
Regarding your code, you do not need to AND the control with its 'new value' element node. You can just wire the control, as its value is read when the event executes. You can easily do away with all the local variables you have used by updating the boolean values outside of the event structure. Lastly your code is all encapsulated with a frame, which does nothing.
Changing the direction of flow, is just a matter of routing gasses through available hardware, or replacing key pieces of hardware. I am not sure what more you are asking for.
Below is a diagram showing a possible way to reverse a pipe's flow. I have shown using 2 way and 4 way valves.
Message Edited by yenknip on 08-05-2008 02:29 PM
sir,the real problem is that i don't have a method of determining which pipes are sources and which are sinks. And some indication of the direction of flow.here i attached a image,the pipe may be source or sink at same time.there is a valve between them,if flow comes from left and valve is on the flow will be on right side, and if the flow comes from right and the same valve is on the flow will be on left side,hope that you understands my problem after seeing image now.
thanks for reply
best regards
tanzeel
Oh, I think I may have got the wrong end of the stick. Is it just a simulation, and not a control system? Or at least a visual representation of a control system.
So you want to be able to display which pipes are being used.
The problem you have with using an event structure, is that if you turn on a valve further down the line, then turn on an earlier one, the display will not update properly. What you want to use is a recursive algorithm to follow the open line and update your display at the end.
How complex will the simulation be? Will there be multiple gasses mixing in pipes, leading to sources going into sources?
So you want to be able to display which pipes are being used.
The problem you have with using an event structure, is that if you turn on a valve further down the line, then turn on an earlier one, the display will not update properly. What you want to use is a recursive algorithm to follow the open line and update your display at the end.
How complex will the simulation be? Will there be multiple gasses mixing in pipes, leading to sources going into sources?
How you store your data, is not necessarily how you display your data.
@tanzeel wrote:
its difficult to make this recursive, its real trouble implementing with graphical programing.suggest any LV recursive algorithm.
What I would do is to make an array of clusters (or classes if you are familiar with objects) detailing the properties of a pipe and a tap.
Pipe{int pipeNumber, int ConnectedPipes[ ], int connectedTaps[ ], bool Status, bool Visited};
Tap{tapNumber, int Connected Pipes[ ], bool Status, bool Visited};
Each object has a unique ID - this could be the index of the object in the containing array and could be done away with.
Each object has an array detailing which pipes it is connect to
Pipes can be connected to pipes and taps, taps can only be conneted to pipes
bool Status is the boolean stats of whether the pipe has a flow in it / tap is open
vool Visited is a flag for the recursion algorithm
When the network of pipes is constructed, each instance of a pipe and a tap has a record of which pipes and taps they are connected to.
When a tap status change event is triggered, we start at the gas source and follow reference numbers down through open taps, changing the visited flag and the status to true, until we hit a closed tap. Then recurse back up through the visited nodes until there is an unvisited node below, and follow that path down to a closed node. In practical terms, Each node would probably be better placed on a FILO stack to give a more efficient memory footprint than having the whole network copied in working memory, and also do away with the 'visited' flag.
After we have determined the status of the nodes, we can update the display in one action.
I realise that you will have to do a rewrite of your program**, but given the size you mentioned of your pipes network, this may well be quicker - and definately more elegant - than adding hundreds of events to your already fairly substantial event structure. Lastly, I cannot think of a reason why a local variable would be used anywhere.
Apologies if this was a bit rambling, I tried to keep it concise.
**Addendum
"... rewrite of your program" - but not the time consuming part of redrawing your front panel. Additionally as each pipe and tap should have its own unique name you could put that into the object ID.
Message Edited by yenknip on 08-06-2008 02:35 PM
