My front panel is causing my vi to run at the wrong frequency.

My vi worked fine before I made my front panel into a useful GUI. The code was not changed only decorations, colors and position was changed. Now my vi will not operate at the correct frequency. I know this because I should be sending out a bit pattern at 25Hz and the oscope shows a change with the new vi. If I reduce this vi to 1/2 screen and the view the top of the front panel the vi runs fine as soon as I view the lower part of the front panel or go to full screen the frequency is wrong. I also found that by deleting two large decorative boxes the vi ran fine. I have played with the graphics settings and the only thing that helps is setting the resolution to 848x480 then the vi runs fine but looks funny.
Any suggestions? Windows 2000 with LabView 6.1.

Sounds like you are low on memory or CPU.
Make sure you display is set for 16-bit color.
Make sure none of the indicators are over-lapping.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Similar Messages

How to programmatically load and show the front panel of a vi but NOT run it?

Is there a way to load and show the front panel of a vi but NOT run it? I am starting with the AsynchronousCallAndForget.vi from the example finder and inserted an invoke node with the FP Open method call prior to the Start Asynchronous Call node. The vi I am loading has the "Run when opened" unchecked and the menu bar IS visible so I can manually click the run arrow. Thanks!
Solved!
Go to Solution.

Why are you using the Async call? If you simply open the VI reference, then call the FP.Open method this works fine. You can then call the VI run method with Wait Until Done set to false if you wish to run it Asynchronously, this is how we did it in ye olde days before we had this new fangled "Start Asynchronous Call" stuff.
Charles Chickering
Architecture is art with rules.
...and the rules are more like guidelines

Does Front Panel Audio Work When Using RCA Outputs from the X-Fi Titanium HD PCIe Sound Card?

I see that the rear panel headphone output is disabled when the soundcard RCA jacks are used.
But is it possible to have the front panel audio output work at the same time that the RCA jacks are in use or is it also disabled?
I am willing to tolerate inferior quality audio feeding my monitor and use the RCA jacks for my headphone amp.

I was able to construct a work around for this problem. A Y splitter from the RCA outputs is an option but can degrade the sound because of the uneven load presented to the soundcard.
Ten eleven inch Apevia CVTAUDIOE25 HD Audio extension cables were connected together in series to a SilverStone FP32 3.5 audio front panel bay. The extension cables were connected to the front panel audio connectors on the Titanium HD sound card and then the cables were run out of the computer case and up to the area near my keyboard. I connected the front panel audio bay to the extension cable and the bay sits next to the keyboard. When no 3.5 mm stereo cable is connected to the front bay near the keyboard the sound is normal out of the rear outputs. But when a 3.5 mm audio cable is plugged into the front panel bay audio there is sound out of the SilverStone front panel bay. The sound is still muted out of the rear RCA jacks when the plug is put in the front bay but it is only used when the main audio outputs are not required.
The function for me is that the front bay serves the same purpose that the previous front panel 3.5 mm audio extension cable did.
There are photos of this under a different user name on Audio Asylum PC Audio.

There is a problem with the phone app. When I want to call somebody the phone screen come too late. This will cause a problem if I call the wrong number

There is a problem with the phone app. When I want to call somebody the phone screen come too late. This will cause a problem if I call the wrong number. Apple please please please fix it as soon as possible and also check why the phone is always restart. I prefer to let us use the iOS 7 until you finished from the IOS 8 because Ios 8 still under construction there is a tones problems in the system. And this Will cause undirect problem for the iPhone 6

There is no apple here in this user to user technical forum.
Do this Use iTunes to restore your iOS device to factory settings

I want to save an image of the front panel, (with data), after every VI run

When I try to copy the front panel (using a select all), and paist to paint, all the data in the graphs show up as they did after the last run, but the data in the charts dissapear. The chart itself is copied but the data is not. Any ideas on how to solve this?
Thanks,
Brian
Attachments:
Brians_graph_compilation2.vi ‏1363 KB

