dannyt

QUOTE (AnalogKid2DigitalMan @ Jun 6 2008, 04:21 PM) Typical. Once again the BS 1363 rectangular blade plug isn't included in the package, so we Brits have to buy an adapter!!!

QUOTE (Michael_Aivaliotis @ May 13 2008, 08:04 PM) Hello Michael, Not often that I post and feel I can actually ofter something, but you might be interest in looking at OpenG forums compare to disk tool in this thread I proposed a fix for the compare to disk tool to get this it working in LabVIEW 8.x and posted an an working example it uses the file project\procmphier.llb\CMP compare two VIs.vi with the correct application contexts. You can use this example and just replace the "disk version" with any Vi you want. I am working on getting it to automatcially do compare with different ClearCase Version at the moment. Thanks for the great site.. LAVA ROCKS !! regards Danny QUOTE (MikaelH @ May 13 2008, 11:03 PM) This is the way I've implemented it and linked it to TortoiseSVN http://lavag.org/old_files/post-941-1210716158.zip'>Download File:post-941-1210716158.zip Cheers, Mikael Mikael I would be really interested in looking at how you have done this integration, but I do not have LabVIEW 8.5, it is possible for you to please post a LabVIEW 8.2.1 version, I would be very grateful regards Danny

You might be interested in looking at the OpenG builder application OpenG, it has a nice auto-increment revision system build into it and so much more Within the builder there is a "Build Version Control " option, you name a Revision text file , which OpenG looks after for you and using this file as a seed, it auto-increments on each build the build number and inserts this value into a LabVIEW Control. Basically you select one of your VI maybe your top level VI or an About.vi launched from your top_level and on that VI you place the control you want OPenG to populate. cheers Dannyt

Hi All I have a rather puzzeling problem, I have a few VI's written and working using the ClearCase Automation Library (CAL), ccauto.dll. I am using LabVIEW 8.2.1 on Windows XP my problem is limited to running in the development environment only. I am using an Automation Open Vi and passing in a Automation refnum generated by using the Browse ActiveX Class ClearCase.IClearCase I have got everything working fine on my machine. Then came the time to roll this feature out the other LabVIEW developers here, however when these VI's operate on other peoples machines though everything works correctly, I was very supprised to get a prompt to save changes when I went to closed these VI's down. The list of unsaved changes give "An external component referenced from this VI changed causing the VI to adapt to the new interface." as the reason. Both PC are running the same version of ClearCase, the ccauto.dll is located in the same place on both PC's and when examine the dll's (using InspectExe) they are both the same version 6.16.0.943 and even the same checksum. When I browse the ActiveX Class's on both PC's the Library type on both is the same Library 6.0 Version 6.0 Could anybody please shed some light on why these VI might seeing a change to the external interface. I will not be able to live which the situation of resaving these VI's for each PC so if I cannot figure this out I will just remove the call's to ccauto.dll and replace it with command line instructions regards Danny

QUOTE(tcplomp @ Nov 22 2007, 07:28 AM) Ton, The answer, with any SCC provider, is the same if you wish to run automated build / deployment sysyems. You need to get down with the low level commands provided by the SCC provider. In this respect LabVIEW is no different for any other language. ClearCase, CVS and Subversion all provide access to thier full functionallity via the comand line. All three of them can only really be used to thier full potential when used with tools you write yourself to get them to do what you want, it is that ability that makes them so great to use in these situations....... but you do need to really understand the SCC tools you are using. I have worked on many automated build & deploy systems using C, C++, Java and Databases in both ClearCase and CVS and in all case's, the automation was achieved by writting our own scritps (usually for me in perl or ksh) to direclty access and mulipulate the SCC systems, they are intended to be used in this way. I have never worked on a project where the tool suite to automate build / release etc, used the MSSCC interface, it provides a very small level of functionallity that only really allow IDE's to be tied into a SCC system and makes checkout checkin easy. For ClearCase there are three ways to go 1) the ClearCase automation library (CAL) this will not do everything you masy want. 2) ClearPerl a well established Perl module for doing this in ClearCase and 3) directly calling the cleartool commands via either a command promt or better still a unix shell. I have not done this stuff with subversion but I would start with writting my own LabVIEW tools library for subversion calling the subversion command line client an added after-thought Having just written this reply I realise my previous post was being a little unfair to NI, when I replied to Ton's question of why I bypassed the LVSCC interface, though I still stand by everything I said, it is fair to say that these issues are true to all languages I have come across and it is not unreasonable that as automated build / deployments issues vary so much from user to user that one needs to step beyond the normal integrated functions provided. cheers Dannyt

