dannyt

Published in January 2013, this is the official directive on closing references: when you need to and when you don't.

http://www.ni.com/white-paper/14393/en

 

In your picture, the code shown is fine. Moving the Open and Close inside the loop would just create a performance burden. Moving only the Close inside would cause run time errors since the reference would be closed on the second iteration.

If I wanted to go one stage further and put the Front Panels of these launched VI into a subpanel, I assume I do NOT want to close here at all but gather up the array of references coming out of the loop to pass into the "Insert VI " subpanel method as required. I would then need to close the full array of references when I no longer needed them for the subpanel.

Hi, Thanks for the extra info. My system does work so I must be doing this correctly, by luck I suspect.So I have a top level typical event driven state machine system and it calls this subvi just before it enters the state machine while loop. If I understand what you are saying, I cannot make the calling of this subvi its self a dynamic call

Thank you for the reply and I will be reading the link you posted tonight

cheers

Danny

Hi,

Quick question regarding my closing of my VI references, I suspect I am doing this wrong. Should I have the close reference inside my for loop and close it each time ? The code works fine I have been using it for a while now, but I was doing a review and noticed this.

any comments please

cheers

Danny

I really would try and understand that example it would be worth the effort, run it a few times with the highlighter on, you would gain a lot I think.

However try the attached file as a starting example

Untitled 1.vi

Hi

Not sure if you are already aware of this but there is an example VI installed with the toolkit.

Look in C:Program Files (x86)National InstrumentsLabVIEW 2011examplesOpenGdictionary or whatever you version of LabVIEW is. In that directory is a 'Dictionary Example.vi' file that shows you how to use it.

Hi,

In the last couple of years I have taken over a large amount of LabVIEW code written in German, and I speak, read, write no German.

To be honest the language of the IDE was NOT the problem, where the developer knew what he was doing and had written the code with style it was simple to understand and maintain (with a little help from Goggle Translate on the comments), where the 'other developer ' had no idea what he was doing and no concept of LabVIEW style the job was hell (and would have been even in English).

The single issue that caught me out in terms of IDE language that I did not foresee or expect was  "localisation issues"  in particular  "use system decimal point (T)" input to certain LabVIEW VI's or default  use of "system decimal point" in others.

use system decimal point defines the decimal separator. If TRUE (default), the decimal separator uses the localized decimal separator. If FALSE, the decimal separator is a period.

In the past I have always written code on English PC's  and then run the built executable's on English PC's which use "." as the decimal point so I had never really given localisation any thought.

I was stumped initially when I had an executable that worked OK in the UK but failed when deployed to Germany.  It turned out that scan from string function and some other VI's  were locale aware and in Germany the decimal separator is "," so my parsing of GPIB output was all wrong.

The simple solution to this is place useLocaleDecimalPt=False into the executable's ini file at build time.

hope this helps

Dannyt

Thank you for the update, I had better download the new version and take a look, I am running quite an old one and had forgotten to keep and eye on changes

Hi,

I am working on Windows 7 using LabVIEW 2011.

I have a PC with two NIC cards in it, plus the onboard LAN connection and I am trying to run Iperf from one NIC to the other, through a wireless system.

To archive this I need to play around with the Windows route table to ensure to packets go out through the correct NIC. I found at one point in my experiments with this that, LabVIEW start reporting Not Responding messages, both when running my program and when in edit mode, LabVIEW was locking up for a few 10's seconds then continuing.

It finally dawned on me that this was after I had completely clear out the route table apart for two entries I had put in. On replacing the localhost entries 127.0.0.1 back into the routing table this Not Responding issue went away.

Does anyone have an idea what would be behind this behaviours ? I assume it is some sort of continuous poll to the Vi server by LavVIEW.

Cheers

DannyThomson

(null)

I was just adding a some links to YouTube clips demonstrating the usage of the WireFlow ProgressBar module and now I see it beeing referenced ;-)

/J

Thanks for drawing my attention to the WireFlow ProgrssBar I have not come across this before, it looks quite interesting and something I think I should find time to play with.

