Mellroth

Hi, just wanted to point out that you will also get error -1003 if you try to load a dynamic VI, containing FPGA code, using option 0x08 (reentrant run) in the "Open VI Reference". In this case the error is somewhat misleading as the VI is executable, but not with the selected option. The developer distribution works great, just create a build for the desired target (include vi.lib, instr.lib if needed). Build, and download the distribution folder to your target and run your dynamic VI. /J

Hi, I've seen the same error but with ClearCase. I get this problem when building applications where the destination directories/files are version controlled (and checked in). The solution for us has been to check out all destination files, or select a destination folder that is not under source control. Good luck! /J

Congrats, Tomi! Very nice cake, I hope you don't mind if I did some changes to it: It now remembers the notifiers from call to call, so that requesting 1 occurrence at the time, does not require recursive call unless there are no more occ. in buffer. It doesn't close opened VI-references to allow for occurrences to stay active. When requesting more occurences than available, the recursive call requests complete buffers only, i.e. avoiding nested calls as I think that is slower. Download File:post-5958-1170227460.vi Again, congratulations, and keep up the good work :worship: /J

Now I'm 100% sure, the RT target rebooted when the "Quit LabVIEW" primitive was called (at least in LabVIEW 7.1.1). When the RT target rebooted while the FrontPanel of the RT application was displayed, I had to kill the LabVIEW-RT process in "Task manager" before I could start my RT application again (using the command line interface). /J

I'm quite sure (not 100% as this project was a few years back). In that project I called "Exit LabVIEW" to shut down. When the controller rebooted I contacted NI, and got the response I quoted in my previous post, i.e. that the RT-controller is supposed to reboot when this primitive is called. I'll see if I can find that old project in ClearCase on monday... /J

So you're not only writing good comments everywhere on LAVA, you're also a Mac user... :worship: I've been a Mac user since -93 (Mac Classic II), and I've never looked back (even tough I'm on the dark side at work). Have a nice weekend, and ask your Mac to fetch you a large Whisky, you have deserved it. /J

I actually don't think you disagree , since I did not mean that you should use the Exit LabVIEW primitive. I just pointed out that if you do use it (as suggested by tcplomp), the RT-target will reboot (not shut down) when called. In LabVIEW 7.1 there is no RT-view of the application palette, so you can use it on an RT target by mistake. I actually did that a while back and asked NI about it, here is the reponse: Regarding the last part of your comment; I totally agree /J

If you execute the "Exit LabVIEW" function in LabVIEW RT 7.1, the RT controller will reboot. To read a DI line to detect power failure, seems to be a good way to be able to clear things up, before power is cut. /J

Right click on the parts you want to change and select import picture. This has to be done for both states (On and Off), i.e. swith boolean state between edits. Attached is a control where I replaced the green part with a triangle. Download File:post-5958-1169745969.ctl I'm sorry I don't have LabVIEW 6.03 available so the control is in LV 7.1.1 /J

Hi, have you tried to copy the files manually in explorer? The reason I ask, is that we are having a lot of problems to copy files over a VPN network. The files are not corrupt, as I can copy them when I'm in the office, but as soon as I connect through VPN some of the files are impossible to copy. The error we get in expolorer varies, e.g. "Path is to deep" "Network address no longer exist" I found some links, that suggested that changing some of the network settings should resolve the issue. http://codebetter.com/blogs/sahil.malik/co...px?PostID=23742 http://forums.enterpriseitplanet.com/printthread.php?t=2109 Sorry to say, it didn't resolve my problem with VPN, hopefully it can solve yours. /J

1. select the push button 2. in Edit menu select; "Customize control..." 3. while in control editor, locate and press the button with a wrench (in the Toolbar) 4. use the "parts window" to access the different parts that you want to replace or edit. Good luck! /J

I think you can access the lower layers of the IP stack to enable/disable Keep alive packets as well as setting the period of the Keep alive packets. We had a problem with delays when transferring small pieces of data, the solution was to disable the Nagle algorithm (buffering of small packets until an efficient size is gathered). To do this we used the code in the folling link as an example: http://digital.ni.com/public.nsf/websearch...39?OpenDocument As I remember, we also tweaked other network parameters (enabling/disabling KEEP_ALIVE messages etc.) using a similar approach (GetRawSocketFromConnectionID). In VISA-TCP/IP you can also set some of these parameters through property nodes. /J

CAR# 3SL9US00. Update: LabVIEW 8.2 will also crash if you create the Problem.vi for a FPGA target, and then open the VI in "Main Application Instance". The reason seems to be that the VI remembers what target it originally was created for, and therefore uses a special version of the "Initialize array" node, that outputs "fixed size array". /J

CAR# 3SL9US00. /J

Hi, crashes here as well. I replaced the WFM-constant with a numeric array constant, and then there is no crash. But as soon as I go back to that Wfm constant, I get the crash again. /J

HI, I think David meant that you could add a case structure within the VIs in question, not where they are being called. This way your VIs contain both your development code and your release code. You would still have to add some switch mechanism to select which case to use, maybe a GLOBAL (oops, did I say that, sorry ) that is set when you initialize your program. /J

Hi, you mention Real time, do you intend to run your program on an RT-platform? If you are, I don't think LVOOP will work, since it is yet to be released for the RT platforms (if I'm wrong, Aristos will probably jump in and correct me). /J