QUOTE(tcplomp @ Nov 22 2007, 07:28 AM) Ton, The answer, with any SCC provider, is the same if you wish to run automated build / deployment sysyems. You need to get down with the low level commands provided by the SCC provider. In this respect LabVIEW is no different for any other language. ClearCase, CVS and Subversion all provide access to thier full functionallity via the comand line. All three of them can only really be used to thier full potential when used with tools you write yourself to get them to do what you want, it is that ability that makes them so great to use in these situations....... but you do need to really understand the SCC tools you are using. I have worked on many automated build & deploy systems using C, C++, Java and Databases in both ClearCase and CVS and in all case's, the automation was achieved by writting our own scritps (usually for me in perl or ksh) to direclty access and mulipulate the SCC systems, they are intended to be used in this way. I have never worked on a project where the tool suite to automate build / release etc, used the MSSCC interface, it provides a very small level of functionallity that only really allow IDE's to be tied into a SCC system and makes checkout checkin easy. For ClearCase there are three ways to go 1) the ClearCase automation library (CAL) this will not do everything you masy want. 2) ClearPerl a well established Perl module for doing this in ClearCase and 3) directly calling the cleartool commands via either a command promt or better still a unix shell. I have not done this stuff with subversion but I would start with writting my own LabVIEW tools library for subversion calling the subversion command line client an added after-thought Having just written this reply I realise my previous post was being a little unfair to NI, when I replied to Ton's question of why I bypassed the LVSCC interface, though I still stand by everything I said, it is fair to say that these issues are true to all languages I have come across and it is not unreasonable that as automated build / deployments issues vary so much from user to user that one needs to step beyond the normal integrated functions provided. cheers Dannyt

QUOTE(tcplomp @ Nov 21 2007, 02:53 PM) This is a quick answers and not complete. The low level NI SCC are password protected so that is a pain. The NI SCC tools for the Clearcase interface work at to high a level and do not give you anything useful to work with for an advanced ClearCase user or admin, for example the SCC File Properties.vi and the SCC File History.vi launch the ClearCase properties window and History browser respectivly, there is not a lot you can do with that. Whereas to generate a bill of meterial I want to a File Properties VI to return a string I can then work on. There is an advance option input to both these VI's but with no documentition on the format or API of these (that takes me back to point one) There is a large amount of ClearCase functionalilty not available with the exposed interface (I am sure somebody will correct me here ), getting or even changing a ClearCase view configuration specification, getting a list of files on a branch, get back checkout / check in commets applying labels baselines and much more. ClearCase can be a great tool, but only if you spent time getting this level of stuff working to help you. What settings there are for the configuration of using their VI like "checkin even if identical" are up at the configure source control advanced level. If you are trying to auto builds / labeling / deployment you need to do these things programatically. Finally, and I am not sure if I can explain this correctly but the built in SCC for ClearCAse seems to be built more around ClearCase UCM and not the far better (IMHO) Base ClearCase. The source control Project concept in LabVIEW for ClearCase at anty rate just does not work for me. I have several views and branchs on the go at any one time (1 view = 1 branch = 1 fix) when I finish with a view to goes, in fact to get LabVIEW Clearcase interface working I have a fake view mounted all the time just to stop LabVIEW complaining when I lauch it with a newly created view. Plus I only had LabVIEW 7.0 when I started. :ninja: anyway that my thought on the matter. edit sorry I forgot, attached is the sort of extra info I put in the build log file http://lavag.org/old_files/post-7256-1195661907.txt'>Download File:post-7256-1195661907.txt Dannyt

