VI Analyzer Front Panel Size and Postion Test fails

Hi
We make a lot of use of the VI Analyser and I have been playing with the configuration settings to try and make it only fail the tests that matter to us and I have one test I do not understand correctly.
From the LabVIEW help
Panel Size and Position—Checks that a front panel
completely resides within the bounds of the screen. The test also checks whether
the front panel is larger than the maximum specified width and height. If you
are using a multi-monitor system, the test fails if the panel does not reside
entirely within the bounds of the primary monitor. This test works only on
standard, control, and global VIs.
I would like to apply this test, a simple check developers are not creating huge VI, it sounds simple enough, but I cannot seem to get this test to pass.
I am working with two monitors and this test fails when my VI is on either monitor with the message "This VI's front panel does not reside entirely within the specified bounds (1280 x 1024)" my current screen resolutionis 1280 x 1024, so I assume as long as my VI front panel fits within one screen it should be a pass.
I can clearly see my that VI front panel (and block diagram for that matter) fits within the screen of either monitor. If I look at the VI properties of my VI the Window Size is 474 x 513, could anybody please suggest when why this might be failing.
cheers
Dannyt
Danny Thomson CLAD
Sub10 Systems Ltd
Solved!
Go to Solution.

Hi Norbert,
Thanks for the prompt reply, my asking the question and your reply has made me play with this a little deeper and I have managed to solve my problem.
In case anyone else has a similar problem here are the details.
When you have two monitors and look at the Windows properites you see one monitor is identified as 1 and the other as 2, thses identities are based on the graphics card and the which monitor is plugged into which ouptput connector. You can then chose which monitor you wish to act as your primary monitor. You would suspect it would not matter once you have selected your primary monitor BUT IT DOES.
My inital set-up
Left Hand Monitor    - idenity 2 selected to be primary monitor
Right Hand Monitor - identiy 1
With this set-up everything looks and acts as I expect it to task bar, icons etc on my primarry monitor. However if you run the VI Analyser it will fail Panel Size and Position on BOTH the left and right hand monitors.
I crawlled under my desk and swapped the monitors cables round so now the set-up is
Left Hand Monitor    - idenity 1 selected to be primary monitor
Right Hand Monitor - identiy 2
Now the VI Analysers Panel Size & Position Tests will pass on the left hand monitor but fail on the right hand monitor, just as would expect.
It appears that LabVIEW is looking not only at the windows "Primary Monitor" setting but also the identies, this does not seem the behaviour I would expect nor the correct behaviour.
cheers
Dannyt
Danny Thomson CLAD
Sub10 Systems Ltd

Similar Messages

How to set front panel size to be same as one led?

Hello All,
LV2010
In documentation reads that minimum front panel size is one pixel. I need to create front panel which have same size as one led (see attachment). I'm not able to make front enough small just by dragging window borders. I also tried to change front panel size from File->Vi properties ->Window size but that didn't helped. How I can set front panel to smaller size?
Attachments:
Small_front_panel.vi ‏6 KB

I think I got it
In the window apperance option I removed everything except "Allow user to resize window" And the Run options. Then I ran the VI (continuosly since there is no loop) and resized it. After I stopped it, I then removed "Allow user to resize window" from the window apperance options.
P.S! If you try to resize my Vi now, it will pop back out for some reason.
Regards,
Even
Certified LabVIEW Associate Developer
Automated Test Developer
Topro AS
Norway
Attachments:
Small_front_panel (1).vi ‏6 KB

Set front panel size to fit different monitor ( 2 monitors-pattern to 1 monitor-pattern)