This Knowledgebase also has some information on programatically saving VI images
http://digital.ni.com/public.nsf/websearch/942DAA35C7B35616862565FE005F713F?OpenDocument
(KB 197BB7VJ if the link doesn't work).
Note that you don't have to put the code in the VI you are running in order to save it to a file, so you don't actually have to modify your VI. You can just run a seperate VI that uses the VI name from the first one (I've attached a VI which could either be run standalone or used as a SubVI, as well as an example of using it as a SubVI).
If you don't want to do it programatically you could just hit the print screen button on your keyboard and then paste it into paint and crop off the extra windows stuff.
Attachments:
CreateVIJPEG.vi ‏34 KB
ImageExample.vi ‏24 KB

Front panel class objects are missing their icons in the runtime engine

I have this project that contain some class objects. When run in the developer environment, the icons appear fine.
However when I build as an executable and run it in the runtime engine, the icons are missing.
These missing icons are purely cosmetic and the underlying logic works without a problem. Is there anyway to get these icons to display when built as an executable?

Known issue, see http://lavag.org/topic/12980-class-control-icon-not-shown-in-run-time/
EDIT: have you considered just making that control invisible? Takes a bit of manipulation of property nodes and references but you can do it as shown:

Problem with Append Front Panel Image To Report.vi

I'm using LV 7.0 with the MicroSoft Report Generation toolkit installed. Under the Report Generation palette there exists an Append Front Panel Image To Report vi. Also on the same palette there is an Easy Print VI Panel or Documentation.vi which uses another Append Front Panel Image To Report vi located under the VI Documentation subpalette. Here is the problem; I have serval vi's that use Append Front Panel Image To Report.vi from the Report Generation palette and I have a couple of vi's that use the Easy Print VI Panel or Documentation.vi which is linked to the Append Front Panel Image To Report.vi located under the VI Documentation subpalette. Clear as mud!
This creates a conflict of intrest. In a nut shell th
ere are two vi's with the same name in different locations doing different things. I have a program with subvi's that need to call each respective Append Front Panel Image To Report.vi and that just is not working.
Is this a known issue with LV7.0 that has already been addressed and/or resloved?
Thanks.

ATC Herman,
Based on the picture you posted and what you are describing, it looks like you might have an incomplete install. What version of the toolkit do you have? Was it first installed on an earlier version of LabVIEW, or did you install it first on 7.0? Your VI Documentation Palette appears the same as if you hadn�t installed the toolkit. I�ve attached a screenshot of what it should look like. The VI in question is a polymorphic VI, which may be causing some of the confusion. If you right-click on it and select �Open Polymorphic VI�, it will show you what options you have, depending on the input. I opened both test and test1, and they appeared the same for me. I was able to have them both on the block diagram. The path to bo
th of them was C:\Program Files\National Instruments\LabVIEW 7.0\vi.lib\printing\ReportDocExtensions.llb\Append Front Panel Image to Report.vi. The .llb ReportDocExtensions has the polymorphic VI, as well as copies of each of the possible instantiations. Make sure you have these VI�s in the .llb in that directory.
There is a KB on having the toolkit on multiple versions of LabVIEW and what files you need. Make sure you have all the files listed.
Please let me know if you are able to get to the bottom of the issue with the above information.
Thanks, and have a happy day!
Robert M
Applications Engineer
National Instruments
Robert Mortensen
Software Engineer
National Instruments
Attachments:
Report_Palettes.JPG ‏57 KB

Printed front panel graphics quality (Print Panel to Printer method vs. Append Front Panel Image to Report.vi)

LV 6.02 (or 6.1)
NT 4.0
I have a vi that the front panel includes all the information I need to print except that it is on different pages of a tab control to conserve screen space. I was attempting to programatically cycle the value of the tab control in a For loop and invoke the Print Panel to Printer method to print 7 pages of the front panel, each with a different tab page selected. The printouts were excellent quality but beginning with the second consecutive Print Panel to Printer method the on screen front panel image of the VI being printed would become jumbled (sometimes, by the time 7 printings were done, the entire front panel image would disappe
ar and a bitmap of the desktop or underlying windows would be visible in the VI's panel frame) yet the subsequent Print Panel to Printer methods continued to print the panel as they should appear. The visible front panel graphics would never return to normal and the only solution was to close the vi (in the dev system) or exe (compiled) and re-launch. I tried a lot of things (like hiding the panel to print before printing and showing it after printing) with no luck. It appears that two or more of these consecutive invoke methods caused the problem regardless of whether the tabs were cycling, or even if there was no tab control and much fewer controls on the panel to be printed than normal. I also had the same problem with LV 6.1.
Finally, I was forced to switch to the report generation toolkit vi's, I cycle through the tab pages and use the Append Front Panel Image to Report.vi to append each image to the report. This is faster and control returns to my program quicker but I a
m unhappy with the printed quality of the graphics of the front panels. They are not as high of resolution as those generated via the Print Panel to Printer method.
Any suggestions?

You might try changing the way the VI is printed by going to tools >> options >> printing. Try the postscript and bitmap settings.
Jeremy

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?.

I want to print the front panel without all the header stuff while the vi is running

I want to print the vi front panel without all the header information that Labview puts at the top. I want to do all this while the vi is running by pushing a button.

One option is to use the the 'Print VI to Printer' method. Beware that invoking this method repeatedly with complex front panels has caused me graphics problems in my VI's display that persist until the development environment or the built .exe app is exited and re-entered.
See: http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=5065000000080000005F5A0000&UCATEGORY_0=_49_%24_6_&UCATEGORY_S=0&USEARCHCONTEXT_QUESTION_0=spaz+print&USEARCHCONTEXT_QUESTION_S=0
NI has confirmed this to be a bug in 6.0x and 6.1 and has indicated that it will be fixed in the next version.
I was forced to fall back on the Append Front Panel Image to Report.vi in the report toolkit. Which does not produce printed graphs of as high as quality as the Print VI to
printer method.

Graph stalls when front panel is adjusted

So I am trying to debug a code that someone previously wrote. I am a bit familiar with the code but as I mentioned did not write it myself. The deal is that when Im in running the front panel and the graph is graphing time vs any other parameter, if you press any button on the front panel or if a sub-vi gets called the graph will stall and one has to manually reset the graph. I am not too sure why this is going on. Attached are a few screen shots of where this section of the code lives. There is a stacked sequence with two subdiagrams and it is also being called in the event structure inside one of those subdiagrams. I could also upload the whole code if needed.
Thanks for the help guys
Attachments:
Graphing front panel.doc ‏456 KB

OK, I was able to get to the code by selective unzipping.
As a first step, you should eliminate all these value property nodes and replace them with plain local variables instead. The code os causing excessive thread switching and spends way too much time in the UI thread.
Overall, there is way too much code. For example you have in the "graphed parameter" event the same property node in every single case of the inner case structures. These property nodes belong after the case structure, only once instance each needed!
(Sorry, I have to do some other things now. Will look at it a little more later.....)
LabVIEW Champion . Do more with less code and in less time .

Unexpected effect of Lock Front Panel in Event Structure

I have been using LV intensely for only a short time, although I have dabbled with it many times since its first appearance. The "problem" that I have had may well be the intended behaviour, but it just seems unintuitive to me. I'm writing a small application to take measurements from a USB instrument. I have already written a basic driver for the instrument, which the application calls, and the driver is working as expected. In the application, the user can configure various settings and then click an Execute button to transfer them to the instrument. The click event is handled in an event structure along with other events. Since some of the instrument operations take an appreciable time, the first action that occurs in the click event case is to disable the Execute button using a property node so that further clicks are ignored until the operation completes, at which time the button is re-enabled.
When disabled, the Execute button is grayed out as expected and clicking it has no visual effect. However, it seems that clicks made during the disabled period are still queued and acted upon when the button is re-enabled, causing the operation to be repeated.
It is the solution I have found that seems unintuitive to me. The Lock Front Panel check box was checked (by default) for the click event, and I assumed that this would be the correct setting. However, unchecking the Lock check box actually makes everything worked as expected. Click events occurring during the disabled period are now ignored or discarded. I'm not suggesting that this is a bug, but I'm interested to learn why it happens, if anyone can explain. I have attached a picture of a simplified version of the event case.
Attachments:
Sample.png ‏7 KB

I would say what you see is expected behavior, even though it's a bit complicated.
The "Lock front panel until the event case for this event completes" option will only defer clicks and other things generating events until the current event handler completes. So this means that the click is placed in a queue and only evaluated once the event is finished. At this time, the button is no longer disabled, so an event is generated.
When the "Lock front panel until the event case for this event completes" is not checked, the click is immediately evaluated, but it's happening on a disabled control, so it does not generate an event.
From the LV help:
By default, when an event enters a queue, LabVIEW locks the front panel that contains the object that generated that event. LabVIEW keeps the front panel locked until all Event structures finish handling the event. While the front panel is locked, LabVIEW does not process front panel activity but places those interactions in a buffer and handles them when the front panel is unlocked.
Note If an event case that locks the front panel takes a significant amount of time to execute, consider using the Set Busy function or displaying a dialog box to notify the user that the front panel is locked.

VI Method "Front Panel:Get Image Scaled" Memory Error 17

Hi all, I've got two almost identical sub vi front panels that I'm dumping to a jpg image for reporting purposes. One was copied and slightly modified from the other to show a different data set and plot. The original works just fine, but the second sub vi, when using the "Front Panel:Get Image Scaled" method to pass the image to write the jpg, always returns the following error:
"Error 17 occurred at Invoke Node in Myprogram
Possible reason(s):
LabVIEW: Not enough memory to manipulate image.
=============================
NI-488: Unrecognized command.
Method Name: Front Panel:Get Image Scaled
[Continue] [Stop] "
I've stripped the problem section into a simple tiny new that only opens the report and tries to get the image with the same working/non-working result above. Using the Execution Trace Highlighter, it error is definitely occuring when the Method executes.
Any ideas? Thanks.

Hey cjgpr,
I haven't been able to dig up much info on this error message. There's one other discussion forum post that talked about it some, and a KnowledgeBase article on it. It seems that whatever changes you made to the front panel have caused it to exceed your computer's memory when creating an image. Try removing items until it works, then see what actually breaks the functionality.
Brian B
Field Sales Engineer
Tennessee/Southern Kentucky
National Instruments

Custom Title in PDA Front Panel Title Bar

Hi,
I would like to customize the title in the front panel title bar of my PDA application after the application has loaded. Targeting Windows XP this can be done by using Property: Front Panel Window: Title, which is not supported by the PDA module (8.5).
Does anybody know of any workaround?
Thanks,
Volker

Hi Volker,
I'm
sorry for any inconvenience this has caused. As you're probably aware,
architecting PDA applications is considerably different from architecting
Windows XP apps. PDAs have very limited resources, and are not capable of
supporting the LabVIEW runtime engine, so the PDA module must "cut the
fat" by compiling the VI to native PDA code and by eliminating any
unnecessary features. There may be other reasons that that feature has
not been implemented that I am unaware of, or it may simply be that R&D has
not made it a priority. In either case, filing a product suggestion is
the best way to draw attention to it.
Also, FYI, the LabVIEW Help keeps a current list of supported properties and methods:
Supported Properties (PDA Module, Touch Panel Module)
http://zone.ni.com/reference/en-XX/help/370642E-01/lvpdatpchelp/pda_properties/
Supported Methods (PDA Module, Touch Panel Module)
http://zone.ni.com/reference/en-XX/help/371944B-01/lvpdatpchelp/pda_methods/
Eric V
National Instruments
Applications Engineer
Certified LabVIEW Associate Developer
"I'm a Ramblin' Wreck from Georgia Tech and a helluva (NI Applications) Engineer!"

Can not open front panel sub VI when running an application VI.

When I create an application of my program a problem occurs. When I select options (press a button or so) from the main front panel that should result in a popup menu (sub VI cal) LabVIEW indicates that something is happening but the front panel does not open. The mouse indicator changes to the time glass so LabVIEW is doing something but the window of the sub VI does not open.
The problem has the same characteristics on several places. There are some sub VI front panels that opens but I ca not find the reason for why these open and not other.

Hi
there are three ways trhough which you can force a subVI to show its front panel
1. open the perticular SUB VI
click File->VI properties select window appearence catagory.
click customize button and select "Show Front Panel when called" and "close afterwads if originally closed" check boxes
save the VI
whenever you use this Sub VI every time it will pop up front panel
2. dont perform the changes suggested in option 1. place the instance of subVI in your main application and if you want that instance to popup a front panel then right click on subVI and Select "SubVI Node Setup" again select "Show Front Panel when called" and "close afterwads if originally closed" check boxes
with this option only certain instances of SUB VI will cause pop up to occur
3. this is the most flexible option. use invoke node to show front panel. in invoke node select show front panel method to popup the VI and use close front panel method to close the pop up window.
Tushar Jambhekar
[email protected]
Jambhekar Automation Solutions
LabVIEW Consultancy, LabVIEW Training
Rent a LabVIEW Developer, My Blog

My front panel is causing my vi to run at the wrong frequency.

Similar Messages

Maybe you are looking for