QUOTE(gmart @ Nov 21 2007, 01:02 PM) I find this a major pain in the butt with LabVIEW, it is like trying to source control object files in C. It could be dealt with so much better by NI. In fact the whole ClearCase integration could be a great deal better. There are think two levels to this problem, one is the basic inconvenient of checking out all these other files and the second is more major, a basic function of configuration control if tracking what has change and why. If you do code reviews or support parallel release or look back at what happened, you wish to see the actual files edited by developers to fix a problem or add a new piece of functionality and not to have to search for those files on a branch that contains 20 or 30 re-compiled files. One suggestion on how to cope with this is a follows, this works if most of your work and testing is in the development environment, but would be harder if you are doing builds. You do not have to save all your changes to disk for your VI / project to run. So when you start only checkout and save files you are actually editing and do not save any recompiled Vi changes, this is fine as in memory they are OK for you to test with. When you are happy with your changes and things are working well. Load up your top level project and then close it. In LabVIEW 8.21 you get a list of the files it wants to save and why. Note down the files that LabVIEW wants to save due to "recompiles" or "sub-Vi changes". Now checkout in ClearCase these noted down files all with the same comment, something like "VI NOT edited - changed due to recompile or sub-vi change", then save all these VI's. Now using various scripts or LabVIEW you can easily see which files on a branch have actually been edited and which have just been save for recompile by looking at the ClearCase comments. The next step in this is automate this, as LabVIEW 8.2.1 can see which VI's in memory have change and why (well I assume this is the case) in order to give you the list in the save box. I should be possible to write a VI that generates that list and automatically checkout those that have recompiled with the correct comment. I am working on something like this at the moment. Slightly off topic extra, I already have a bunch of Vi's to get various ClearCase info, view config spec's, comments, etc and carry out ClearCase actions like, checkout, , do a labview diff on versions correctly (in progress).These do not use the NI supplied VI's but use either ClearCase command lines from DOS prompts or the ClearCase Automation Library (CAL) DLL. With these VI when I do an OpenG build I add to the build log the ClearCase view config spec, and a full bill off material list all the VI's in the build, list for each VI it's full ClearCase info like branch name and version. The other tick I do is to automatically pass all the VI's on a specific ClearCase branch into the VI analyser. I was thinking of these as possible candidates for the LAVA code repository but was not sure anyone would be interested.

QUOTE(Aitor Solar @ Nov 12 2007, 01:08 PM) Thanks that works fine

Hi Aitor Your tool looks quite interesting and I was going to have a play with it but the llb in the zip file is saved in LabVIEW 8.5 so I cannot open it. It is possible for you to post LabVIEW 8.2 or 8.2.1 version please cheers Dannyt

QUOTE(Norm Kirchner @ Oct 30 2007, 02:46 PM) Hi Norm, Thanks very much for that tip, I managed to get round to playing with this today your comments were enough to put me on the right track. I have written a little VI, that may be of interest to others using the OpenG builder, who like me are still trying to learn all this. I hope somebody find it useful as it is my first code post (and I would like to return something to the community). I would also be happy to get any feedback if this is not the way to do it, or how to do it better. This VI can be placed into any pre-build / post-build or callback VI that the OpenG builder uses and it will append messages to the NI.LV.Dialog DEAB_Log_store__ogb.vi string register. The benifit of adding your own logging in this way to the build log file means that you get only a single build log file and the OpenG application deals with all the time stamp and location issues according to the rules in your build configurastion file. I did wonder if I should put a shift register around this code to hold the reference so it does not have to be looked up each time used. My worry with this is can I assume that all the pre-build post-build and allback VI will have the same application contect themselves. The uploaded VI is save in LabVIEW 8.2.1. Download File:post-7256-1194562875.vi cheers Dannyt

