Determine Front Panel in memory
Hi!
Is there any way to determine, is the front panel loaded into memory, programitically?
Thanks!
+++ In God we believe, in Trance we Trust +++
[Hungary]
Solved!
Go to Solution.
Well, easy rule of thumb:
LV does not load the front panel into memory if not needed.
LV loads the front panel into memory if you display it.
LV loads the front panel into memory if using property nodes requiring the front panel. This info can be obtained from the detailed help of this property:
LV loads the front panel into memory for certain methods (also documented in detailed help of the method).
On a side note:
Please do not mix execution of code in the UI thread with loading the front panel. The UI thread is always running and does not determine wether (or not) front panels are loaded into memory!
hope this helps,
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Similar Messages
-
Load error code 3 unable to load front panel
Hi all,
Wrote a vi in 8.6 and saved it for 8.5 for collaborators. When they run it up pops the error code 3 unable to load front panel. Memory full. see attached picture.
Has anyone any suggestions as to how to fix this?
Regards,
leeser
Attachments:
labview error code 3.png 51 KBHi guys,
Thanks for the comments,
Attached is the code (zipped). Excuse the bulkiness of the block diagrams. It basically controls a rotation stage and makes an avi at specific times/angles. The motor stage is ActiveX controlled.
As I don't have access to the hardware I am writing semi-blind. However, when I did visit them and had a quick look at the code I could get it to work by quickly including the subvis into a new main vi and obviously compiling it in 8.5. (may be onto something here!)
Different versions of the labVIEW -> doing a group a favour; I have v8.6 they have v8.5, wrote it in v8.6 saved it for v8.5. I don't have v 8.5. I also have v 8.2.1 on a different machine. Saved it for v8.2.1 and it opened no problem in 8.2.1. Will send this version on and see how they get on. More likely to be forward compatible???
I agree that the optimal situation is 1) use the same version of labview and/or
2) they get someone to do their coding on-site!!!!
I think the corrupt front panel object could be true given that I could get it to work when the subvis were included in a new main vi on-site.
so versions 8.6, 8.5 and 8.2 attached.....
regards,
Leeser
Attachments:
rotation_control.zip 178 KB
rotation_control_v8.6.zip 60 KB
NCLA_rot_usb_v8.5 Folder.zip 141 KB -
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 -
Remote front panel: loading VI into controller memory
Hi everyone,
I am currently using LabVIEW 7.1 and need some expert help.
I have a VI (which also include more than 80 sub VIs) that controls a system through compact Field Point module controllers. Currently, all these VIs are stored in a server computer.
At this stage, I am capable of creating a remote front panel, which allows me to control the system from a client computer other than the server computer. Instead of using the server computer to control the system, I would really rather to use my field point controller to do the job, and I have the following questions:
1. In the server computer, VI can be loaded to memory by opening the VI, how do you do it if you were to use the cFP-2015 controller as a server?
2. I created a "startup.exe" and the "htm" files for my program and stored them in my controller and set it to launch application at boot-up. For once, I can access to my controller from the web. But once I close my browser, and re-access the web, the memory in my controller seems to be lost and I got an error message saying VI was not loaded in server memory. Is it possible to store the VI in the memory of my controller for a long time??
Many many thanks in advance.
TakHello Guenter,
Thanks for your explanation. I think your description match very well with my observation. Your suggestion of flashing the LED while my program is running is a good idea.
Sorry that I didn't describe what happend well enough, here is what happened to me.
I embedded the program which simply turn on and off one of the LED on my cFP controller for 20 times.
I re-boot my controller and wait some time, I then see the LED turns on and off.
Before my program finish, I can access to my remote front panel page for multiple times even after I closed my browser while the program is still running.
If I request control over the controller, I can manually stop the program, and then re-start it.
However, after I re-start the program remotely, if I closed the browser even while the program is still running. The program stops as soon as the browser is closed. When I re-open my browser, it says the requested VI is not loaded in the memory on the server computer.
So, correct me if I am wrong, it sounds like embedding my program as exe file, download to my controller, and set it to launch the application at boot-up is the only way to load the VI into controller's memory. Is there any other way?
So, having said that, I have to re-boot my controller every time when I want to start my application file that is sitting in my controller, is that correct?
Many thanks again.
Tak -
How to display remote front panels of subvis that are already open
I inherited an RT project that uses remote front panels for nearly all the user interfaces. The host application opens a remote front panel the the top level RT vi, and there are several subvis on the RT system that are opened from that top level vi and thus displayed on the host (i.e. their "Show Front Panel When Called" properties are set TRUE).
If the Host loses its connection to the RT system when any subvi front panels are opened, and the host application is restarted, it can re-open the top level vi remote front panel, but all the RT subvis that are already open will not display their front panels. I am looking for a way to open the front panels to these subvis from the host application.
The kicker is, I need to know which subvis are actually running before I attempt to open remote front panels. Is there any way to determine what subvis are actively running (and not just in memory, such as subvis that won't get executed until the top level vi reaches a certain state)? I am thinking that I could create a list of the subvis that I need access to, check to see if any are actively running on the RT system, and then invoke a remote front panel connection with those that are running.
Does anyone have any ideas as to how I might be able to do so? Or any other suggestions? [and yes, I know that RFP communication is probably not the best way to go, but we're too entrenched in this software to start over with a new system!]TurboPhil wrote:
If the Host loses its connection to the RT system when any subvi front panels are opened, and the host application is restarted, it can re-open the top level vi remote front panel, but all the RT subvis that are already open will not display their front panels. I am looking for a way to open the front panels to these subvis from the host application.
It might be possible to work around this behavior by placing VI invoke nodes in your top level VI that reference each of your subvis and setting the Wait Until Done invoke method to false. This should cause the subvi to close when the top level VI closes even in the case of an unexpected restart.
You can access this invode node in the functions pallet by selecting Application Control » Invoke Node and also selecting Application Control » Static VI reference. Wire the Static VI Reference to the vi reference input node and double click the Static VI Reference and select the appropriate subvi in the dialog window. Left click on the Method section of the invoke node and select Run VI. Finally right click on the Wait Until Done invoke method and select Create Constant and ensure this constant is set to false.
TurboPhil wrote:
The kicker is, I need to know which subvis are actually running before I attempt to open remote front panels. Is there any way to determine what subvis are actively running (and not just in memory, such as subvis that won't get executed until the top level vi reaches a certain state)? I am thinking that I could create a list of the subvis that I need access to, check to see if any are actively running on the RT system, and then invoke a remote front panel connection with those that are running.
You can access this information by using the Real-Time System Manager (Tools » Real-Time Module » System Manager). This can be used to show what VIs and subvis are loaded into memory and which are running.
For more information on using this tool please referere to this Knowledge Base article.
Message Edited by BLAQmx on 02-18-2008 11:40 AM
Mark
LabVIEW R&D -
I'll start with my setup:
2 PXI-1042 chassis connected via fiber-optic using NI PXI-8336 (MXI-4) cards.
Chassis 1: PXI-8108 embedded controller running LabVIEW Real-time OS (2010), PXI-6528 DIO, PXI-8336 MXI-4.
Chassis 2: MXI-4 in slot 1, 4 PXI-8334 DMM, PXI-6528 DIO, PXI-6281 M-series DAQ.
The real-time executable monitors analog and digital inputs and DMM measurements, displays the values using numeric and boolean indicators, generates alarms and allows users to acknowledge alarms via a Remote Front Panel. The code has a custom error handler that traps errors and stores them in a global array. This allows the code to display them on a console and allows the user to acknowledge and clear errors, and scroll through multiple error messages. We used property nodes sparingly.
The system is monitored by two laptops with the correct run-time engine installed (both laptops have the LabVIEW development suite). Under normal conditions, one laptop keeps control of the Remote Front Panel at all times.
The problem:
The system was running flawlessly for 3 months of continuous use. Then, for no apparent reason, the indicators that display measurements from "Chassis 2" (specifically the DAQ) stopped updating.
If the user refreshed the browser, the Remote Front Panel client would reconnect to the RT Web Server and get updated values, but they were always static. Essentially, refreshing the browser took a "snapshot" of the data, but the indicators did not update continuously as before. At the same time, DIO inputs to "Chassis 1" responded appropriately to changes in state.
Refreshing the browser on one laptop would update the values for that laptop only, and the other laptop could be refreshed independently and have different values displayed, but both laptop's indicators were static. During this time, the DMM measured inputs were not changing and the "Chassis 2" DIO inputs did not change state (i.e., we could not perturb the inputs), so we could not determine if those indications were affected.
Also, the error console did not respond to user input until the browser was refreshed and the client reconnected to the target.
We know the RT application is running on the target because there is code that monitors the status of the loops by changing state every loop iteration and displays the status to the user.
Our short-term solution was to reboot the RT controller by powering down both chassis, starting "Chassis 2", then starting "Chassis 1". It's been running for a few days now without incident.
Since the data displayed after refresh was accurate based on comparison to gages in the system, we do not suspect a measurement problem.
Possible culprits:
1. The RT Web Server has malfunctioned in some way (memory problems, synchronization, etc.)
2. The MXI-4 link.
3. Cosmic rays? Sunspots? Nearby radar stations? Neighboring HAM radio operators (with massive amplifiers)?
If anyone has any ideas, they are welcome. We are concerned that this will be an ongoing problem, if only every few months or so.Could you clarify a bit on how the PXI-6528 was acting while you were seeing these problems? Does this card have values display on the Remote Front Panel, and if so were they still updating properly? I believe you were saying that, but I wanted to be sure because that makes a big difference.
If everything became static, including the DIO card, at the same time, then I'd say see if your browser updated, or something in your network settings was changed without you noticing. Perhaps an update ran and reset some of your firewall settings, or an Internet Explorer update changed something that required a reboot.
If just the outputs of chassis 2 were the problem, and the DIO card values on your remote front panel still worked well, then it is most likely a problem with your MXI-4 cards or your fiber optic cable that cause the change in behavior.
Miles G.
National Instruments
Applications Engineer -
How to open front panel of a VI running in RT.
Hi,
I have an application to read the encoder position using the cRIO program. I have made an executable and this application runs as startup application whenever the controller reboots. Right now, i am accessing the VI of the startup exe through Remote Panel connection. This works fine but everytime i close the remote panel , i have to reboot the controller for the next view.
So is there any alterntaive to open the front panel of the VI.
I tried using VIServer but ran into errors. (i tried using front panel -open property node.did not work)
Also i do not have any VIs stored on the controller. Only the exe is stored on the ni-rt/startup folder on the RT controller.
Please let me know how to open this VI.
Thanks.Hi Ben,
When i close the remote front panel the first time, i am terminating the RT VI which is running on startup.
So i had to reboot everytime to access the remote VI. I guess that the VI (exe) should be continuosly running when the RT is started up. The remote panel only should be opened and closed. After I close the remote panel , i want a windows VI to be opened up.
I have a Windows VI which programmatically opens connection to the RT server for opening the remote panel. The VI runs. When the user clicks Exit on this RT VI, the VI running is stopped and then another windows VI opens up. This works fine for first time. Since the RT VI is terminated, second time , if I run, it says, VI not in server memory.
Is there a method to close the remote panel programmatically in the RT VI itself. I have a Exit button in this RT VI, so if the user clicks, Exit, the program has to be running, but the remote panel has to close. There is a method called close connection to client , but this does not work in RT , as this requires VI path.. Right now , when the remote panel RT VI is launced, to close the remote panel, i click on the 'close' button on the VI title bar. Again when the remote panel is launched, there is no error. but is there a method to close the remote panel in the server(RT VI itself). i have attached the VI.
Thank you.
Attachments:
Dummytest.vi 39 KB -
Here is the scenario, I have a main VI that uses an event structure to call various other SubVI's depending on what control is pressed and to update the front panel accordingly. The front panel of the Main VI is a Tab Control with ~25 controls total. As you can imagine, some controls should not be enabled until other events happen. For example, I have a menu ring called "Report Type" of which you can choose 'HTML' or 'Send to Printer.' Next to this ring is a boolean control called "Open in Browser?" , I want to only enable this boolean control only when "Report Type" is set to 'HTML.' Likewise I want both the "Report Type" and "Open in Browser?" controls to be disabled if the user has not hit the "Download Data" control to get data from the RT Controller (otherwise there would be nothing to report.)
These are just a few examples of what I need to do, I have been adding 'Disabled' property nodes throughout my event cases but it is becoming very unwieldy and making my block diagram quite cluttered and hard to understand. What I want to do is have a 'Front Panel Controller SubVI' of sorts, of which I define about 10 or so various states the front panel can be in and pass that state to the controller SubVI which in turn disables/enables controlls accordingly. This idea sounds good but so far the implementation seems pretty bad. I was hoping I could just make a cluster of control references and pass that into the SubVI but LabVIEW 8.2 doesn't seem to allow me to wrap up references in a cluster. This has forced me to use VI Server to get the references. What I've been able to come up with using VI Server works, but I can't believe its the most elegant solution. Basically, for each of the possible states, I iterate over all the controls in the front panel and have a case structure for their Label Text which determins if that control should be enabled/disabled for the given state passed in. Also, for some reason it seems that it is not grabbing references to ALL of my controls. There is a menu ring control on the front panel that isn't in the Controls[] array. I should mention that this particular Control already has a reference node created for it that gets passed to a SubVI, perhaps this is why its not found in the Controls[] array, but this doesn't seem to be very intuititve, or documetned for that matter.
<a href="http://tinypic.com" target="_blank"><img src="http://i37.tinypic.com/fjgwtv.gif" border="0" alt="Image and video hosting by TinyPic"></a>Thats a very good idea, although I'd probably want to put a case structure around the disable property node and have it only change value when the search array function does *not* return -1, otherwise I'll be disabling things I might want to maintain in an enabled state.
Just before I read your post, another thought came to me and that why use a SubVI, I could just use a parallel loop with queues to send back state information. Since queues can be blocking, this would not negate my event structure. I could combine the idea you gave me with this architecture. Thanks -
Close Front Panel Causes System Hang.
I have an application where there are several front panels that I would like to have open at once, but where when they stop they would close. I was using the scripting function fp.close - but as the application has got more complicated this seems to work less and less well. Basically when i hit close, the system hangs for a few seconds, then the time critical stuff i have tends to timeout and then crash, and everything goes funny for a while.
My (uneducated) guess is that when it closes a front panel it drops loads of stuff straight out of memory - in an uncontrolled way.
After going for a cup of coffee it usually sorts itself out. But clearly this isn't a sustainable solution for my application or my kidneys.
Am I doing something wrong? - Is there something i should do to allow the Vi to finish before i try to close it? Should i be releasing references or somethign to make things better. I thought about running the close vi sub as a new thread - but not sure if this would actually do anything different.
Attached - the subroutine that i pass a vi ref to.
Attachments:
RunningVis_CloseSubVi.vi 17 KBThere's nothing in the attached VI that would necessarily cause your problem. I would, however, suggest that you feed your reference through the nodes in proper flow control method rather than branching off like you've done.
When a VI fails to close quickly, I have most often found it's due to open references which aren't explicitly closed. File references, VI references, multiple calls in a loop acquiring the same reference over and over without releasing it, .NET calls not being closed - that kind of thing.
Richard -
Mobile VI Front Panel Display issue
I am not sure whether I should report this as a big of Mobile Module, so post it here and see if anybody else encounters the same issue.
When create a mobile VI, if you put a TCP Connection control and String array on the front panel the same time, it won't run. It compiles and deploys all fine, but when you try to run it, it doesn't. And if you put it as a subVI, it will stuck when it is called.
Guess I am lucky. Just so happened that I needed to put both controls on the front panel and ran it as a subVI. Every time this subVI was called, the whole program stopped. It is a simple subVI call, but maybe it is so simple that it becomes so hard to debug. I started to check if the memory was full, then subVI property, and then put all kinds of breakpoints to debug. Finally, just when I ran out of debugging ideas, I was looking at all the controls on the front panel. Is it possible that one of those controls has some sort of conflicts with others, or the mobile module simply cannot load the type of control(s). So, I took one out at a time.
It took me a whole morning, but that's how I found this bug. I hope after I post it here, it can save your time to debug this type of bugs.
Attachments:
TCP Control.vi 10 KBHi, Paul,
This could be another bug of Mobile Module if you can repeat what I did.
Here is the issue. When I transfer time stamp from PC (time stamp flattened to string) to the palm (then unflattened back to time stamp), the time stamp on the palm is always plus one hour. Don't know if this is a bug or a programming error?
Thanks. -
I'm using the code shown in the sample VI discussed here: http://digital.ni.com/public.nsf/allkb/353A696A3F393D9B86256E8B007A2912
to close all open VIs except my top level VI. My top level VI is actually a separate executable and the sub-VIs are their own executables. All reside under the same project. It works very well if I'm running in LabView but will not work when I build them. I added all the sub-VIs to the Always Include box in my top level VIs properties which did nothing. I also tried adding them to the Startup VIs box. This allowed me to close them all programmatically from the top level VI but it also open all the VIs at once (which was expected and not desired). I think the problem is the executables are not able to see outside their own memory space so the top-level VI never finds any other open front panels to close. Is this correct? Is there another way to go about doing this?
Thanks!Where do I begin…..
I’m using a “server” to control 4 “client” PCs. My server opens references to 4 VIs on each client then executes them sequentially. So on a normal day, the server will run everything itself and I will have no contact with the clients. But on a several occasions, I’ve needed the ability to walk up to one of the clients and run just one of the 4 VIs.
We are updating from LabView 6.1 to 8.5 and we want to run executables rather than VIs for various reasons. I have a new VI running on the client PCs who’s only function is to initialize the shared variables and open/close the VIs. I initially thought of making the remaining 4 VIs sub-VIs but I will loose the ability to run them individually. I think I would also have to rewrite the VI running on the server since the 4 references it originally opened do not exist. I don’t think you can open a reference to a sub-VI on another PC. Can you???
As you can see, this is a huge mess. I’m still pretty new with LabView so any help you can provide would be great. -
VI Front Panel in SubPanel reacts slowly
In LabView 2010F2, I have a VI that has several buttons and other controls on the Front Panel. When I run that VI standalone, it runs very quickly, uses less than 20% CPU, and is very responsive. ALl of the controls react very quickly. But when I put that same VI FP in a subpanel in a small VI, all of the controls in the VI in the subpanel are now running very slowly. There buttons are slow to react. There is almost a 1/2 second delay on the buttons. The CPU is stall down around 25% usage. The hosting VI does not do much and should not be responsible for this delay.
If the CPU is not very busy, what is the cause for the delay in the reaction of a Front Panel of a VI that is placed in a subpanel?
What can be done to significantly improve the response of a FP that is placed in a subpanel?dbaechtel wrote:
Ben wrote:
How is you memory doing?
Do you have "show Kernal time' selected?
Ben
CPU Usage and Kernel Time do not pudge much during Save All or Clean Up Diagram of large diagram. CPU usage stays about 25%, Kernel time stays about 50-75% of Total CPU Usage.
I don't see any reason why LV would show "not responding" under these conditions unless there are some long LV processes that are being executed that include significant I/O delays that do not relinquish the CPU to do other things while executing these long LV processes. If LV was not blocked by I/O (disk) delays then I should see near 100% CPU usage. If LV was being delayed by memory swapping, the I should see less than 50% memory free,
I'll leave the discusion of Internals and Data Structure for another thread.
Spoiler (Highlight to read)
Both of my copies of that book are much more worn.
Both of my copies of that book are much more worn.
It is going to take some work to narrow down the possiblitlites since you have presented this situation as an interaction problem.
Generally speaking there is one hot button that comes to mind and that is the UI (User Inteface) thread where all GUI updates are handled as well as those things that do not play well if left to run in their own threads (property nodes for example).
SO I would like to suggest you start by trimming it down to something that work good and then start adding stuff back until you can detect the performance hit. At tath point step back and look for contention issues.
If I remebe correctly you can't post code images so asking you to post images of teh code that does not play nice together is a no-go.
You could also run the performance monitor.
THe Trace Execution tool kit should aslo help you get a the root of this situation.
Trying to help, wondering if if I can,
Ben
PS Regarding the bug thread. I depend on that thread to stay on top of potential bugs. I asked and Laura moved the off-topic posts to the proper thread. Please excuse my "anal-retentive" side.
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction -
Enabling / Disabling graphs and opening a new Front Panel Window
Hi,
I have a simple application of showing 12 analog signals on 12 different graphs placed vertically in aligned position. I have to develop a user interface so that if user wants to display signal no. 1, 4 and 6 out of total 12 signals, he should make selection using check boxes and click a re-draw button. It should result in opening a separate window with these three signals displayed as separate graphs aligned vertically and adjusted to fit window size. Similarly later user can change his selection of displaying signals (from same acquired data) say 1, 3, 5, 6, 8, 9, 11 & 12 and click Redraw button. It should result in opening a new Window showing all these signals as separate graphs which are aligned vertically and resized to fit the window. Now I have two major issues in this context.
1) I have been searching LabView help to locate a way to open a new window for this purpose but I failed to locate any way for it. As per my limited knowledge, it seems that we cannot have multiple "Front Panel" windows in Labview.
2) For the graph I could not locate a control to enable/disable a graph so that it appears or vanishes. Is there any way to achieve it?
I shall appreciate your valuable advice. I shifted from "Lab View Signal Express" to "Lab View" in order to achieve this user interface design but I am still not successful in finding a good solution for this application.
Regards
MnuetHi Mnuet,
You can do what was said above. Here is a KB on dynamically loading VIs. It looks something like this.
Dynamically loaded VIs are loaded at the point in code while running, as opposed to being loaded when the parent VI is loaded into memory like normal subVIs. You can make a reference to them and then control the front panel appearance, their run status, etc with property nodes and invoke nodes.
Jeff | LabVIEW Software Engineer -
Can I have an array of controls without having them in the array front panel holder?
I would like to link a number of boolean control buttons in an array without grouping them on the front panel the way it does when you make an array and then put in a boolean control.
Here's the background:
I have 8 linear motors controlled by CANbus, and so each button type (Move, Stop, Home, etc) is duplicated 8 fold. I have an event structure that is currently triggered with a separate case for EVERY button with only a very small difference in the code inside each case. Ideally I could have the buttons in arrays and then check the new array value against the old value on a value change event. The alternative for me is to have each case handle the 8 buttons (with a Mouse Down? filter event) and then use the Boolean.Text value from the CtlRef and search an array of all Boolean.Text Values for the 8 buttons to see which name matches and process accordingly. I have something like 200 buttons, so making the arrays of Boolean.Text values from the reference nodes is WAY too time consuming as I have to go through like 5 levels of right click menus. Any suggestions?Mark,
You might consider using clusters on the front panel. Create a type def'd cluster that has all the boolean controls for 1 channel. You can drop 8 of these on the front panel and the event structure can detect a change in a cluster. Easy to convert cluster to array behind the scenes. Remember that order of cluster determines index of value in array.
Message Edited by Wayne.C on 04-09-2010 05:19 PM -
LV 8.5 opens all sub-VI front panels
Hello,
Recently I again saw a strange occurrance that has happened to me about 10-12 times over the past year. Here specifically I am using LV 8.5 with the cRIO and FPGA module. When I was running a new RT VI from the developer environment, (deploying to the cRIO) the result looked something like this:
All the sub-VI front panels are opened, and shown in their reserved or running state.
None of these VIs are set to show front panel when called or opened, but all are sub-VIs of the top level VI within the project. It seems to have replicated a "Find all VIs in memory, within the project" and then "Show front panel" Invoke. The troubling thing is that this is not really repeatable, when I have closed all the VIs and run the VI again, it is fine. I have seen the same behavior in LV 8.2, 8.21 as well as when deploying to cFP-2120 or when on a Host computer.
Has anyone else seen this or are there any ideas of what is going on?
Thanks,
Mello
Message Edited by Mellobuck on 12-11-2007 01:17 PM
Message Edited by Mellobuck on 12-11-2007 01:17 PM
Data Science Automation
CTA, CLA, CPI
SHAZAM!
Attachments:
Multiple Windows.jpg 117 KBWell now that I have seen to image, I recall having seen this myself.
Like you, it was when I was deploying to an RT target and I was not able to recreate this behaviour.
It was either an 8.0 or a 8.2 app.
So all I can do is confirm that you are not alone, but can not offer a solution.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction
Maybe you are looking for
-
Dynamic text in Flash: a href="mailto:... tag?
I am using an Access DB to feed text dynamically to Flash. Although some simple html tags work in the text, I tried putting in <a href="mailto:[email protected]"> link tag in and it didn't work. Does flash not support mailto links in dynamic text? Is
-
Latency in upload of content search web part
Hi, We have a customer who use sharepoint which is adjasted to mobile, and it seems that when user access in vpn or mobile - it takes too much time till web parts are loaded. These are Content Search web parts that display pictures. Is there any set
-
HT3887 I m not able to found Bluetooth in my Macbook Pro. Error is Bluetooth : Not available.
I am not able to found Bluetooth in my Macbook Pro. Found error is Bluetooth not available. Please inform me.
-
Where is Lightroom 6 download hiding? I only see free trial downloads
-
I just got an HP Envy dv4t and it runs windows 8. My desktop, which is a Dell windows vista has all of my music on it. I'm trying to use home sharing between the two, but my HP won't pick up my dell's library, but my dell will pick up my HP's. I've t