Automatic resizing of controls on block diagram

Hi,
I have control as strict type def and many instances (on block diagram) of this control in several VIs. When I add new element in this control all instances resizes to maximum size and that corrupt layout on block diagram because all structures resizes with that instances. Is there a way to avoid that?
Thanks, andrej

Place it on the front panel of a subVI as an output. Then call that subVI whenever you want the typedef.
You can find more on using typedefs here.
Try to take over the world!

Similar Messages

Edit menu control from block diagram

On my front panel I have a menu control that lists the existing file folders for saving the test data. If the operator want to add a new folder I want the Block diagram to write a new folder and add the entry to the menu control list.

What I would suggest is that your menu have a selection called "New", then if the user selects this, the file dialog would pop up and allow the selection of a new folder. Using a property node, write the new path to the Strings[] property to update the list. At the end of the program, you could write the list to an ini file to save the new list. You would also want to read this ini file when the program starts and write the list to the Strings[] property.

My scrollbars disappear when resizing my LabView8.6 Block Diagram window

My design can't be seen in it's entirety within the Block Diagram window so I need to use the vertical and horizontal scrollbars to navigate the design. The scrollbars disappear if I resize the Block Diagram window past "some point". If I shrink the window very small, the scrollbars reappear. Other programs I've generated don't seem to have this problem. Any suggestions?

Hi,
Check the scrollbars settings, right click on vertical/horizontal scrollbars and change the settings. If the problem still exists, U can send me ur vi, let me have a look to know the exact problem.
regards
sunil

Delete controls from block diagram in LV2009?

Hi,
I'm missing that "delete/copy panel terminals from diagram" option of older LV versions (see attached pics)...
Where is it hiding or is gone for ever? I really miss that feature...
Best regards,
GerdW
CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
Kudos are welcome
Solved!
Go to Solution.
Attachments:
BlockDiagramOptions_LV71.png ‏11 KB
BlockDiagramOptions_LV86.png ‏22 KB

GerdW wrote:
Hi Ben,
thanks for the link. Actually I set this key to "True"
And this change isn't mentioned in the "LabView 2009 Features and Changes" document that opens from the LV start screen
Message Edited by GerdW on 08-21-2009 04:26 PM
That is where I stumbeld across it.
About a third of the way dwon under the section labeled
Options Dialog Box Enhancements >>> 6th bullet down reads "Rarely used options no longer exist in the Options dialog box. Refer to the Knowledgebase for a list...."
Clicking on the "knowledgebase" link took me to the page I linked previously.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Type defs changes not reflected in block-diagram constants?

I'm struggling with strict type-defs today.
If I create a strict type-def, say of a cluster with an enum in it, and save it. Then create a block-diagram constant from the strict type-def in a blank vi. Then make changes to the strict type-def (say, add another item to the enum), the block-diagram constant ghosts out , as it should. If I then select "Apply changes" from the strict type-def menu, the ghosted block-diagram constant becomes un-ghosted, as it should. BUT, it hasn't update!? If I look for the new item in the enum, it isn't there!? I'm sure it should be, right?
No changes that I'm making to my type-defs or strict type-defs are being reflected in my block-diagram constants (which are definitely still linked to the controls with "Auto-update from type-def" checked on). It does work for front panel controls and indicators though - just not block diagram constants.
I'm using LabVIEW 8.5.1, Win XP Pro. Any ideas anyone?
Thoric (CLA, CLED, CTD and LabVIEW Champion)

Solved. I think.
I tried a range of type-defined controls, including an enum, a ring list, a cluster with an enum inside it, and a cluster with a ring list inside it.
Changes to the enum items were reflected in all vi controls and block diagram constants.
Changes to the ring list items were not reflected in the controls or block diagram constants.
This snapshot shows the the last item available in each ring and enum list. Clearly the rings were not updated when the custom controls were. (Yes, I applied changes and saved too).
Switching to strict type-defs only impacted the front panel controls, as Ben highlighted, because this is GUI related. You can see from this second snapshot where all type-defs are now strict type-defs that all enums and rings updated to reflect all three items, but the block diagram rings are still out of date
I expect somebody will tell me now that this is normal behaviour???
Message Edited by Thoric on 09-10-2008 02:31 PM
Thoric (CLA, CLED, CTD and LabVIEW Champion)
Attachments:
custom_control_test.jpg ‏53 KB
custom_control_test_stricttd.jpg ‏54 KB

Opening VI block diagram engaging remote instrument control

This is a phenomena that doesn't seem to cause any major functionality issues - but I'm still curious how opening the block
diagram window of a VI can automatically engage remote control of any
connected instruments that are powered up - even when the VI itself is
not running? The only problem I have with this is if manual control is needed prior to running the VI.
Has anyone else encountered this issue?

What, exactly, causes the "REMOTE" indicator on your device to come
on? It looks like if you have any VISA resource objects on your
block diagram and open the block diagram, LabVIEW searches what devices
are out there. I would be surprised if your instruments reponds
to a simple query by going into remote mode, but that may be what's
happening. Can you check the manual for your instrument to see
what commands put the device in the remote state?
Robert Mortensen
Software Engineer
National Instruments