Please can you post a link here when you have the demonstration clips on-line.

cheers

Dannyt

I would like to add my thanks to all the others here, this is really great for those of us not able to attend such a great event.

:beer_mug:

Thanks again

I don't remember where exactly but it is similar to what bmoyer just said.

As I said in a previous post I got dynamic loaded VI working OK in an executable with compile code seperated.

BUT that was only after I moved away from the old LabVIEW 8.x.x layout format. While trying to get my system working I did at some points get an error message when running the executalbe that blamed the seperation of compiled and source code, but in truth I think the error message was incorrect /misleading and the real error was down to my paths finding and loading the VI correctly.

Once I had figured that out everything has been working fine.

Yes I do use TypeDefs normally strict type's but I do not change them very often. My build scrpts often clean out the compiled code caches maybe that helps.

Seems to work OK for dynamic loaded VI's now that I have moved away from 8.x.x layout

I could not wait for the option to seperate compiled code and source code and have been using it from day one in LabVIEW 2010, so I have been using it in LavIEW 2010 and then LabIVEw 2011 and have had no problems with it myself.

I do not use Objects and have a sinlge top level with around 1000+ vi in a application I do use dynamic loaded of VIs

Congratulation, twice the fun. All the very best you and your Mrs

How long does the reply take in the hyper term example, and what time out are you using on the read, it might be worth playing with the VISA timeout value on the configure serial VI.

Also if you do a goggle search on "labVIEW serial error -1073807339" you will get a number of existing threads on here and ni.com that might help

So where actually does you VI go wrong ? Does it connect OK ? does it time out on the read or write ? can you provide the error message

I tend not to use the the basic visa read on it own as you have done. I always use it alongside "Bytes at port" inside a loop and the whole thing in another loop to look for a matching termination character.

I think the solution to this already exist as several people said in the form of the VIPM when it is used along side VIPC files.

You could have on LAVA and NI community sites people's top VIPC files as voted for by you the public, this would give new users a number of examples of the types of configurations used by experienced user.

The two problems with this solution are, one that not all good extras and add-ons come in the package format, however the use of packages is growing ever stronger. The second problem is that the VI configuration files are only supported in the Professional version of the VIPM and that in itself will stop then becoming a mass market way of sharing.

I really like the VIPM but like ShaunR I still find it amazing that NI never came up with something like this as part of the professional version of LabVIEW

Hi,

I now always work with two monitors, I do not konw how I would live without two. I work in the same ways as hooovahh but use the free version of http://www.mediachance.com/free/multimon.htm.

Our coding standard still insist that a VI block diagram fits on one standard screen, though we will allow a little left /right scrooling on some occasions. This is because we all have two monitors on our development setup but not on the shop floor nor at home. Also I feel it tends to breed bad habits in coding thinking you have all that realestate.

Not totally sure I have understood your question correctly by string convert to number tools do you mean Scan From String ?

Scans the input string and converts the string according to format string.

Use this function when you know the exact format of the input. The input can be string, path, enumerated type, time stamp, or numeric data. Alternatively, you can use the Scan From File function to scan text from a file. The connector pane displays the default data types for this polymorphic function.

Would help if you showed you block diagram

I see what you mean.

Now Lava has the OpenG forums would it not be better to put the OpenG site to bed so as not to sully its well earned reputation

We would not want a sad looking Dragon, that would make us all sad

EDIT, just re-read my post and would like to clear up any misunderstanding BEFORE it happens, I was referring to the ICON and nothing else

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/I-would-love-to-have-a-Native-LabVIEW-DHCP-server/idi-p/1891513

Have you ever wanted a Native LAbVIEW DHCP server.?

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/New-VI-Analyzer-Test-check-the-quot-Separate-compiled-code-from/idi-p/1882483

A missing test in the VI Analyzer test suite

That only works if you can remember what was in the rest of the thread

I would move up to LabVIEW 2010, the separate source & compile code feature is great I would say a must for team working situations. I have been working with it for a couple of years with no problems.

I would also agree with candidus, planning an communication are key for team working.