dannyt

I would second that idea very much, the life seems to have fallen out of the OpenG forum's over the last year or so which seem doubly strange now that the OpenG Libraries have been recognised by NI. Danny

Well I am using the "Separate Source and Compile Code" system for a little while now and I am VERY happy with the results. I agree the process or getting all your VI's updated to 2010 and the check flag set is a BIG pain and I can remember feeling sad and shouting about the change in default from the first Beta to the latter ones. I only have the top level VI's in my LabVIEW project everything else is just a dependent and the Project Method of marking VI's does not work on dependants. Yes built times are slower in LabVEW 2010 by a factor of about x3 for us. Yes the general 2010 IDE feels slower to me. I did a similar VI to Shaun's, and I had real problems running it over my projects, I must have had my PC reboot on my around five times or more. Before I got it correct. It did not just fail but keep rebooting my machine. I got it working in the end, there are a couple of things that I do differently to Shaun's one. I also set the "seperate flag" for all the VI in LLb that exist in my source code and I do not convert all the heirarchy. We keep in our source repository old file that are no longer used, just for reference (and to rebuild old versions of course) and these VI 's were not upgraded to LabVIEW 2010 and so had no "containscompilecode" property. Why am I happy ? well doing some code change testing in LabVIEW 8.2.1 and LabVIEW 2010 I have already saved on over 200 files that would be marked as changed in LabVIEW 8.2.1 that are unaffected when doing the same change in LabVIEW 2010. That is 200 file fewer to do Quality Reviews on and track though our system..and just wait till 2011 comes out I will be able to test 2011 without checking my code base out and re saving it all. Final thing anybody using the VI Analyser should remember to write their own analyser test to check the state of the "separate source and compile code" flag

Very nice, work or fun ?

I really love this one, but ......... I often wonder where people get the time, do they live in some parallel dimension whereby they do not have to do the dishes, take the child to hockey or gym or whatever and all the rest

I think what we needs is a LabVIEW build plugin for Cruise Control CruiseControl is both a continuous integration tool and an extensible framework for creating a custom continuous build process. It includes dozens of plugins for a variety of source controls, build technologies, and notifications schemes including email and instant messaging. A web interface provides details of the current and previous builds. And the standard CruiseControl distribution is augmented through a rich selection of 3rd Party Tools. Dannyt

The "allow debugging" does have an effect on the executable file size and memory footprint, but here we are talking about the development environment just loading you top level in memory to edit / view or run it.

I like that one Paul

I just thought people might like a link to be able to find the info easily :-(

HI Martin, let me know if it does make any difference so I can see if I was going mad or not :-) cheers

I was only being tongue in cheek Ben

Hi, Yes I have seen this a lot and reported this to NI during the Beta Testing of LabVIEW 2010. It only affected the development environment , it appeared to me to need a lot more memory to hold my project than the same code in LabVIEW 8.2.1. Also LabVIEW does not seem to give up the memory when you close your top level VI and go back to the Welcome screen At one point by playing around, opening and closing different projects I managed to get to a situation where with only the Welcome screen showing has around 1G of RAM in use with LabVIEW. I do feel that the minimum PC requirement of LabVIEW 2010 should be raised to take this into account. In the Beta forums the NI guys convinced me it was not actually a memory leak, but due to 'pool clean-up' it was a few months ago and I cannot quite remember all the discussions, I got quite excited about this but nobody else seem to care. As you said it does not grow over time it only grows when you open up new VI in some way. Looking at my LabVIEW 2010 welcome screen only at start-up 100MB, load up my top-level exe RAM goes upto around 200MB close my top level and it stays at 200MB, opening my top-level VI again and still 200MB This is quite different to LabVIEW 8.2.1 I am not certain, but I think that generally the amount of RAM used for my project is less now I have installed the f2 patch than it was before, however there was nothing in the release notes to say there were changes that would affect that and I may just be me being mad. Do you have the f2 patch installed ? cheers Danny

Gosh are you saying Bug never get fix

For a list of LabVIEW 2010 Know issues look here LabVIEW 2010 Know Issues Could A LAVA admin please pin this as the 2009 thread is thanks Danny

so funny that's a great video

Hey Cat, congratulation it will be 1000 before you know it

Hi yesterday I noticed an f2 patch for LabVIEW 2010, just thought I'd post it here as nobody else has LabVIEW 2010 patch f2 Details

I have tried to open the VI in LabVIEW 2010 running with patch f2 and I get the same error, I suggest you raise a CAR with NI that the problem still exists in 2010 and patch f2 Dannyt

I think I was half asleep when I said yes, now I am awake it not so good, still people will either be interest or not

Took my CLAD a couple of weeks ago at the NI Developer Day in Bristol and passed so I am well chuffed I did take it a couple of years ago, but NI lost the exam papers when they posted them back to the States. I am also due to do a small presentation (very small) at the London NI Days event, not sure quite how I found myself in that position as I am not used to doing that kind of thing, a little worried but looking forward to it as well Dannyt

:star::star: Oh Thank you LORDS OF LAVA LOL's My Portal returns, I can now happily travel through time again. Seriously guys thanks for that, I for one appreciate it :beer_mug: Dannyt

Thanks for all the replies as always. Shaun, cheers that was the way I was leaning on this, I just wanted to see if I was missing something, I have seem more general chatter about them of late. I have not had to do any network LabVIEW to LabVIEW programming yet in and if I do I suspected I my take a lot more serious look at them them. cheers

Hi All, Sorry for maybe a silly question, but I was reading another thread here talking about shared variables and I starting thinking and not for the first time, are they any different, well any better than Global Variables in principle. I understand that unlike Global Variables they have a lot more functionality, but do they not share the same problem of over use and breaking of Data Flow issues especially when used in Single-Process Shared Variable Case. I would be interested in people's comments cheers Dannyt