Hello, Everybody,
I have here some questions about front panel size.
At first I have create my LabVIEW programs with 2 monitors and run them with 2 monitors, because of this reason I have created a huge front panel with many objects.
But sometimes I will run the program only with 1 monitor, the problem is, the front panel is too big, I can not see the front panel with all objects completely on one monitor! I know, I can scroll aroud it, but I don´t like this way. I would like to set the front panel size automatically to fit the window ( to differenz window sizes or resolutions), how can I do that?
I have tried with "Maintain proportions of window for different monitor resolutions" and "Scale all objects on front panel as the window sizes" to finish that, but they did`t work, I can not see the front panel at once on one monitor;-(
Can you help me?
regards,
Johnny

As noted in the KB article What Is the Difference Between the Options
"Scale All Objects on Panel" and "Maintain Window Proport..., the "Scale All Objects on Panel causes all the objects inside the panel to scale when the panel itself is resized". If the panel isn't resized, the objects arent's scaled. You may also want to read the KB article How Do I Scale All of the Objects of My Front Panel with the Window Size?.

Scroll front panel left and right using control

I am taking an input from a chair rotation sensor (that just returns a voltage). I want to use this value to operate a control that scrolls the front panel left and right. Effectivively, the user would be able to navigate a wide control panel just using his chair.
So to summarise:
Does anyone know of a way to control the left and right scrolling motion of the front panel using a control?

Use the VI property "FP.Origin" to set the position of the panel in the window. To move the window position, use "FP.Winbounds".
LabVIEW, C'est LabVIEW

Front panel speaker and microphone ja

Hello all,
I wanted to know if it's possible to connect the front panel microphone and speaker jacks to my Audigy 4 sound card.
THx

jfp1 is on page 2/7 of the one i d/loaded pins 2 and 8

Using config files to setup front panel objects and DAQ info.

I am trying to write a program that condenses 5 versions into one. I need to be able to load a configuration file based on the users choice of which machine they are using and use that information for my dropdown boxes and for what was constants in a case structure based on a choice from the droplist.
For example, if a certain part was selected, it had 5 limits listed as constant that the data aquired was compared to. The limits were inside a case structure wired to the droplist.

"I have a case structure that is connected to a digital line. The program receives a value from the machine's PLC and it picks the appropriate case. Inside this case, there are constants for tolerances for the measurement that was selected. Each case has the same number of constants to control the tolerances for 5 different characteristics of the measurement. There are 32 cases each with different values. The problem is, I have 5 different versions of the program with up to 32 cases in each structure, (over 150 different sets of tolerances). I do not have them all in one program as the same case number is used somewhere else and may have different values. The display information on screen is also different from one machine to the other, and I want to
be able to hide or show certain front panel objects. I would like to set up an .ini file of some sort that stores all my case selections and load them in blocks, on one machine i load these 32, on a different machine, load the other, etc. Also be able to load the preferences for what is visible and what is not on the front panel."

Remote Front Panel Problems and Best Practices

All,
Problems
I'm currently attempting to host a Remote Front Panel from a cRIO 9073. The intent of the front panel is to control and configure the services running on the cRIO. Currently I've been experiencing quite a few problems getting this to operate smoothly.
These are the problems I'm currently experiencing.
* Front panel takes a very long time to load (~45 Seconds).
* On close the front panel may reset the cRIO.
* Front panel may cause excessive CPU usage.
* Plugin has problems in Firefox.
I'm fairly sure that I've installed all of the Latest NI software (I'm using LV 2009f2)
I currently cannot post the code as it's proprietary.
Currently the front panel consists of two timed loops one running at 500ms intervals and the other running at 1000ms intervals. The GUI is basically a tab control and on the heaviest tab contains about 15 buttons.
Questions
Is it not possible to use event structures in embedded LabVIEW? So far I've had to code my own event loop to handle all the events I wish to process on the remote front panel, and I feel this might be causing a problem.
Is the sort of functionality I'm trying to achieve acceptable in Web Front Panels?
It seems that the reason it takes very long for the VIs to load is that the VI Front Panel Server must fire up. Is there a way to make this or whatever the component is that handles it fire ahead of time?
Thanks for your time, I look forward to discussing this.
Regards,
Ken

Hi Ken,
Is this a remote front panel for a real-time VI? Is it built into an executable? If this is a RT VI, you cannot use event structures. More details are available in this KB:
Can I Use the Event Structure in LabVIEW RT?
I assume you have seen this?
How Can I View Remote LabVIEW Real-Time Front Panels in a Web Browser?
Are you still having the cRio reset issue and CPU usage increase?
Kristen H.

MSI P67A-GD65 - Front panel connections and sli A NO GO!

I have issues with this board and two gtx580 cards in sli, because If I plug the front panel connectors (power, reset, power led, hdd), the bottom card won't fit.
The issue was already found here too: http://hardforum.com/showpost.php?p=1036689234&postcount=81
Any solution from MSI.

That's not a problem for me; as the cables are plenty long. In regards to cable length the position is actually reasonable (though higher up on the same edge would address both issues). I've used at least one mb that had the connector about as far away as possible from the front connectors (it wasn't an msi - the last msi board I used was a K-3 which was really nice; still use it in my Dad's computer). Oh well I hope MSI respond to my ticket; as well as the other fellow; if nothing else maybe in the future they will address the issue.
Quote from: Bernhard on 21-March-11, 04:52:00
The MSI design alone is not the only problem. The case designers also leave the geader cables shorter than desired. I have no problem with my CM 690, but the other cases just seem to have cables that are about 10cm too short.
One solution I have employed is to route those cables under the board, diagonally, as the cable thickness is just less than the standoff heights. Thus, lay the cable in the case before inserting the MB. That way at least they won't get in the way of the GPU cards.

Help RE:Front Panel Audio and Sound Blaster Live! 24 Bit C

I own Soundblaster Li've! 24-bit card.
I would like to make use of the front panel audio jacks on my case but i have no idea where on the card to connect the pins on the card ( the pins are:Mic In, Mic Power, Ear R, Ear R, Ear L, Ear L, GND)
Anyone know where exactly do each of these pins go?

Maybe this site can give some light on this matter - http://audigy2zshowto.blogspot.com/
jutapa

Adjust front panel to screen size and re-position objects on different systems automatically

Hello, i have designed a vi that contains 5 led's placed at the 4 corners and center of the front panel which occupies the entire screen. However, this vi is to be used on different systems having different screen sizes. But on every screen, i'll need the front panel size = screen size and the led's to be placed to the centers and corner of this new screen size automatically without any manual operations and positioning bieng done every time. Will the resize option perform this task completely or do i have to go for some other techniques?
Solved!
Go to Solution.

As far as I know, what you want is not easy to do but it is doable but you have to programmatically do it (no Labview setting). Here is an example for only 2 LEDs but I suppose that you will be able to make it work for your other LEDs.
This VI maximizes the front panel and then positions the 2 LEDs in the center and top right corner upon running. The LEDs are positioned according to their own top left corners, not according to their centers.
Marc Dubois
HaroTek LLC
www.harotek.com
Attachments:
Position LEDs.vi ‏14 KB

Dr. Damien's Development - The Xylophone Project X - Font Issues and Front Panel Layout

The Show Raw Data button was made active in this installment. Doing this in a robust fashion was more involved than one might think, due to font and platform issues (remember I want to port this to a Windows Mobile device eventually). The following changes were made.
The A frequency indicator was made active. This was an oversight from the last update.
A front panel object, XylophoneFP.lvclass, was created to hold the front panel references and methods.
The front panel object was used to implement the Show Raw Data button.
The front panel object was used to compensate for font issues.
When testing this application on Windows Vista, I noticed that the font differences between Vista and XP were annoying enough that I wanted to fix them. This will also lay the groundwork for any layout issues when porting to Windows Mobile. Usually, I create a cluster containing all my front panel references, but this time I put them into an object. Besides the usual object boilerplate, there are two methods, one to rearrange the front panel and one to show/hide the data graphs.
Once the controls and indicators are properly arranged, showing and hiding the data graphs is simple. VI server methods are used to find the edges of the outer controls, some whitespace is added, then the front panel size is reset. Arranging the controls in the first place is much more complex. Dialog controls are used, and these controls change size based on the default font size. Font sizes can change due to user preference or when using the application in a different operating system than it was developed in. Button sizes can also change due to localization.
This problem is difficult to solve cleanly, and the VI which does this, XylFP.lvlib:XylophoneFP.lvclass:ArrangeControls.vi, shows the problem. It relies on the actual sizes of the controls/indicators to rearrange the front panel in a hopefully pleasing fashion. Even though this is a relatively simple UI, the VI is fairly complex. It uses VI server calls to determine the current sizes of controls and then rearrange them. If you choose to do something similar, consider the following hints:
The Bounds property of all controls is not writable. To change the size of controls, you need to find the property or properties which change the size. There may be more than one (which is why Bounds is not writable). For example, to change the size of a boolean, use the Button Size property.
In many cases, the property you use to change the size of the control will not be the same value as the Bounds property. Using the boolean again, the Bounds of a 3D LED include the 3D effect around the LED, but the Button Size only includes the LED itself. Comparing the Bounds property to the result of a query to the property you will be setting will give you the necessary offset to convert between the two.
Make sure you label your wires if you attempt to do things like this. Long wires are very common in this type of programming. It is difficult enough to keep track of things without the added aggravation of having the trace wires back to their source to identify them.
A few judiciously placed type converters can eliminate many type conversion dots. This is not usually a real problem in this context, but you should get into the habit of efficient programming.
I will be hiking through the mountains of New Mexico with the Boy Scouts for the next couple of weeks, so do not be dismayed if I do not reply to comments very quickly. However, comments and suggestions are still welcome and encouraged. I will reply when I return.
Previous Installments
Data Acquisition Concept
GUI Concepts
Specifications
Core Architecture
Data Acquisition and Note Analysis
Sound Acquisition Revisited
Sound Analysis
Configuration Dialog
Calibration Dialog
Message Edited by DFGray on 06-05-2009 03:09 PM
This account is no longer active. Contact ShadesOfGray for current posts and information.
Attachments:
XylophoneX.zip ‏1259 KB

DFGray wrote:
I put the event structure in the command loop so that events are processed synchronously. In the past, I have run into a variety of race condition/synchronization issues when separating the event and command loops and prefer to keep them together to make the program structure simpler.
It is simpler but you give up any multi CPU performance. That LV is inherently parallel is one (the only) real advantage over a text based development system. I can write good structured text that is almost as visually easy to parse as LV. With modern syntax coloring engines, the difference in icons vs. structured text is not that great.
But the challenge I give the traditional text coders is to keep track of many mulitple threads. This is why dataflow is a powerful concept. Yes it does lead to asynchronous execution but if you impose synchronicity on your code you are working against LV. I get most first time programs where everything is in a sequence structure. "Just to be safe".
Of course this is much better but my first design goal is that any application should take advantage of a much hardware as possible, degrade gracefully on slower hardware and play nice with other running applications. This simpler structure severely handicaps that first goal.
In this case it is simple enough to "get away" with it since as you point out that there should not be anything that takes significant CPU time. But that may not be true on the PDA?
If you are going to run it on the PDA will we be discussing techniques to seamlessly use both NIDAQmx Base and NIDAQmx in the same system? That is a real challenge. I look forward to more of this!
Cheers!

Maximum Character size of Front Panel indicator in LabVIEW

Hi,
I have a simple question that I hope somebody can answer. Is there a maximum character size that can be displayed in a Front Panel indicator in LabVIEW? If so, what is it? I have a VI that is continuously reading a serial port and updating a front panel indicator, and I need to know how much text can be displayed before it either truncates or throws an error. This is for LabVIEW 2010 SP1.
Thank you,
J Korn

A quick Flatten to string shows how LabVIEW stores strings {size-data} Size is a U32 so 4294967295 characters max.
The big thing to remember is this memory must be contiguous (and the Indicator requires a COPY) so in practice the performance hit for constantly allocating larger and larger buffers for the data and available memory impose practical limits much lower than the 4294967295 Char maximum. Probably better to log the data to a file and maintain only the last x characters on the indicator and use the file to look a history data
Jeff

How can i open front panel of a vi and run it

Hi
I have a vi that i call multiple times from another vi, however i want it to open the front panel on some calls and not on others. What is the best way to do this?
I have come up with a way and was wondering if this method was okay or is there another method that might work better escepcially since i am eventually going to create an application out of it and hope that no problems pop up then
Unititled 1 calls Untitled 2 where with one call it opens and runs Untitled 2 while with the other call it simply runs untitled 2.vi
What I did was i changed untitled 2.vi window appearance to dialog but i deselected the show front panel when called, so by simply calling the subvi form untitled 1 it works. Unititled 2 runs but does not open
Now with another call i want to open and run untitled 2.vi so by looking the attached vi you can see what i have done
Again if there is a better method that would make my vi's more efficient i would greatly appreciate it.
Reza Sed
Attachments:
Untitled 1.vi ‏24 KB
Untitled 2.vi ‏10 KB

What you did, in theory, is the correct way to do it. However, you should move the front panel open and close into Untitled2.vi and have a boolean input as to whether to show the front panel or not. This way, your calling code is cleaner, and you don't have to reproduce the code everytime you want to call the subVI and show the panel.
If you were to use Untitled2 in another project, then you woud have to go back and look how to implement the showing of the front panel in your other code. If later, you were to decide you want that VI to be maximized, then you make one change in the VI, and not in every place you ever call it showing the front panel.

Is there a way to use the built-in Datalogging and programmatically log the front panel while the vi is running?

I would like to use the built-in Data Logging feature. There is the "Log at Completion" option, but is there a way to programmatically make a new log record while running? I looked around in VI server and couldn't find any methods that would do that. Currently, I am grabbing all of the front panel control references using VI Server and if there are any changes, the changed values are written to a log file along with a date/time stamp. I'm mostly dealing with buttons, which simply change from 0 to 1 or 1 to 0, so it's not too hard to visualize what was pressed. It works okay for reconstructing what happened, but it would be much nicer to use the built-in fe
ature because you can "replay" directly onto the front panel and actually see what the changes were. However, without being able to programmatically make a new log, it won't work for me.

Jake,
There are several options here.
I would suggest using your own code for datalogging. The datalogging you are referring to is primarily for debug, and one shot datalogs of front panel indicators (and controls?), not including graphs, etc.
If you go to the file functions, you will see a menu for datalogging. These functions will allow you to save your data, as you need it, simply, and in a compact format.
I recommend opening the datalog file, doing all your file operations, and closing the file before the program is complete. There are several examples of this in the examples database.
Good luck

LV 8.0.1 'NOT RESPONDING' and/or 'split' and unusable front panel while scrolling

Hello,
Is anyone aware of any display or front-panel glitches and bugs with LV 8.0.1? I have been using LV for years, but I have never seen the front panel tear itself (literally) in sections while I use the standard scoll bars at the edges of teh screen, then become completely unusable and go into [NOT RESPONDING] mode (???). In other words, my front panel displays have always moved as one continuous piece when scrolling. During these recent episodes, I would use the scroll bars and parts of my front panel displays would not move while the other section(s) tore away and scrolled as I commanded. When this happens, my entire PC would slow down, the CPU usage would rise and a approach 100%, and the VI was unusable. I have been writing a particular VI for several months, starting in LV 6.1, then LV 8.0 PRO-DEV, and recently upgraded to the LV 8.0.1 'maintenance' release. The problem that I describe here began to occur within two weeks of the maintenance upgrade. The problem seemed to be propagating to my back-up version after I opened each VI in unsuccessful attempts to find a VI that did not appear corrupted. It seemed as if any VI that I opened was going to be plagued by the bug that I described above and I thought that I was going to lose months of expensive work and my job!!!!. In a last ditch effort ( and a stroke of pure genius) I started saving some of these coorupt version as 'PREVIOUS' in LV7.1 format. This seems to have turned the situation around, for now, and saved my VIs from becoming corrupted and completely unusable.
Please let me know if anyone else has seen this. Also, please let me know how to avoid this, in the future. Does this indicate corruption of my LV 8.0.1 PRO-DEV environment or the VI files (or both)? Does NI have tools to correct these corruptions?
Thank you.

Thank you. I can only point to the following events/ techniques that were somewhat different from my previous experiences/ techniques:
1) Performed 'SAVE AS... ' new file name to these files over several months and several times a day using similar filenames with only one number character different between them
2) Logging long data files to the root C: drive and closing in on less < 5GB HDD remaining (could this be overwriting soem temp files that LV uses to manag graphics???)
3) After saving to LV 7.1 and re-opening with LV 8.0, I get a message that is new to me that explained something about wiring a Boolean constant to a case structure and how LV 7.1 or previous used this to keep a sub-vi in memory (???). Unfortunately for me, I did not capture the exact syntax of this message and I do not wish to intentionally repeat this graphical feature.
4) I copied a small block of code that contained a 'cloned' sub-vi from one block diagram to the a similar VI that , shortly afterward, exhibited the front-panle 'tearing' feature. This is something that I usually do not do, and, again, is one of the only new actions from anything that I have done in LV for the past several years.
5) After the message described in (3), above, the rescued LV 7.1 version had moved a handful of the most recently added indicators to a very remote location, about 30 seconds of edge-scrolling time, to the left of my front panel graphics. I perfromed a 'drag' operation by selecting these and bumping them to the right edge of the screen for about 30 seconds to get them back to the vicinity of my front-panel graphics. I have never experienced a VI that shifted inidcators so far off the edge of the screen.
These are the only ' unique' events that I can recall before the 'tear; effect.
Thank you.

VI Analyzer Front Panel Size and Postion Test fails

Similar Messages

Maybe you are looking for