dannyt

For me the new separate source and compile code, at last you can develop in parallel with a team and use source control in a really useful way.

But my pet hate is that you cannot wire a VISA refnum to an event case like you can with DAQmx. But more generally, the "probe window" introduced with LV2009.

Oh I so agree with the new probe window. I think a number of the "windowed" IDE addon's are like that, only half thought out in usability terms. The heirarchy view is next to useless in any real way.

Dannyt

Hi all,

I have got the LabVIEW LVCompare.exe working with ClearCase on windows.

This means that you can do LV differencing using the source control integration with LabVIEW or from the ClearCase explore or the tree view.

Would anybody be interested in a step by step guide on how to do this ?

For those in the know you just need to edit the ClearCase map file ( C:\Program Files\Rational\ClearCase\lib\mgrs\map ) and change the compare & xcompare type managers for the correct file type.

z_whole_copy		compare				..\..\bin\cleardiff.exez_whole_copy		xcompare			..\..\bin\cleardiffmrg.exechange to z_whole_copy            compare                     	..\..\..\..\NATION~1\Shared\LABVIE~4\LVCompare.exe z_whole_copy            xcompare                        ..\..\..\..\NATION~1\Shared\LABVIE~4\LVCompare.exe 

but as I said if anybody was interested I could do a step by step guide.

Danny

Thanks for correcting me Darren and sorry for making the wrong assumption.

Danny

Hi,

I already have the code in 8.6 and like to maintain in the same. I need to fix the issues from the rsl file got from VI Analyzer 2010. No need for 8.6-2010-8.6 conversion.

Is it possible if we use same tests in both 2010 and 8.6?

Thanks,

Suresh

Sorry Suresh, but I am being very slow here and I still do not quite get what you are asking.

So your LabVIEW code is written in LabVIEW 8.6 ? You are loading up you code into LabVIEW 2010 and then running the VI Analyzer ? saving the *.rsl file and then starting up LabVIEW 8.6 and trying to load the rsl file ?

LabVIEW compatibility matrix look about halfway down, it looks like you cannot do what you want to do.

Hi all,

Is it possible to use result file from VI Analyzer 2010 in VI Analyzer for LabVIEW 8.6?

I tried but the failure node was not opened respective to the occurrence selection. it throws error message when clicked. But works fine with 2010.

Is there any format to use in 8.6 or any conversion methods?

Suggestions welcome.

Thanks,

Suresh Kumar.G

I assume you are talking about a *.rsl file that you save after running a VI Analyzser test in LabVIEW 2010.

I have not actually tried this but as the 2010 VI Analyzser has new extra tests in it that the 8.6 Analyzser will know nothing about I would not expect it to be backwards compatable.

What are you actually aiming to do here, it will be easier to offer help / suggestions

Here is the video : http://www.vimeo.com/17700095

<iframe src="http://player.vimeo.com/video/17700095" width="400" height="300" frameborder="0"></iframe><p><a href="

This is a work in progress of course, any suggestion is very welcome.

Wow, that look really useful.

Your reply has left me a little confused, I only put the outer for loop in with a simple hardcoded 4 to show you what the output would look like with several lines in it.

My answer was only meant as a guide to show you one possible way of doing what you want to do and I was leaving you to put it into your solution

How you decide to run you loop generating the data is up to you, it can be a while loop with an exit or whatever you want. If you want to update the output one line at time then just put you string indicator inside the loop.

Danny

This may not be the most efficient way but it does work and allows quite a bit of flexibility in you log sting

i use the read port function in Dll using invoke node.. return is byte array i convert it to string concatenate with the input from shift register (prev interation data in log)

and display it on string indicator in hex mode..

what display mode do you have on your log sting ? normal display or "\" code display ...... if you have it set to the code display one then yes you line feed will be seen as you say, it will only appears as a line feed in normal mode. As I said before you should look at the format into string method this will help you build up a log string with timestamp and text and other data types.

Danny

Hi Madhav

It would help if you posted an example or snippet of you code, but if I understand you problem correctly rather than use concatenate, you should be looking at the "Format into String" function, that way you can build up your output string from a number of different input types, ie hex number / time stamp and also easily put in formating like tab or linefeed.

hope this helps

Dannyt

Hi,

Have you done a general Web search of "labview error 1172" there are quite a few hits regarding that error.

Failing that you really need to post your VI or at least a screen shot of it for people to be able to help

cheers

I see that there has been a ?!@*-ton of spam on the OpenG General Discussion forum this weekend.

Just a thought; maybe the discussion forums could be moved to LAVA? It might provoke a bit more involvement in OpenG in general and the more robust forum software would stop the spammage (is spammage a word?)

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

Do you have "Allow debugging" active on your VI's? That's something that's always disabled in a compiled EXE and would explain the difference.

/Y

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.

No good deed goes unpunished. Butthead.

I like that one Paul

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

Danny

Well, regarding the f2 patch; installed on some but not all.

I'll make sure to install it all over, and see if that helps. Thanks.

Martin

HI Martin,

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

cheers

There will always be bugs that carry over from one version to the next.

That does not mean that none of the bugs are being fixed.

For all bugs to be fixed all development would have to come to a halt and about six versions of BETAs would have to be run. As long as the show-stoppers get fixed and progress is made on the rest, I'm happy.

Ben

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

Same as 2009 known issues....same as 8.6 known issues..same as.....

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