Automatically open block diagram on extended monitor?

Hello,
I was wondering if anybody know how to pop-up the block diagram on an extended monitor automatically so that ctrl+E need not be pressed to shift between FP and BD. It would be nice to see FP on monitor 1 and BD on monitor 2(ext). applicable to opening any number of VI/subVIs. (not needing to drag window to ext monitor either)
Thanks in advance,

See page 2 of this thread: http://forums.ni.com/ni/board/message?board.id=170&thread.id=102680&view=by_date_ascending&page=2

How do I get the Label for a Front Panel Control to appear in the Block Diagram but not on the Front Panel?

How do I get the Label for a Front Panel Control to appear in the Block Diagram but not on the Front Panel? On the Front Panel I am making a complex control that consists of a Slider and a Numerical Input box. Both Controls display the same information and either can be used for Input. When one changs, the other is made to display the same value.
But I only want the Slider to display the Label on the Front Panel, to avoid confusion. On the Block Diagram however, I want both controls to display their Labels so that I know what they are. How do I display the Label for a Control on the Block diagram, but not display its Label on the Front Panel?

No. The Label Visible property is separate for the front panel control label and the block diagram terminal label.
How did you start out with the block diagram's label not being visible? Whenever I drop a control or indicator, the label is always visible on both the FP and BD by default. Maybe there is a LabVIEW option that causes new controls/indicators not to have their labels visible by default, but I have yet to find it. I don't think an item should ever be dropped without the label visible, good LabVIEW coding practice demands that the labels for control terminals on the block diagram be visible so that you know what control or indicator a wire is going to.
That being said, I have seen a lot of VI's posted where the label for the terminal on the BD is not shown (against good programming practice.) I've gone to the BD and right clicked to show the label. Sometimes, the people have an empty label (which will turn off the visibility for both the FP and BD) and I'm forced to add some text of my own into the label so I can figure out what their code is doing. When I add some text to the label, at that time, I find both the BD and FP labels become visible.
Are you dealing with controls that have empty labels to start?
Good programming practices:
1. Always have a name for all of your controls, never use and empty label by deleting the text in the label.
2. Make the labels unique. For example, don't have two controls both called Stop. How do you know quickly know which terminal relates to which control?
3. Always show the labels on the block diagram, so you know the function of a control's terminal. If you want to hide the label on the FP, that's okay.
4. If you want a different label to appear on the FP than whatever you actually called the control, then use the caption. You can hide the label and show the caption. This is useful if you need to programmatically change what the "label" is on the front panel such if you are making an application that needs to change its user interface such as for a foreign language.

'Control terminals on connector pane not on top level block diagram.' comment on CLD report

Hello All
Could anybody enlighten me please , what does that comment mean on CLD report
'Control terminals on connector pane not on top level block diagram.
Does it mean that some terminals are hidden within some case structures and not showing on block diagram without going into case structures or by 'top level block diagram' it means
main.vi and controls on main.vi must also be connected to its connector pane?
Thank you
K.Waris
Solved!
Go to Solution.

For one thing it means that they run VI analyzer on your VIs since that is a verbatim warning that you receive. It simply means a terminal which is wired to the ConPane is not on the top level diagram, ie. inside a case structure.
As to why it is often not a good idea to do this read this classic thread:
http://forums.ni.com/t5/LabVIEW/case-structure-parameter-efficiency/m-p/382516#M191622

Set label to appear to the right of control/indicator in a block diagram

Hello,
I'm just wondering if there is anyway to set the preference in how label of a control/indicator to appear to the right of the control in a block diagram. I'm doing a lot of routine copying and pasting of controls and indicators, and the labels always appear at the top of the controls/indicators. Thanks for the tip.
Peter

Peter Parker wrote:
I'm just wondering if there is anyway to set the preference in how label of a control/indicator to appear to the right of the control in a block diagram. I'm doing a lot of routine copying and pasting of controls and indicators, and the labels always appear at the top of the controls/indicators. Thanks for the tip.
If you copy&paste a control, the label will jump back to the default location for the pasted control.
There is a better way! It makes copying a control faster and retains the label location:
select the control you want to copy
hold down the [ctrl] key and drag the terminal to a new place.
You will have a copy of the original control at the new location and the label position is the same.
(Darren would probably call that a Nugget© )
LabVIEW Champion . Do more with less code and in less time .

How do I automatically make new front panels and block diagrams a certain size and screen position, like able to fit on a 1024 x 768 screen?

I'm studying for the CLD and I notice that one of the requirements is this:
Develop block diagrams to fit a screen resolution of 1024 x 768.
When I create a new VI, its resolution is slightly too big: 1110 x 768.
When I create a subVI via the menu item Edit >> Create SubVI, it is way too small: 800 x 543.
For both methods of creating new VIs, I would like to specify both the screen position and window size. But if that is not possible in LabVIEW, I'd like a quick way to make this happen. I see some property nodes for VIs where I could write a subVI that could do this for the front panel, but that is awkward. And it does not apply to block diagrams.
Is there a clever way to do these things?