QUOTE(Norm Kirchner @ Oct 29 2007, 03:18 PM) Hi Norm, I have spent a little while looking at this and though it does get me a great deal more propereties and info, at present I do not see how I can use this to move forward to solve my problem, as what I think I need is a reference to the Vi within the NI.LV.Dialog instance. This problem is showing me how little I really know about LabVIEW , could you give me a little more detail on which way I should move forward. I suspect the answer is there right in front of me but I cannot see how to get the reference I need in order to be able to open the correct instance cheers Danny

QUOTE(eaolson @ Oct 29 2007, 04:03 PM) I do not have any special license or anything but after a little trawel around I have just managed to find the properties mentioned, to get it I added SuperPrivateScriptingFeatureVisible=True and SuperSecretPrivateSpecialStuff=True to my 8.2.1 labview.ini file as talked about http://forums.lavag.org/VI-Scripting-Readme-First-t1207.html' target="_blank">here so thanks Norm now to play with it and see what dammage I can do :ninja: cheers Danny

Hi All, Firstly, this is a cross post, I have also put this question on the OpenG forums How to get the best out of plugin's however I think it might be of general use / interest so I am posting to LAVA as well. I am making increase usage of the OpenG application builder and in particular I am running a number of plug-in's, different plugin's for pre / post usage and in call-back mode. I do not know if this makes any difference but one of the reasons we are using the OpenG app builder is so that we can build executables of our code without using the LabVIEW project explorer, we are moving from LabVIEW 7.0. to 8.2.1 and are code base needs some moving around before things will fit nicely into the project explorer scheme. One of the things all my plug-in's are doing is generating information that I want to log. In truth I really wish to add them to the existing log file that the OpenG application builder itself creates but up to now I have totally failed to be able to do that and have had to write my own logging into each of the plug-in's. While this solution works it is far from ideal. The OpenG builder has a good log system whereby a running log is kept in a shift register in "DEAB Log Store_ogb.vi", all nicely date time stamped, and at the very end this is written to the correct Dir overwriting any existing log file using "DEAB Write Log File_ogb.vi". So far so good. My problem is that the two VI's above are loaded in the application instance "NI.LV.Dialog" and the plug-in's which exists on a network location are therefore in a different instance and i cannot figure out how to get them to call the correct instance of the "DEAB Log Store_ogb.vi" and "DEAB Write Log File_ogb.vi". In the thread App.AllVI and Application Instances Kennon suggests QUOTE I have tried using this in the plug-in's but I cannot seem to find any reference in the output cluster to any of the "NI.LV.Dialog" VI's that I know are running as part of the builder. Could anyone please please give me some pointers on how to do this thanks in advance cheers Danny

QUOTE(Darren @ Oct 16 2007, 04:31 PM) Darren, Thanks for your reply I now have it loading OK, my problem was the underscores on the LLB name, I removed then and it is fine. Now I need to play with it Just a note in case anyone else is interested; if you have several versions of LabVIEW you can put the "Find VI Calls.llb" under the location C:\Program Files\National Instruments\LabVIEW 8.2\project\VI Analyzer\_tests In fact I have created a structure under _tests "User Defined Tests\Find VI Calls" in the Find VI Calls dir I have placed the "Find VI Calls.llb2" file and a "Find VI Calls.txt" file which contains your instructions above on how to use it. cheers for the help and the tool Danny

QUOTE(Darren @ May 10 2007, 04:37 PM) Hi Darren, Having just moved upto LabVIEW 8.2.1 and also got access to the VI Analyser I was interested in playing this this extra 'Test' but I am afraid I cannot get it working as you described. I have tried placing the downloaded file in both the My Documents\LabVIEW Data\VI Analyzer Tests location and also in C:\Program Files\National Instruments\LabVIEW 8.2\project\VI Analyzer\_tests\User Defined\Find VI Calls on each occassion I exited LabVIEW completely and restarted, but I do not see the extra test category. Could you please offer me some pointers in fixing this cheers Danny

QUOTE(crelf @ Oct 15 2007, 01:03 PM) more thinking of England stuffing (well scraping past) the French, roll on the final when we do the same to the 'boks'

QUOTE(kevinP @ Oct 15 2007, 11:11 AM) but he has not actually thrown anything yet

