Labview programs become difficult to maintain when block diagrams get too big.
Usage of subvis is recommended to avoid this.
By default, every subvi's icon looks the same, except for a number.
I find that the time needed to creating meaningful icons for most subvis exceeds the coding time by far. Even if using existing images instead of that integrated icon editor - first find a suitable one, then I usually have to scale and adapt it.
Even when settling on using just text in the end, the time needed for icon creation still exceeds the time for programming the vi.
I can see the following strategies to avoid wasting time with icon design:
All in one large vi
Not creating relatively simple subvis with less than approx 20 blocks (adjust number with experience)
Just have the default icon everywhere
I do not like any of these. They do not help with maintainability.
It seems there is a trade-off between maintainability and time required for icon design.
How do people with labview experience solve this?
The right way to create VIs anyway.
I would suggest adding all VIs into a single library then change the icon of the lib to one you like and click the Apply Icon To VIs. This will add the Library Icon to all library functions like a template.
Then you can use VI scripting to programmatically add text on VI icon (For ex. VI Name): http://sine.ni.com/nips/cds/view/p/lang/en/nid/209110
I suggest you take a look on this: https://lavag.org/files/file/100-mark-ballas-icon-editor-v24-lv2010/
It will show you how you can write text on a VI's icon programmatically.
Install GOOP Development suite:
In the menu, click:
Tools->GOOP->Create VI Icon...
Then click 'accept'. 95% of the time, this is appropriate.
The other 5% of the time is used to set up headers based on
library/class/folder
Then GDS offers to update the headers for the other member VI's.
The LabVIEW help includes some simple instructions for creating an icon template and then using that template to create an icon for each new VI you create. I really don't see why either of those steps should take you more than about fifteen seconds!
There's certainly no need to be an artist, or take too much trouble over it, to create a VI icon: all that really matters is that each VI icon is:
identifiable as part of your application - this is why to use a template; and
distinguishable from the other VI icons in your application - you can easily do this with a couple of words of text or a glyph from the included set, even if you choose the latter at random.
Related
I have written an app that makes extensive use of custom right-click menus on an Access form. The code works great and the user loves it, but lately I am having trouble making it work properly.
In earlier versions of Access it worked well, but newer version seem much more limited in how many items can be put in such menus. The documentation is silent on the matter, and nobody in any newsgroup has had any useful ideas, but I regularly get random error about stack space, out of memory, and general lockups when populating the menus. Doing a C&R used to help, but now even that is not enough, and some menus I can no longer populate at all.
I tried building an app that just built menus until it crashed, to get some idea of what the limits may be, and I am well below what that indicated, but the experimental app had nothing else, while the real app has a great deal else.
Is there any information on how much stuff can be put into these menus, and what the menus share space with? There may be something I can do another way to make more room for the menus. I tried moving all code out of the form, leaving only event stubs that called routines in standard code modules, but that did not help.
And how are they stored/activated? The app is MUCH slower to load when it has these menus, even though no code is running on start-up.
********** Edited to add this:
I use VBA to create a menu, like this:
Application.CommandBars.Add "RCStat", msoBarPopup, False, False
then add it to a control. like this:
Application.CommandBars.cboStat.ShortcutMenuBar = "RCStat"
I add controls (only popups and buttons) like this:
Application.CommandBars.Controls.Add(type:=msoControlPopup)
Application.CommandBars.Controls.Add(type:=msoControlButton, Parameter:="StatKod = 77")
It runs perfectly and the menu items work exactly as expected, except that it bombs after adding some number of controls. It doesn't seem to matter where I add them, just the total number of added controls hits some undefined threshold, and the app crashes.
I got the original code from Getz, Litwin and Gilbert, 2000 edition. Back then, it worked great. But as the versions advance and the app accumulates data, it is becoming less and less functional. However, there are only around 10,000 records, and the app itself is less than 100MB - nowhere close to any of Access's upper size limits.
Pete,
I've done quite a bit of work with shortcut menus, and created the Access Shortcut Tool about 5 years ago, but have never attempted a menu with so many controls although some have 3 or 4 levels.
I am not aware of any restrictions on the number of elements in the commandbars collection, but I find that shortcut menus with too many options, like lists and combo boxes with too many items, are difficult for users to navigate. I generally break these up into segments and use buttons in the form header to display the appropriate menu. Sorry I'm unable to provide anything more helpful.
Dale
We have a commercial product, Total Access Components, that includes as one of its 30 components a right click popup menu that can include icons and font styles.
Here's the info for the popup menu control: https://fmsinc.com/MicrosoftAccess/controls/components/popup-menu/
There's a free trial if you want to try it.
I've written LabView code for a locking system.
The lock has a motion timer that relies on input from a numeric control. I've added a script file reader that needs to be able to change that timer value. Using a selector, I can switch between values, but I'd like it to update the value in the control, rather than override it, so that I can see it on the screen.
How can this be accomplished?
This is currently how I switch between the scripted version and the direct numeric input from the control:
So how can I get the script value to update the control box or is that not possible...?
Do you mean something like this? I created a little vi to demonstrate how the control is updated.
In most cases "property nodes" are the way to go. Every control has a lot of different options to chose from and usually if you look through the properties you will find what you're looking for :)
A little hint:
If you want to add "code" to your question so that other users can test it, you can create a .png file. To do this, you need to select the parts of the vi that you want to share, and click on "Edit > Create VI Snippet from Selection". Then you save that generated .png and upload it here as a picture. Then others can drag&drop it into their block diagram.
Important: Check the .png before uploading and make sure that you're not accidentally posting sensitive data of your company.
I am learning French. Every time I use the Force Click on my Mac on a word I don't know, I get a dictionary entry and a translation to English.
But when I want to translate a whole sentence, I have to open Google Translate to do so. (1. Open Google Translate. 2. Copy sentence 3. Paste Sentence) It is pretty annoying to do that 20-30 times a day.
So is there a way to expand the capabilities of Force Click in Safari (or in the best case, in every application which allows "Look Up")?
Let me worry about how I can translate the sentences.
I am open for any kind of creative solution.
Here is the standard pop-up when I force touch
I don't think there is a documented way to achieve this on a force click, but you may want to look at Services.
Basically, you can create an application that provides a service, select some text, and then choose your application's Service menu item from the Services submenu in your Application Name menu (the one in bold where "Hide" etc. are).
The service will then receive a copy of the selection (in an NSPasteboard) and can do whatever it wants with that, or even change it.
I'm using Dymola but I expect OpenModelica might very well be the same (or at least similar).
For a given component model sometimes it makes more sense to have lots of parameters shown on one "tab" of the parameter GUI. This can lead to an excessively long GUI which, for many reasons including for psychological reasons in relation to how humans process information, is not a appropriate solution.
To solve this I would like to add a vertical scroll bar on the parameter GUI. I believe I saw it once though I cannot recall exactly where.
For illustrative purposes look to the right side of your web browser window. That gray bar that goes up and down is the scrollbar :). I know, obvious but you never know.
I assume I need to put some command in an annotation somewhere though where and what command I am not sure. For example, I found some reference to a verticalScrollBarPolicy but alas, I can not find any documentation on this.
Anyone know how to do this?
EDIT #1:
Dymola (and Adrian indicated OpenModelica as well) will automatically create the scroll bar when the GUI gets larger than the screen. Unfortunately (at least in Dymola) there is little margin so if you GUI is a fraction smaller than the window the "OK" button will be covered by the ribbon on the bottom of the screen and the GUI will be needed to made slightly larger to make the scroll bar appear automatically. This is a reason why a manual option for a scrollbar would come in handy.
I think additional "tabs" might help?
As far as I know in OpenModelica we have a scroll bar for that dialog windows if the window would expand out of the screen.
As of this posting my understanding based on feedback on this forum, my own experience, and from additional discussions with others there is no current manual control of the GUI (i.e., size, scrollbars, etc.).
Your best bet if you come across issues (e.g., you have a super small 2nd monitor) is to use lots of tabs and keep descriptions very short (which is probably appropriate for most applications anyways).
This is a Dymola and OpenModelica issue not a modelica issue as it is not contained in the modelica specification (as I understand it).
If this changes and I find out about it I'll remove or update this post.
What is the best way to understand a complex LabView VI that controls a motor?
My goal is to control the motor from a joystick.
The wiring diagram shown below allows a LabView user to control the motor from the LabView GUI: move a slider up and down either increasing or decreasing the desired velocity. As the slider's value changes, it is fed into a bunch of math controls and eventually gets converted into a command string for the motor to interpret. This command string, if I understand correctly, is bunch of bytes that get written to the serial port.
Instead of using the LabView GUI to control the motor, I would like to use the joystick.
What is the best way to approach this?
The joystick has pitch,yaw,roll,and throttle. Which one relates best to the velocity of a motor?
The answer to your title "What is the most efficient way to quickly understand how a complex LabView VI works?" is probably to do some combination of the following:
Look at the VI's inputs and outputs to try and understand what they are there for. The label and caption of controls and indicators may be helpful, also right-click to check the description and tip.
As well as controls and indicators, look for other I/O: queues, notifiers, global variables, file read/writes, instrument communications, and for any data storage that persists between calls such as an uninitialised shift register.
Look at the overall structure of the VI to see how it executes, e.g. is it a one-off operation, does it execute different cases depending on some input, does it loop until a certain condition happens, does it use a state machine structure, etc
Break down the VI's structure into smaller pieces that you can understand. You could print the diagram out and annotate it by hand, or add frame decorations and text comments to the diagram to record what you deduce. If the diagram is cluttered or poorly laid out, rearrange it as you go along (use Ctrl-click and drag on the diagram background to add blank space where you need it).
Set probes on key wires and watch them while the VI runs to see what happens
If possible, manually set the VI's controls to example values and run it to see what happens (this may not work if the VI depends on other parts of a program running at the same time)
Write a test wrapper VI that calls the complex VI and supplies it with example data or inputs to see what happens.
To address your specific question about the VI diagram you've posted, I can see various controls for quantities such as Velocity, Position, Amplitude, Max A (amplitude?), Frequency and so on. You need to decide which of these quantities should be controlled by which axis or output of your joystick. Then you need to add code that reads those values from your joystick, and modify the existing code so that the parameters you want to control are supplied by the joystick values instead of the front panel controls. You could probably just put the joystick reading code inside the existing loop, wire the joystick outputs to join up with the wires from the front panel controls you want to replace, and then change the relevant front panel controls to indicators from the right-click menu so that they will show the values you are getting from the joystick.
The best way is to write one from scratch. But you could analyse the code by clicking the Highlight Execution button to display an animation of the block diagram execution when you run the VI, and use probes to check intermediate values. And you probably should also do an on-line course, e.g. LabVIEW Training: Learn LabVIEW in Three or Six Hours
My answer to your third question is "throttle.".