bmihura wrote:
I'm studying for the CLD and I notice that one of the requirements is this:
Develop block diagrams to fit a screen resolution of 1024 x 768.
When I create a new VI, its resolution is slightly too big: 1110 x 768.
When I create a subVI via the menu item Edit >> Create SubVI, it is way too small: 800 x 543.
For both methods of creating new VIs, I would like to specify both the screen position and window size. But if that is not possible in LabVIEW, I'd like a quick way to make this happen. I see some property nodes for VIs where I could write a subVI that could do this for the front panel, but that is awkward. And it does not apply to block diagrams.
Is there a clever way to do these things?
It doesn't mean the default size of the window. It means once your code is complete, your block diagram should be small enough that you can see all your code when its on a monitor of that resolution. Before you test, set your computer monitor resolution to 1024x768. Write your code. If all the code on your block diagram can be seen without scrolling, you will be fine. They won't measure this explicitly. They are basically just saying "you shouldn't have a huge block diagram."
CLA, LabVIEW Versions 2010-2013

Can't see block diagram of an auto-running VI

Hello,
I have an old and dirty VI that runs automatically when opened. I cannot see the block diagram because when I stop it, LabVIEW shuts down. There is probably that 'evil' function Stop LabVIEW at the end.
Is there a way to avoid that behavior?
The VI was written a while back in LabVIEW 7.0.
Thanks for the help!
Vincent
Solved!
Go to Solution.

LV_Pro wrote:
One other possible trick to stop the vi without it exiting might be, on Windows machines, to do a "Ctrl ." (holding the CTRL control key while pressing the "period" key)
Not sure there was a "Book X", don't think the Greeks used Roman numerals! ;-)
I have actually seen cases where this doesn't work. Most of the time it happens when in a producer/consumer architecture where the exit logic is not correct and the loop with the event structure exits and the consumer is waiting for something to happen. I was aware of the "Ctrl ." abort but have been forced to kill LabVIEW because the abort wasn't processed.
Mark Yedinak
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot

Bug with block diagram labels in 2013

I just reported a minor but interesting bug with the block diagram free labels in LabVIEW 2013. If you attach a free label to a structure of any kind using the gluph in the bottom right corner of the comment then resize the structure in the direction of the comment it causes the entire block diagram to resize in that direction.
Kelly Bersch
Certified LabVIEW Developer
Kudos are always welcome

kbbersch wrote:
I would disagree that the behavior is expected. If the comment is not immediately next to the structure, but is a distance away, the block diagram does not resize if the comment is not attached to the structure but it does resize when the comment is attached. I would expect the attachment arrow to simply get shorter unless the structure is resized so large that the comment has to move so as not to interfere.
Expected behavior? Nobody expects the Spanish Inquisition.
I am afraid the problem here does lie with your expectations. When you resize a structure and the new space is occupied by anything other than wires then LV will use "Make Space" to create room. Make space obeys neither the laws of man or nature, it simply gets the job done with all the subtlety of a steamroller. I believe if there is something preventing Make Space from doing its job then NI engineers are automatically dispatched to your office with sledgehammers to fix the problem.
I do, however, share your wish for a world where you do not expect LV to wreak untold havoc on your BD when attempting to make space or "clean up". Here they should probably treat the connecting arrow more like a wire and less like a rigid object. I'd say bug myself.

PXIe-5663e block diagram

Hello,
I have a question regarding the block diagram of the VSA 5663e, in particular of the 5601 RF Downconverter (see attached file).
There is an amplifier that can be switched on, but I can't find any means of controlling this PA manually. Is it meant to be a preamplifier?
Is this PA switched on automatically by software? If yes, under what conditions? There seems to be no way to retreive the status of the PA from the instrument.
Thanks
Attachments:
5663e.png ‏50 KB

HI HansAnders,
the only thing you can direclty set is the reference level. You should use the smallest possible level you can (depending on your signal).
Than you have the possibility to change some other settings, so the amplifier will be turned on (or off). I have here two documents which explains how to do that:
Attenuation of the 5663
Downconverter Gain
Unfortunatly I dont have any information about when it is turn on exactly. So this you will have to try. But you will see when you set the attenuation on manual and to zero your noise will be reduced.
I hope this helps,
RMathews

Growing block diagram objects

Recall that with objects on the Front panel, one can select and move them in very small increments by using the control arrow keys.
Is there a way on the block diagram to grow a control/indicator with that same granularity and in a similar fashion? For example, I have picture box that I'm inserting a bitmap into. I want to grow the box width by a miniscule amount, but the normal way of grabbing the sizing handle and dragging it doesn't offer me the desired granularity, as it grows to the next grid line.

... or simply hit the letter "g" (for "grid") while resizing, and it will no longer snap to the grid during the current sizing operation.
No need to change the default behavior.
(g is a toggle, so hitting it twice (or any event count) would re-enable "snap to grid")
LabVIEW Champion . Do more with less code and in less time .

Automatic resizing of controls on block diagram

Similar Messages

Maybe you are looking for