Include a large amount of SubVIs in a main VI - labview

I have a large amount (about 50) of SubVIs including beyond some usage specific code a small number of GUI elements (mostly about 2: input and output).
My goal is to reuse those VIs without creating a huge mess in a new ('main') VI and collect all GUI elements on a GUI common pane a user shall finally interact with.
I tried to use the Open VI Function, 'VI Reference' and 'Run SubVi' like in the examples to create references for subpanels, but the subpanel ui is only shown when the program is run and the amount of additional blocks is mostly bigger than the code in the respective SubVI.
The SubVIs should be loaded only once to construct the main User Interface.
In addition: In this tutorial they create a subVI and recreate GUI elements that are already defined in the subVI.
I assume this behaves like passing arguments as in a text based programming languages like the snippet:
def main_vi(x, y, z): # inputs x, y, z
s = sub_vi(x, y, z)
return s # output s
Is this necessary, or can the subvi's GUI controls directly be reused from outside?
Is it possible to use the subVIs inside of an "main" VI that includes everything and maps everything to a common UI using tabs?
Or is it better to copy everything to the main VI, i.e. no code reuse at all?
Thanks in advance!

Depending on the functionality you are going for, yo may want o look into XControls. This would allow you to encapsulate your functionality into a reusable control that could be used on a main panel without making the main panel very messy.

Large UI's can be a pain (pun with pane not intended), especially if there are a lot of controls and indicators. There are some useful ways to break UIs into modular components. XControls are one of those but I don't recommend them due to their unpredictable behaviors. Instead look into working with Sub Panels. There is a great toolkit for this from a company called Moore Good Ideas (or MGI). More info can be found on their website here.
There is also a better alternative to XControls, called QControls. More info on them can be found here.
In general, though, you might want to look into a more modular framework. More info on Frameworks can be found here.

Related

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.

Labview diagram creation API

I need to drive a testbench with labview.
The test scenarios are written in a languages that can be automaticaly translated into labview diagrams.
Is this an API that allow to create "labview diagrams" from another software ? or with labview itself ?
I agree that LabVIEW scripting is one approach, but let me throw out another option.
If you are planning to do a one time migration from your test code to LabVIEW than scripting is great, but if you plan to regularly update your test code (because it's easier to use the "test" language than LabVIEW) than it could become quite painful to constantly perform the migration every time your test code has changed.
I've had great success with simply putting my state machine inside of a for loop and then reading in "commands" from a text file that was generated using my "test" language (see pic).
For example, to do an IV sweep my text file might say something like:
SourceV, 5
ReadI
Wait, 1
SourceV, 6
ReadI
This image is greatly simplified - I'm not using a state machine and I don't show how to use "parameters," but I can provide a more comprehensive example if needed. Again, I've had great success doing this with around 30 "commands" controlling multiple instruments and then I generated the text input using VBA or Python.
It's called LabVIEW scripting. You will need to enable an option in the VI Server page in the options dialog to see the relevant features.
A few things to note:
Scripting isn't complicated, but you do need to be aware of how LV code is built.
While scripting is public, it was initially created as an internal tool. There are still corners of it which are incomplete.
Scripting code can be tedious. If you can get away with it, try creating templates of code.
NI has something called CodeGen, which I believe are a series of functions which make some scripting easier, although I never really looked into it.

How should I organize my vb.net GUI?

I'm refactoring an existing VB.net application that is ~6,000 lines in one file, and I've encountered a dilemma.
On the one hand, I can use visual studio's Data Sources and drag-and-drop functionality to get rid of all the hand-written code that sets up the DataAdapters, DataSets, DataTables, CurrencyManagers and the manually linking between them all.
On the other hand, I can separate the logical pieces of my UI into User Controls.
Now, if I only do the first one, I end up with tons of controls all in the same form, which causes me to have tons of controls in the same 'namespace' that I have to manage, and forces me to write all custom UI logic and event handling in the code behind for the single main form.
If I only do the second one, I get the distinct visual pieces of my UI in separate files, which gives me an appropriate place to write specific event handling and formatting code; but it doesn't let me use the visual studio designer to hook my dynamic components (e.g. DataGridViews) up to the BindingSources in the parent form. The nice thing about this is that I get to set the myriad properties (column width, read-only etc.) in the GUI, which seems like it would make the project much more maintainable.
What's the sensible course of action here? Or is there some possible way to employ both tactics (which is what I would ideally like to do)? I'm definitely looking for some guidance here - I'm a complete vb.net newbie.
Thanks!

create multiple classes with wxFormBuilder for python

I'm using wxFormBuilder to write a series of GUI applications. So far it has worked wonderfully, but the documentation on their homepage is a broken link.
What I'd like to do is combine my programs into one program, each as a different tab in a wxNotebook. However, I can only get wxFormBuilder to generate one class, the class for my frame. Ideally, what I'd like is for each panel to be its own class, so then I can override each class individually, and not be stuck with one giant class which contains all the event handlers for 5 different applications.
Is this possible with wxFormBuilder? Is there a different program which would allow me to do this more easily?
I'm open to other wx programs, but can't departure from Python, and I'd really rather not have to write the wx code by hand.
Some people like wxGlade, Boa Constructor (old) or XRCed (included with wxPython). You might experiment with those. I've heard good things about wxFormBuilder, so I'm a little surprised it doesn't have that capability. Here are some links: http://www.oneminutepython.com/
http://sturlamolden.blogspot.com/2008/03/howto-using-wxformbuilder-with-wxpython.html
http://www.blog.pythonlibrary.org/2010/05/11/wxpython-an-introduction-to-xrc/
Hope that helps a little.

text editor loading multiple large text files - multi threaded

I'm fairly new to VB.NET, and I'm working on a text editor with a tabbed interface. I deal with large text files, so I'm wondering what is the best way to go about this.
Should I have each tab / text document open up in a new thread or a process? I basically want the entire application to always run fast as the text editor is just one part of it. If I have several large text files open I don't want the rest of the application slowing down a bit.
If someone can help shed light on this and maybe point me to a URL with any relevant examples, I'd appreciate it!
Should I have each tab / text document open up in a new thread or a process?
No. Definitely not a new process. The amount of Win32 to put everything back together will make you hate yourself.
Not a new thread either. The Winforms UI runs in a single dispatch thread. Trying to touch the UI from different threads will make your program explode.
I would recommend simply using the tried, true, and boring background worker approach. This can be used with threads or just using asynchronous IO (.NET handles the threading for you). Depending upon your use case you may want to just lazy-load parts of files, you can use memory mapped or random access files (e.g. only read in a very small part of the file at a time). In any case the "data" should be separate from the visualization of said data.
(Emphasis added to search terms.)
Whether you have 1 or 10 tabs open, you will only be able to type/edit 1 file at a time, the other tabs will just be taking up memory in the data structure you define, so not sure how there would be an impact on performance.
As a side note, if you are doing a large amount of string manipulation use the stringbuilder class, far quicker and memory efficient.