QUOTE(Michael_Aivaliotis @ Oct 14 2007, 12:31 AM) I suspect somebody like myself who mainly lurks but very occaisoianlly post, must be a lurcher what a great game of Rugby on Saturaday night :-) ....... now only South Africa stand in the way of a great world cup double Danny

QUOTE(Michael_Aivaliotis @ Oct 1 2007, 04:31 PM) Actually it might not be to bad, the create trigger part is easy as is associating it triggers to files, it is the script that is hard'ish. Looking at the LabVIEW project files *.lvproj they are already in an xml format and contain in a readable for the vi names, with thier paths for example <Item Name="circle area.vi" Type="VI" URL="/C/Program Files/National Instruments/LabVIEW 8.2/examples/project/viserver/circle area.vi"/> I am new to 8.2.1 and using projects, can you add projects to projects I assume you can. So with one single top level, you could easily search through looking for all reference to the current VI you are editing. If you cannot have projects within projects, a single text file point to all you projects and the location of thier project file (lvproj) would do. In fact you could forget you SCC system and just have a labVIEW application that told you for any VI all the projects it is used in within you orginasiation. I almost feel sure somebody has aleardy done this somewhere in the LAVA archives. You could even batch run something like this every night, as most older projects will not be changing as much as newer projects. Danny

QUOTE(Ben @ Oct 1 2007, 02:54 PM) A significantly easier and more LabVIEW centric suggestion than mine Ben, I like it. Danny

QUOTE(torekp @ Oct 1 2007, 12:49 PM) There is no way the SCC tools can know about the inter-relationship between your VI's and projects. but if you are happy to to document this, there are several way this type of thing could be done in ClearCase (I would suspect CVS and sub-version would support similar types of actions) but it does take a bit of work to set it up. In ClearCase you can set-up triggers to fire on nearly every action ie checkin, checkout and many more. Not only that, but the triggers can fire in two modes for most actions, either as a pre-trigger or as a post trigger, typically pre-triggers can be setup with a pass / fail type result and be used to stop and action from happening. The triggers are usually written as Perl scripts and thier can be written to do almost what you want. So for example you could create a post-checkin trigger on all files of type *.vi files within your ClearCase system (attaching the trigger to all the files type is very easy and quick), this script file could then parse your VI relationship xml or text file and pop up a message telling you what else is affected. Obvioulsy you would need to remember to keep you inter-releationship documentation up to date. Things that I have seen be done with triggers post-checkin trigger - replace all tabs in C or C++ files with a fix number of spaces pre-checkin trigger - run lint against all C files before checkin and stop checvkin happening if lint found errors both - automatically build software and run unit tests. post-checkin triggers - email members of a project team a file has changed and much more There are also Clearcase objects called Hyperlinks that can be used to show inter-relationships between files (see below) and these can be acted upto by triggers as well. Some useful or othewise definitions are at the bottom of the page. hope this is of some use Danny ClearCase Triggers A ClearCase Trigger is a an executable program that you create that you can make Clearcase invoke before and/or after a specified ClearCase event or operation. You tell ClearCase which commands/events to invoke it for, you tell it how to invoke it, and ClearCase will execute it at the specified time with the specified parameters, as well as set the environment with lots of ClearCase related environment variables to allow your trigger "script" to consult numerous items of contextual information at the time it is invoked. ClearCase Hyperlink Types Hyperlinks are the stangest of the Object types. Using Hyperlinks, you can link one version of an element to another. Not only that, but you can use hyperlinks to point from almost any object type to another. ClearCase uses Hyperlinks to track Globally defined types. First of all, to even use Global definitions of Object Types, you create a hyperlink AdminVOB from one VOB to the Administration VOB where the Global definitions live. Then when you actually invoke a Global definition, ClearCase links the Globally defined Object Type to the locally defined object type with the GlobalDefinition Hyperlink. A pretty neat trick. The classic use of Hyperlinks is to point from one version of an element to the supporting documentation. If someone checks out a library definition, then the trigger could also force a checkout of the corresponding documentation, and refuse to check in the library definition until the corresponding documentation has been updated.