I reported this bug december 2005, and just recently checked if it was still present in LabVIEW 8.2 (sorry I don't have a CAR for this one). Added the bug to the LV7.1.1 bug list as well: http://forums.lavag.org/LabVIEW-crashes-wi...-711-t5888.html The same crash appears in LV8.2 if the LV7.1.1 VI is opened, but not if the code is created from scratch. Somehow LabVIEW is using a special version of the "initialize array" node in LabVIEW 7.1.1, and when opened in LV8.2 this version is still being used (generating "fixed size array"). Developing new code in LabVIEW 8.2 is not a problem, its only when you open up old 7.1.1 code you might run into this crash. What really annoys me is that the two VIs, Problem.vi and Problem-solved.vi is more or less identical, its only when you check the type of wire you can spot the difference. Download File:post-5958-1169204334.zip /J -------

I reported this bug december 2005, and just recently checked if it was still present in LabVIEW 8.2 (sorry I don't have a CAR for this one). /J ------- The Problem.vi contains a pre-allocated array, that is populated by using a second array that is auto indexed in a FOR loop. The crash: LabVIEW crashes when closing the Problem.VI after it has been run. LabVIEW also crashes sometimes, if you edit and try to save a VI (Caller vi), that has the Problem.VI in its sub-vi hierarchy (Caller VI must be run first in order to crash)) Solution: Change the dimension size input (Initialize array) from constant to control (this changes the type of the array wires) the pre-allocated array changes from "1-D fixed size array [100] of" to "1D array of". the output from the Array subset node changes from "1-D bounded-size (sub) array [100] of" to "1-D (sub)array of" In LabVIEW 7.1.1, I have the FPGA toolkit installed, maybe this is forcing LabVIEW to use a special version of the "Initialize array" node? Download File:post-5958-1169203496.zip

the email notification is easily configured, so you only get the events that you want. /J

If you think bugs is the worst you could find in you VIs, think again. Just check out this "Untitled VI" http://www.riksutstallningar.se/EditExtens...mp;type=Webbild /J PS. The link is to a picture of an upcoming art exhibition in Gothenburg, Sweden

Have you tried Bugzilla? (http://www.bugzilla.org/) Its pretty easy to use, and seems to meet all your requirements (I don't know about Subversion though). /J

HI, didn't the suggestion from Albert and others solve your issues? If I edit the Problem.vi as suggested, I get the result outside the loop (note that only the last value is available). On the other hand, if you want all calculated values available after the loop has finished, then you'll have to use array indicators instead of scalars. If this VI is part of a larger program, I think you will have to explain a bit more want you want to do, before you can get any more help. /J

We have used Terminal Server and LabVIEW 7.1.1 and LV8 with no problem. Just a suggestion; 1. create a separate labview.ini file for each user (store in user data) 2. each user should also create a shortcut to LabVIEW, e.g. on the desktop. 3. edit the shortcut to make LabVIEW launch with a user specific ini file (see below) If you don't do this, all users will share the same labview.ini file, and therefore all settings. /J From info-labview:

Hi, the reason for this is that this VI doesn't use the type-descriptor output (your other VIs probably do), so there is no need to use the LV7 version. See attached VI. Download File:post-5958-1168604159.vi /J