Create subvi from output of loop - labview

Labview is very frusturating to me having used C/Java before.
I have a simple problem I dont know how to solve.
My program does some operations in a loop and updates an indicator inside the loop. I would like to make this loop (and the inputs it requires) into a VI but I have no idea how to make the indicator an output of the VI.
I would like to be able to reuse this VI, connect an indicator to it, and have it automatically update without creating any loops outside of the VI.
In C I would be able to do this by either returning a pointer or passing by reference to a function.

Use a queue to move data between loops in block diagrams.
The producer/consumer pattern uses a queue to move the data between two loops on the same diagram, but a queue is global to a VI hierarchy and by naming it when you create it, a second VI can obtain a reference to it by using the same name.
NB: queues are 1:1 and lossless; if you need 1:N data transmission, use a notifier (which is newest-value lossy) instead.

In LabVIEW while loops have simple condition. The value can go outside the loop only when we will meet the condition. There is a condition terminal in the right down corner of the loop.
At general:
1) When true flag will be set there (stop if true) then the value will be passed outside the loop.
2) When the false flag will be set there (continue if true), then the value will be passed outside the loop.
3) You can always use error wires with condition terminal inside the loop, when error will be raised, then loop will stop.
In your case:
Always try to use the smallest amount of while loops as it is possible due to optimalization reason.
1) You can use while loop in your main VI, while all SubVIs will be in this loop and all values (indicators) will be updated.
2) You can try using while loops inside subVIs, but then you have to provide mechanisms that will transport values outside the loop such as queues or local variables

You can make a reference for a labview indicator as well, but you would need to make it a global variable or pass in the reference from the calling vi.
As for your frustrations, you should know that you can pretty much do anything in Labview that you can do in C.

A) The image below shows how to do this.
B) This style of programming works in small applications, but as an application grows larger, I would encourage you to explore an actual architecture for producing data in one hierarchy and consuming it in another (as alluded to by other answers to this question). In particular, do File >> Create Project and choose the Producer/Consumer template to explore a good starting point for such architectures. There are more sophisticated ones, but that makes an excellent beginning.

Related

Labview Program changes behavior after looking at (not changing) the Block Diagram

My Labview Program works like a charm, until I look at the Block Diagram. No changes are made. I do not Save. Just Ctrl+E and then Ctrl+R.
Now it does not work properly. Only a Restart of Labview fixes the problem.
My Program controls two Scanner arrays for Laser Cutting simultaneously. To force parallel working, I use the Error handler and loops that wait for a signal from the Scanner. But suddenly some loops run more often than they should.
What does majorly happen in Labview when I open the Block diagram that messes with my code?
Edit:
Its hard to tell what is happening without violating my non-disclosure agreement.
I'm controlling two independent mirror-Arrays for Laser Cutting. While one is running one Cutting-Job, the other is supposed to run the other Jobs. Just very fast. When the first is finished they meet at the same position and run the same geometry at the same slow speed. The jobs are provided as *.XML and stored as .net Objects. The device only runs the most recent job and overwrites it when getting a new one.
I can check if a job is still running. While this is true I run a while loop for the other jobs. Now this loop runs a few times too often and even ignores WAIT-blocks to a degree. Also it skips the part where it reads the XML job file, changes the speed part back to fast again and saves it. It only runs one time fast.
#Joe: No it does not. It only runs once well. afterwards it does not.
Youtube links
The way it is supposed to move
The wrong way
There is exactly one thing I can think of that changes solely by opening the block diagram.
When the block diagram opens, any commented-out or unreachable-code-compiler-eliminated sections of code will load their subVIs. If one of those commented out sections of code were somehow interfere with your running code, you might have an issue.
There are only two ways I know of for that to interfere... both of them are fairly improbable.
a) You have some sort of "check for all VIs in memory" or "check for all types in memory" that you're using as a plug-in system. When the commented-out sections load, that would change the VIs in memory. Such systems are not uncommon when parsing XML, so maybe.
b) You are using Run VI method for some dynamically invoked VI to execute as a top-level VI, but by loading the diagram, it discovers that it is a subVI of your current program. A VI cannot simultaneously be top-level and a subVI, so the call to Run VI returns an error.
That's it. I can't think of anything else. Both ideas seem unlikely, but given your claim and a lack of a block diagram, I figured I'd post it as a hypothesis.
In the improbable case someone has a similar problem. The problem was a xml file that was read during run time. Sometimes multiple instances tried to access it and this produced the error.
Quick point to check: are Debug and "retain data in wires" disabled? While it may not change the computations, but it may certainly change the timing of very tight loops, and that was one of the unexpected program behaviors, OP was referring to.

Cloning partially solved MIP and keeping current B&B tree