Hey, Great news, LavbvIEW 8.2.1 at last :thumbup: We are moving our project over from LabVIEW 7.0 to LabVIEW 8.2.1. At last we will be able to play with Xnodes, OO and many of the other things I keep reading about on these forums. The bad news is that we have moved over from individual licenses to a volume concurrent license schemewith the licenses server located in a remote head office. So whereas with version 7.0 we could have a copy at home to play with, we can no longer do this with our concurrent license :thumbdown: , has anyone else come across this problem. From the NI License ------------------- 6. Home Usage Exception. Notwithstanding anything in this Agreement to the contrary, if you are a business or other entity, the designated Named User for (or in the case of single seat license, the primary user of the single computer on which the SOFTWARE is installed and used under) the applicable license may also install and use the SOFTWARE on one (1) computer located in such user's home; provided the use of the SOFTWARE: (i) is pursuant to one of the licenses enumerated in Section 2 above (other than a concurrent use license) and (ii) on such home computer is limited to work performed in the scope of such person's employment with you and further provided such person promptly deletes the SOFTWARE from the home computer upon the termination of his or her employment with you or termination of this Agreement (whichever is earlier). Notwithstanding the foregoing, If you have a concurrent use license, this Home Usage Exception does not apply to you. cheers Danny

Hi All, Just a quick question, I have had a look around here and the NI forums, and have seen nobody post any problems installing LabVIEW 8.5 with older version of LabVIEW so I assume all is OK and there are no issues, unlike the upgrade from LabVIEW 8.2 to LabVIEW 8.2.1. I am currently running LabVIEW 7.0, all our project work is being do here, I have a concureent user license version of LabVIEW 8.2.1 installed but have not yet transfered any projects over to this version, and I would like to evaluate LabVIEW 8.5 which I think is also covered by our concurrent licence. cheers Danny

QUOTE(jzoller @ Aug 16 2007, 05:33 AM) I would not go done the money route, I think that the cost of the LabVIEW full development license is very expensive, and not a plus. <small rant on the side ) This is doubly true for us Europeans, where, companies like NI and MS seem to never have heard of a thing called the exchange rate. <rant over> We have two groups writing test software here, one with LabVIEW and one with Python & Jython (a java variant of Python), other teams on this site are using Java, Perl, Linux C compilers.All the above are free except the LabVIEW. We often had manager asking why we should be paying so much for LabVIEW when x,y and z could do thier test software free. Please note, I know and understand NI has development costs to cover and I am NOT implying that LabVIEW should be free (would be nice thought ) but I do think the costs are on the high side, especially if you are an individual developer or working for a small organisation. One particular problem with this is that since we recently have been taken over by a large multinational, I now have the opportunity to move from LabVIEW 7.0 to LabVIEW 8.2.1, yippee !!! HOWEVER with the LabVIEW 7.0 I am able to run legally at home (see below Section 6 of the LabVIEW license), we bought several copies it a while ago; but if I do move forward to 8.2.1 I will no longer be able to do this as we will be running concurrent use license from a licence server and there is no way I can afford my own licence as an individual. So I have simple option stay with LabVIEW 7.0 or give up playing and doing stuff at home. just my two pence worth. Danny 6. Home Usage Exception. Notwithstanding anything in this Agreement to the contrary, if you are a business or other entity, the designated Named User for (or in the case of single seat license, the primary user of the single computer on which the SOFTWARE is installed and used under) the applicable license may also install and use the SOFTWARE on one (1) computer located in such user's home; provided the use of the SOFTWARE: (i) is pursuant to one of the licenses enumerated in Section 2 above (other than a concurrent use license) and (ii) on such home computer is limited to work performed in the scope of such person's employment with you and further provided such person promptly deletes the SOFTWARE from the home computer upon the termination of his or her employment with you or termination of this Agreement (whichever is earlier). Notwithstanding the foregoing, If you have a concurrent use license, this Home Usage Exception does not apply to