LabVIEW
array to global array
krispiekream wrote:
hahaha, why is that?
too many local variables?
oh yeah..can someone show me how i can do the same work without using the local variables?
thanks
Use wires and shift registers. As a result, you may even be able to eliminate some sequence structures, or at least some frames as you won't have to enforce data flow manually. Anywhere you have a terminal that is sitting unused on the left for either a control or an indicator is a candidate to be moved somewhere to eliminate at least one local variable.
I won't go so far to say as you will be able to eliminate all local variables, but there's a chance.
Message Edited by Ravens Fan on 03-27-2008 06:00 PM
krispiekream wrote:
oh yeah..can someone show me how i can do the same work without using the local variables?
Attach your program.
Actually, it won't be the "same work" without locals, it will just be the same result with much less work. 😄
okay, forget about the previous situation..i guess i can work with what i have..
so i have an array of 9 elements...
the way my program works..
i run test on 9 elements on pressure 730.
i find out the offset and save it into an array...
how do i take value from 1 array and place it in another array (string)?
for instant, i want to insert the offset of 7 coming from the last element, into the string array....
then offset 0, 28, etc...
in the end of my test, i want to fill up the devices global array with reading/press values
Message Edited by krispiekream on 03-27-2008 07:19 PM
krispiekream wrote:
my program is attached in the previous reply
thanks
Hi krispiekream,
You need to attach all your remaining missing SubVIs & Globals also. 
Then only somebody will be able to see n understand to modify it with less or no locals.
You can attach upto 3 attachments only at a time.
Do these, then we ll do it for you.
Hi krispiekream & partha,
you can attach (much) more than 3 files when you use ZIP! May reduce network traffic too
you can attach (much) more than 3 files when you use ZIP! May reduce network traffic too
krispiekream wrote: my program is attached in the previous reply
Sorry, I missed that somehow. Unfortuntely, I no longer have LabVIEW 7.0, so it won't help you much. We don't really need the subVIs, because the VI could be refactored without them.
Here are some general guidelines what you could do:
- Get rid of the breakpoint you have set (look for the global with the red outline)..
- Use one single main while loop that is smaller than your screen.
- Get rid of the sequence structures. The execution order should be determined naturally from the dataflow.
- Your subVIs have "error out" terminals. Add also "error in" terminals so the error cluster can be used to force a certain execution order if needed.
- Many times you seem to needlessly force an execution order. This only prevents things that could run in parallel from doing so.
- The "GoodValue" local variable and indicator seems rather useless, because as soon as it turns true, the VI stops nanoseconds later.
- Since the VI does not stop under any other condition, the fact that the VI has stopped gives you all the information.
- You seem to believe that it is not allowed to wire across structure boundaries. For example you read the "offset" with a fresh instance of a local variable in multiple cases of a stacked case structure. You could just wire directly from the source where you extract it from the global to all of them via an input tunnel.
- Mind your data representations. For example the offset is I16 in the global, U16 in the indicators, and DBL once you merge it onto the "devices" array.
- If there is never a "good value", you VI can never stop. What now?!
- Use unbundle by name for better self-documentation.
- What determines the loop rate?
- ...
- ...
(this is just the tip of the iceberg!)
Here it shows part of your last three frames. The sequences are not needed if you use correct dataflow.
You don't need to wait until the number is incremented before reading another instance of the "good value" local.
The two readings from the local variable will occur within nanoseconds of each other and I pretty much can
guarantee you that they two readings are highly correlated. Why read from the same local twice in a row?
All you need is wire from the inside of the previous case. 😄
Here's one possible way how you could architect the same code.
Of course I left out many things, but it shows the main design to eliminate local variables. Keep things in shift registers!
Instead of "read local... modify...write local", just operate on the shift register value directly in memory as shown for the
devices array and the device index. Many times you don't even need the indicator any more, except for troubleshooting.
Message Edited by altenbach on 03-28-2008 10:01 AM
