Mellroth

I get Error8 from App Builder, but only if Subversion (SVN) & Tortoise are installed. I posted the problem to NI Forum, and the solution from there didn't solved my problem.

Plese refer to: http://forums.ni.com/ni/board/message?boar...ssage.id=172537

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

EDIT: As a birthday cake I provide the community Create Multiple Occurrences subVI I just wrote. The VI is inspired by Ben's community nugget from today. The occurrences are distinct under any circumstances unlike the occurrences directly created with Generate Occurrence node or unlike notifiers. Creating many occurrences using this VI should be relatively fast. The Create Multiple Occurrences node is distributed under BSD license i.e. you are free to use it in any of your project with no charge and no obligations. The file is for LabVIEW 8.0 or later. I don't have earlier versions of LabVIEW installed on this computer.

Congrats, Tomi!

Very nice cake, I hope you don't mind if I did some changes to it:

1. 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.
   
2. It doesn't close opened VI-references to allow for occurrences to stay active.
   
3. 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

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

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

are you shure? I have my "knowledge", because in one of my last RT projects with LV 7.1, I had to learn, that using the exit LabVIEW primitive in the RT main VI can lead to that "weird behavoiur" (the startup.exe was restarted in parts when connecting with MAX). I did not experience, that the exit LabVIEW primitive forced a controler reboot

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

A MacIntosh.

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 politely disagree:

The Exit LabVIEW is NOT intended to be used on RT machines, therefore it is not included in the RT-View of the Appcontrol palette.

Using the exit LabVIEW primitive on an RT machine is not recommended, because it can lead to weird behaviour. I have experienced that such VIs can restart occasionally, e.g. if you connect to the RT machine via MAX. Maybe it could reboot the machine, but thus is not intended.

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:

As far as 'Quit LabVIEW' goes, it is supposed to reboot the controller, becassue of the shutting down of the RT engine when LabVIEW shuts down.

The LabVIEW Runtime Engine closes automatically when all VIs have stopped, so you don't need any mechanism to close the Runtime Engine explicitly.

So the answer to the question could be: stop all your VIs (e.g. with occurences) if you detect the power down and exit your application "the normal way". If you don't have a normal way, it would be wise to create one

I totally agree

/J

What about the 'exit LabVIEW' function?

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

i tried your suggestion and what happens is that you still cannot replace or edit the green part with a circle for example, or even rotate it. other suggestions?

thanks

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

Here's what IT tells me they changed:

"Before you were going to \\server03\username$ now you are going to \\server04\users\username where it's not a security issue more so a UNC Path.

We were using: Windows Storage Server 2003 and now we are on Windows Storage Server 2003 R2"

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

do you know how to change the shape of the green part of a push button?

i'm using Labview 6.0.3.

thanks

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

It is only after some data is tried to be send and no acknowledge is received from the other side that the TCP layer will say that the connection is lost. But that is usually only after a considereable time (at least half a minute but possibly a few minutes). This is why it is often good to have some form of keep-alive built into your app, a packet that is sent from both sides at regular intervals.

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

If you can reproduce, I will bother NI with that - if not Stephen cares about that

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

Because there are something like 10 different VIs that each would have to come in a different versions, and they are called in maybe 50 places in total. So that would amount to a lot of case structures if I put one in every place where one of the VIs were called.

Yeah, unfortunately this project is in labview 7.1 .

Thanks for your reply!

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

Now I have to implement another critical module in my LabView application which requires me to implement Fuzzy Logic scripts in OOP form. There is going to be lot of data analysis and this application is real time. I am wondering if I can use LVOOP to program my module. Is LVOOP the best option for me to implement this OOP code in LabVIEW or can i get away with some other option. In the past I have done OOP in Java and C. I am an amateur LabView user.

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

-------

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:

1. LabVIEW crashes when closing the Problem.VI after it has been run.
   
2. 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

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:

1. LabVIEW crashes when closing the Problem.VI after it has been run.
   
2. 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

it uses email to keep everyone informed of everything that is happening

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

requirements:

• Multi-user
  
• Multi-project
  
• Web based
  
• Open source
  
• Good performance across distant networks
  
• Inuative interface
  
• Comprehensive reporting functions
  

Desired attributes include:

• Integration with Subversion
  

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

i thank you for your help but the program does not display the output in the indicator that outside the loop

WHY ?????

and this is a new problem , how can i solve it???

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.

Indexing output = array to display = all values

non-indexing output = scalar to display = only last value

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

Now I'd like to know purely from technical point of view if it is possible to run multiple instances of LV devel environment on W2003 server without problems. I know it's not supported but it may still work. I have already discussed with local NI about the licensing issue and they have no problems with us testing it. However I'd like to ask you folks before I go and buy Windows server licenses and set-up the server.

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:

>Create a new shortcut on your desktop that points to the labview executable.

>Once created, right click on the new shortcut and select properties.

>In the text box labeled "target" will be the full path to the labview

>executable.

> example - "C:\program files\national instruments\labview\labview.ex"

>At the end of the entry place the path to your new ini file.

> example - "C:\program files\national instruments\labview\labview.ex"

>-pref "C:\my preferences\\labview\labview.ini"

>Note that "" must be used if your paths have spaces. Also, the entry '-pref'

>must have a space before and after.

I noticed that the Flatten To String function in the attached LV711 VI does not stay in the "Convert 7.x data" format mode.

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

If you are going to be running from the development environment, an easy way to prevent the dialogs is to make all of your VIs 'Read Only' AND set the LabVIEW Options to "Treat Read Only VIs as Locked" And "Do not save automatic changes" to checked.

Good point, you are right that this is the easiest way.

But, you would have to accept the same settings for all VIs/projects, and you must also take into account that moving between computers also involves setting the right checkboxes in the LabVIEW options.

I still feel that the main question is why the save-dialog should be supressed at all?

/J