I would like to partially solve a MIP, clone the problem and have that copy of the problem continue optimization but with a different strategy (node selection rule, variable selection rule, etc), and keeping the current branch-and-bound tree. I know that this can't be done with either CPLEX or Gurobi, since they would start optimization from scratch in the copy.
Is there any way of doing this with SCIP?
I would really appreciate any help.
Best,
Rodolfo
If you don't insist on having a copy/clone, you always have the possibility to code your stopping criterion in terms of an event handler. I am sure you know our How to on adding event handlers.
There is also an event handler in the scip source code, the so-called soft time limit event handler src/scip/event_softtimelimit.c. There you can find sample code that changes the time limit after the first solution has been found. Parameters can be fed one by one by using the SCIPchg{Real,Bool,Int,Longint,Char,String}Param() methods in the code, or passed as a settings file, which might be easier if you want to change lots of parameters without adapting the code each time.
It is good practice to use settings files saved via the set diffsave command, which saves only the nondefault-settings. Otherwise, using a complete settings file, you might run into troubles because a time limit or memory limit gets changed without control.
A copy that includes data structures such as the tree used during the branch-and-bound solving process is currently not possible. The copy-mechanism of SCIP only allows to copy the problem as a whole and adjust the formulation by changing variable domains and/or objective coefficients.

Labview 2012 Passing Dynamic data into/out of a while loop

I'm trying to pass data which is continuously changed from the inside of one While loop to the inside of another While loop of a sub-vi. The main program on the left is constantly reading new data and the program on the right is adding 1 to the new value. My issue is that I cannot input new values to a While loop which is already running and thus my sub-vi is never updated. I've tried a global variable ("write" from the main program control and then "read" into the sub-vi) but that doesn't work either (same result as if the main were just passing data into the sub).
I apparently don't have enough reputation to post a picture of my program but I'm basically trying to run parallel loops (almost inside each other). Can anyone lend me an experienced hand?
The most common problem with while loops are based on lack of knowledge how exactly does the while loop work in LabVIEW.
First of all the information will be given outside the loop only if the condition terminal (right down corner of the loop) will be flagged as true.
If you want to pass the data earlier (while the loop is running) you have to choose easiest option:
Use queue (is the most common and well working). I can elaborate how this one work in practise if you want, or just try to run an example from LabVIEW help.
local/shared variables - you can define in your own library variables and pass the data by READ/WRITE option.
Please try to upload some documentation to an external server (as you are blocked here), and post a link, and then I could help you with a specific example.
Help»Find Examples. Search for "queue". Pick out an example with parallel loops.
You might want to look into Queues or Notifiers as means of passing data between running loops.

Labview: creating subVIs makes the Block Diagram expand

I wrote a rather complicated piece of code in Labview (with many loops and other sequences). Therefore I want to create many subVIs to make my code more clear.
When I have a loop in the code I want to have in a subVI, the icon of the newly created subVI appears far away form my original piece of code, causing my Block Diagram to expand.
Why does it happen and how can I avoid it?
The piece of code I want to turn into a subVI:
The same fragment of my Block Diagram after I created the subVI:
And here is my newly created subVI - approximately 1 m to the right at 1 m down in comparison with the first piece of code:
Thanks for adding images -- that is quite an inflation of the block diagram.
I don't know why LabVIEW is behaving that way, but my guess is that the control and indicator references are contributing.
As for ways to prevent it from happening, aside from refactoring the code (which is likely necessary anyway), you can try turning off automatic wire routing: Tools » Options » Block Diagram » Uncheck 'Enable automatic wire routing'.
Avoid creating subVIs that contain terminals in a structure
However, to move the block diagram's complexity into a sub VI will require some refactoring because you want to include a while loop that changes behavior based on front panel input (like the stop abs 2 boolean button). Otherwise, whatever value stop abs 2 has when the new sub VI executes will not change while it's running.
The LabVIEW Help reiterates this point: "Because the terminal remains on the original block diagram and the terminal is wired to the new subVI, the subVI does not update the value of the terminal on every iteration of the loop inside the subVI."
Here is an illustration.
Communicating with running subVIs
To send input and receive output from a sub VI while it is executing requires some data synchronization like queues or notifiers. Typical design patterns for this include:
Producer/Consumer on the targeted and simple side, to
Queued Message Handler in the middle, to
Actor Framework on the general and complex side.

How to find or create the iteration number box in a For loop

I have a large, somewhat messy For loop in which I can not find the iteration number box. Is there any way of searching for this component or simply creating a second iteration number box?
You can't create a second iterator terminal, but you can use scripting to move the iterator to a typical location (bottom left) with this VI Snippet.
Be sure the file is open before running the script.
This is a bit of a gamble, but you can try the Clean Up Diagram tool and see if that helps. If it doesn't it should still expose the iteration icon, and you can find out what wires it is connected to. Hit Ctrl-Z to undo the clean-up, and double click on the wire indicated previously and it should expose everywhere the wire routes to. Hopefully you can track it down then.
A messy diagram means that sub-vis or an architecture re-design is badly needed.
Depending on what version of labview you are using, you can use Block Diagram Cleanup tool, as mentioned by Austin. But you can also highlight a section of code and clean that up individually. This 'selective cleanup' feature was introduced in 2012.
Regardless, you can't search for an iteration counter. Use your eyeballs...how bad could this for loop be? Hint hint: I want to see it :-)