dannyt

Hi Michael, Thanks for all the work you do on running LAVA, I like the new feel of the site. But I am afraid I to miss the portal view, specifically on a Monday or if I am out of work a couple of days. I like to see what has been posted over the last ... well however long I have been away really, I then first thing do a quick read through well skim through, some of the things that look interesting and make a mental note of things I want to read in more detail later in the day. In the portal view there are still there in that same view to come back to later. In the unread contents view those items have now gone as I have looked at them. Maybe I just need to change my process of using the LAVA site. cheers Danny

I really like this, though no funny LAVA type puns or anything, it is sort of how I feel about LAVA

According to the error message the file you are writing to is already Open. So I would check to see if some other application is currently using the file. Maybe you have already opened the file in LabVIEW and are trying to open it again. Upload a copy of your VI so we can see it, would help you get a better answer Danny

Hi Ian Often I do a bit of pseudocode on a scrap piece of paper before I code something especially if it is a little nested or I want to talk it over with somebody else first. I am not sure I see your problem, after all the whole point of pseudocode is that it is NOT specific to the language you are going to code in. for example initialise power meter initialise signal generator get frequency list for each frequency set signal generator to frequency get power reading from power meter check stop button state if STOP STOP plot graph this can help you plan what you are going to do before you code it up and applies equally well for LabVIEW or C or Python Danny

Is Australia not like a big cruise ship ? Anyway many congratulations to you jgcode Coincidently I am looking at your error logger project today, trying to understand it all so I can re-write our debug logging system in a similar vain. cheers for all the community support you give Danny

Yes I noticed the comment about large binaries. I think it depends on the project size you are working on, small tool-set type projects it is not a problem, but large application maybe be a different matter Danny

HI, I was reading this article today about the growth of GIT and I found the figure below quite interesting, plus there were a few comparison comments that were informative. It placed the user base of GIT as much greater than Mercurial and yet I have noticed in the LabVIEW world a general settling on Mercurial & SubVersion cheers Danny

This thread might be of interest to you it covers TCP/IP error 66 & 56 disconnection errors and some suggestion on how to overcome or deal with them cheers Dannyt

HI, A big sorry to the Lava Admin's I am having a bad day today. I created a new uncertified CR today and got the thread title wrong, WRONG TITLE could I please ask a admin to change the Tile - from [Discuss] Danny Thomson to [Discuss] ClearCase API I initially clicked on the "Report to Moderator" link to make this request, and just as I posted the report I notice the small print that that link should only be used to report " ONLY for reporting objectionable material " I am not sure if I managed to press Cancel in time or not, so sorry if I submit the report as well. like I said I am having a bad day. cheers Dannyt

Name: ClearCase API Submitter: dannyt Submitted: 13 Jun 2011 File Updated: 15 Jun 2011 Category: *Uncertified* LabVIEW Version: 2010 License Type: BSD (Most common) ClearCase API v1.0.0 Copyright © 2011, Danny Thomson All rights reserved. Author: Danny Thomson LAVA Name: Dannyt Contact Info: Contact via PM on lavag.org LabVIEW Versions: LabVIEW 2010 Dependencies: oglib_string v2.6-1 oglib_file v3.0.1-1 Description: The API provides an interface to communicate with the CleaCase source control tool. This API is not meant as a integrated ClearCase provider in LabVIEW. Installation and instructions: Installation is performed by VIPM, after which a palette is created in the user.lib palette. sourcecode can be found here BitBucket Examples: No examples are included Known Issues: This package only supports Windows ClearCase clients and only supports Base ClearCase no UCM is supported at present. Acknowledgements: Thanks to Ton Plomp for inspiration with his Mecurail API Version History: v1.0.0: Initial release of the code. License: BSD (Most common) Support: If you have any problems with this code or want to suggest features: please go to lavag.org and Navigate to LAVA > Resources > Code Repository (UnCertified) and search for the "" support page. Distribution: This code was downloaded from the LAVA Code Repository found at lavag.org Some Details of functions provided ================================= Supports Windows only, though most of the Cleartool commands and options are the same on Unix Assumes default instilation of ClearCase working with Dynamic Views If ClearCase is NOT installed in default location then you can manually alter install location in ClearToolPath.vi Two types of methods 1) VI using ClearCase Cleartool command line all named *_ct.vi 2) VI using the ClearCase Automation Library (CAL) all named *_cal.vi No interface currently provided for UCM ClearCase operations Add.vi ======== This VI will add an element or directory to Clearcase ie create a new ClearCase Object. NOTES 1 The Parent Object (directory) must be a ClearCase Object 2 The Parent object will automatcially be checkedout if it is not already checkedout 3 By default both the parent dir and the added object will be left checkedout 4 If adding a file, the file must already exist 5 If adding a directory , the directory must NOT exist, remember to set Directoy? to true A creation comment can be added Comment. Copyright 2011 - Danny Thomson No waranty included BranchInfo.vi ============= This Vi checks if the Branch Name passed in exists in the VOB specified by a Valid VOB Object and if it does it will return the following information. branch exist? true / false locked state? True (locked) False (unlocked) branch description Branch creation comment obsloete? True (locked & obsolete) false (just locked) Note only the supplied VOB is checked branch could exist in other VOBs uses Cleartool command describe -type brtype with formating options Copyright 2011 - Danny Thomson No waranty included CheckIn.vi ==================== This VI will attempt to checkoutin a ClearCase Object (file or folder). uses ClearTool --- uncheck/out | unco [ –kee/p | –rm ] { –cact [ pname ... ] | pname ... } –kee/p Preserves the contents of the checked-out version under a file-name of the form element-name.keep (or, to prevent name collisions, element-name.keep.1, element-name.keep.2, and so on). –rm Does not preserve the contents of the checked-out version. Thus, any edits that had been made to the checked-out version are lost. NOTE. Error -2904 if files in not checked out Copyright 2011 - Danny Thomson No waranty included CheckOut.vi ================= This VI will attempt to checkout a ClearCase object (FIle or Folder). INPUTS ---------- FileName & Path itme to be checked out can be file or floder Checkout comment A checkout comment checkout Type see below CC Branch A optional branch to checkout on e.g \main \main\dev\ats\111 see below uses ClearTool checkout | co [ –res/erved ] [–unr/eserved [ –nma/ ster ] ] [ –out dest-pname | –nda/ ta ] [ –pti/me ] [ –bra/nch branch-pname | –ver/sion ] [ –nwa/rn ] [ –c/omment comment | –cfi/le comment-file-pname | –cq/uery | –cqe/ach | –nc/omment ][ –q/uery | –nq/uery |–use/hijack ] pname ... –res/erved Reserves the branch: no user in another view can perform a reserved checkout of the same branch (but any number of unreserved checkouts can be performed); no new versions can be created on the branch until your checkout is changed to unreserved with unreserve or resolved with checkin or uncheckout. If you specify both –reserved and –unreserved, this command performs a reserved checkout if possible; otherwise, an unreserved checkout. –unr/eserved [ –nma/ster ] Leaves the branch unreserved; other users, in other views, can check out the same version (but at most one of the checkouts can be reserved). CC BRANCH Default - blank. View Config specifications rules will be applied. This allows a specific branch to be used to be used to checkout the file. NOTE branch must in this case MUST be the full branch path ie \main\dev-ats-456 not the branch type dev-ats-456. If CC Branch is used the CC warning messages are suppresed as they WILL occurs, but do not indicated we have have a problem, the branch used MUST EXISTS for the objects being checked out Copyright 2011 - Danny Thomson No waranty included CreateBranchType.vi =================== This VI will create a new ClearCase Branch Type Uses CAL Copyright 2011 - Danny Thomson No waranty included CreateLabelType.vi =================== This VI will create a new ClearCase Label Type NOTE Label Type Names cannot have spaces in them, else they will be invalid Uses CAL Copyright 2011 - Danny Thomson No waranty included FileInfo.vi ================= This Vi finds information on the ClearCase element & version matching the input File or Folder Outputs ---------- View Private File True if item is not a ClearCase Object other outputs are only valid IF this is FALSE Labels List of Labels applied to this element. Label (0) is latest label Flags IsCheckedOut -- True / False IsLatest -- True / False General Info Branch -- associated branch for file Extended Pathname -- full ClearCase exteneded pathname ie test.vi@@/main/dev-ats-345 identificer -- see above the bit after ther @@ comment -- if checked in checkin comment else shows checkout comment using CAL Copyright 2011 - Danny Thomson No waranty included FilesOnBranch.vi ===================== This Vi lists files on the clearcase branch Branch Name provided. This VI needs a path to a Valid VOB Object to work. Default is for Output paths to be Absolute Pathnames using the Windows Mapped Drive. This can be change using the Return Path Type input Output Cluster - Total Files on branch - LabVIEW files on branch ie llb, vi, vit, ctl - Directories on branch - Other files On branch uses ClearTool find pname -all -nxname -visible -version "brtype(%s)" -print NOTE. This VI does NOT check the branch exists, such a check should be run first CtViewExists.vi Copyright 2011 - Danny Thomson No waranty included GetConfigSpec.vi ===================== Gets the ClearCase View Configuration Spec for the View specified ViewTag Uses ClearTool -- catcs -tag Copyright 2011 - Danny Thomson No waranty included GetViewTagAndCSpec ===================== This Vi will get the ClearCase ViewTag & releated View Configuration Spec valid for the provide file or folder Uses ClearCase Automation Libray Copyright 2011 - Danny Thomson No waranty included LabelFiles.vi ============== This VI will attach a already created Label Type to the version of the current directory selected by your view, and to the currently selected version of each element in and below the current directory. Uses CAL Copyright 2011 - Danny Thomson No waranty included ListBranchTypes.vi =================== This VI will provide a list of all the Branch Types in a VOB This VI can take a long time if there are many branches in the VOB !!!!! using CAL Copyright 2011 - Danny Thomson No waranty included ListCheckOuts.vi ======================= This Vi finds Checkedout files in the VOB selected by the File Or folder in VOB input Output ---------- 2-D arrray listing checkedout files Columns are PathName - View checkedout in --- branch checkedout on -- user checkedout to using CAL Copyright 2011 - Danny Thomson No waranty included ListLabelTypes.vi ================= This VI will provide a list of all the Label Types in a VOB This VI can take a long time if there are many Labelss in the VOB !!!!! using CAL Copyright 2011 - Danny Thomson No waranty included ListPrivateFiles.vi ======================== This Vi lists the view private files in the VOB and View specified Inputs ------- Valid VOB Object Specify VOB ViewTag Specify ViewTag Include Checkouts ?(F) If True Checkedout files will be included in results else they will be ignored Default is for Output paths to be Absolute Pathnames using the Windows Mapped Drive. This can be change using the Return Path Type input Output Cluster - Total Files on branch - LabVIEW files on branch ie llb, vi, vit, ctl - Directories on branch - Other files On branch uses ClearTool cleartool lsp·rivate [ –tag view-tag ] [ –inv·ob vob-selector ] [ –l·ong | –s·hort ] [ –siz·e ] [ –age ] [ –co ] [ –do ] [ –oth·er ] NOTE. This VI does NOT check the branch exists, such a check should be run first CtViewExists.vi Copyright 2011 - Danny Thomson No waranty included SetConfigSpec.vi ==================== Set the ClearCase View Configuration Spec for the View specified ViewTag Input ------- Filename Text File that supplieds the view config spec Uses ClearTool -- setcs -force filename.txt No waranty included UndoCheckOut.vi -------------------- This VI will attempt to undo a checkout on ClearCase File. uses ClearTool --- uncheck/out | unco [ –kee/p | –rm ] { –cact [ pname ... ] | pname ... } –kee/p Preserves the contents of the checked-out version under a file-name of the form element-name.keep (or, to prevent name collisions, element-name.keep.1, element-name.keep.2, and so on). –rm Does not preserve the contents of the checked-out version. Thus, any edits that had been made to the checked-out version are lost. NOTE. Error -2904 if files in not checked out No waranty included ViewExists.vi ----------------- This Vi checks that the VIEW specified by the supplied View Tag exists Using ClearTool --- lsview No waranty included Click here to download this file

I disagree totally, this IS possible with LabVIEW. It has been possible (though not necessarily easy) with LabVIEW for several version now, but has become increasingly easy with LabVIEW 2010 and useing the seperate source & compile code feature. Using separate source and compile code feature in LabVIEW 2010 you can now ensure that only VI's that you have actually change i.e. edited by a developer are saved into the source control tool. So this mean is is now easy to see which file you need to compare, rather than as used to be the case all those recompiled file and the file you actually changed. Using the LVCompare tool will allow you to do a side by side compare of the differences and you can sit down with somebody and talk them through the changes just as you could with a text file (it help to have two monitors one version on each) Dannyt

Hi, Finally I have gotten round to doing some work on a package of code that I would like to end up in the Lava CR. It is an API to allow use of the ClearCase source control in LabVIEW. I am not sure how many people will find it of interest but just doing this has been a learning experience for me. I have used Ton Plomp's Mecurial API package as inspiration, thanks Ton. A lot of the code I have had and been using for a couple of years, but making into an API that anybody can use has changed how I have to look at the code. I have now done quite a bit of functionality, but I have a general question and would like some advice. Thought the example below is a specific the questions it ask can generally be applied to a number of my VI's I have a VI GetExtendedPathName.vi that gets for a file or folder the ClearCase extended pathname for example my.vi@@\main\dev-ats-23\4, in getting the information I also find out if the file or folder in question is checkedout and also some other possible information about that VI. So the first question is should I provide both the extended pathname and the file 's checkedin / checkout state as output in the same VI or should I separate this out into two VI GetExtendedPathName.vi & IsObjectCheckedOut.vi even thought the code within each is basically the same I am just ignoring one of the possible output. I know I could write a private GetObjectInfo.vi which is called by two public VI's GetExtendedPathName.vi & IsObjectCheckedOut.vi but at the top level user view should there be two VI or one. I currently only have one VI but I feel this is wrong. Second question is on how to address error's in particular predictable error's. So in the example above in order to get this information the file or folder I am looking at needed to be a ClearCase object (i.e. added to the repository at some time), so one possible error is if the user trys to get this information on a file that is still not added into the source control system. In this case should I return the error " −2911 The specified file is not under source control" or as I know what that error means should I clear the error and set a FP flag "File is View Private" true. The second question also applies to things like checkin or checkout file if you try to checkout an already checkedout file should you error or clear the error and flag that file is already checkedout. I hope these questions make some sense and I would appreciate other peoples views on this. I suppose a final question is would anyone actually be interest or find such a package useful. cheers Dannyt

Hi, I have added an idea here to hopefully improve the usability of the LVCompare function idea link I would like to optional command line switch to be available from within the resulting "Differences" window cheers Dannyt

Hi, A small update, if you want to be able to use the possible command line switches, with the LVCompare.exe and ClearCase you will need to use some form of wrapper to allow you to select the switch options and add them to the ClearCase passed in args and pass then onto LVCopmare. Here is a simple version, written in LabVIEW 2010. When you do a ClearCase difference it will launch the pop up below allow you to select the compare options then launch the compare The Zip file contains the files go_compare.vi Go-Compare.exe Install NOTES.txt To install 1) Copy the executable to the dir C:\Program Files\National Instruments\Shared\LabVIEW Compare\ 2) Edit the Clearcase map file C:\Program Files\Rational\ClearCase\lib\mgrs\map make a copy first :-) the lines for the z_whole_copy compare & xcompare should be changed from z_whole_copy compare ..\..\bin\cleardiff.exe z_whole_copy xcompare ..\..\bin\cleardiffmrg.exe to z_whole_copy compare ..\..\..\..\National Instruments\Shared\LabVIEW Compare\Go-Compare.exe z_whole_copy xcompare ..\..\..\..\National Instruments\Shared\LabVIEW Compare\Go-Compare.exe if you only want the default LVCompare without the wrapper to change compare options use z_whole_copy compare ..\..\..\..\National Instruments\Shared\LabVIEW Compare\LVcompare.exe z_whole_copy xcompare ..\..\..\..\National Instruments\Shared\LabVIEW Compare\LVcompare.exe Hope some people find this useful go_compare.zip

That looks really sweet, I am now trying to think of a good excuse to use a tray icon in our project +1 from me cheers Dannyt

Absolutely amazing

It is quite simple to save the data in each loop to only one file, by doing something like this - Firstly as you are talking about spreadsheets I would format any data to be saved in a CSV format so this can easily be open in Excel or as a text file later. Open a file before you loop starts, this could be either a new files or an existing one. Pass the reference to this file into you loop and each time round your loop append you data into the file, when your loop finishes close the file. Look in the LabVIEW Example Finder, there is a example VI "Write to Text File.vi" in the Fundamentals --> File Input & Output category that shows how to write to the same file in a loop Danny

OK, I can see that it is for now an irrelevance for OpenG. My personal experience of LabVIEW 2010 & this separation feature is only to the good I must say. In answer to this part, hopefully developers of packages in general ARE keeping their source code in some sort of SCC, and it is from this they build thier packages. So if they are working in LabVIEW 2010 they will get the benefit for themselves in maintaining that code. It provides no benefit as you say to the end user of the package. Danny

Just a general though / question and I think this applies to both OpenG & LAVA CR's so I was not quite sure where to put this. I am working on a LAVA CR package and I intend to separate source & compile code and it had me thinking. What is the general take that people have on the separation of source & compile code issue for new tools or LAVA CR's that a LabVIEW 2010 or newer. I did see a comment, but cannot find it now, for NI that this will sometime in the future become the default setting rather than an option. As this setting can be do programming, I was also think that maybe this could be a feature request for the VIPM, similar to the mass compile on install setting. Dannyt

wow meant to give +1 to Shaun but gave it to jgcode hey so both have +1

Hi I was looking at Ton Plomp's Mercurial API over the last few days (I hope to announce why in a few weeks) and I noticed a piece of code similar to this It took me a couple of seconds to see it was a simple pattern match and as I always use the Match Pattern privative or for something more complicated a match regular expression privative I was intrigued as to why he did it this way and looking further I found out something I suspect many of you know already. I ran some tests using Ton's method, Match Pattern & Match Regular Expression all just match something at the start of a string. I ran each in a loop 500000 times EDIT Picture updated thank you Shaun I think I knew Match Regular Expression was a "heaver" VI than Match Pattern, I think it says so in the documentation somewhere, but it was interesting to see it was so much slower than the other two methods. I am sure that at times in my code I have used Match Regular Expression where it is not really called for, often I was trying to match something more complicated then when the matching was optimised I never changed back to the simpler match pattern. It is interesting to see that in terms of performance both the other method are the same in terms of time, but Ton's method only uses ~75K for my test VI but around ~210K for the match pattern. Anyway, thanks Ton, I must look at more of the LAVA CR code it is so interesting seeing how others do things. cheers Dannyt

thank you

[cross-posted from OpenG] HI, I have copied this issue I raise on the OpenG forums a while ago now as it is a tool I use a lot and I have a proposed fix (maybe not the best one). I would really like to see if this could be progressed. cheers Dannyt -------------------------------- Hi, Under LabVIEW 7.0 I found the package ogrsc_compare_vi_to_disk-1.1-1 to be very useful, we used it a great deal to carry out peer reviews of our code. Since recently upgrading to LabVIEW 8.2.1, I found this package no longer worked. I have spent a bit of time playing with it and have now managed to fix it. I had to change the main VI compare_vi_to_disk__compare_vi_to_disk.vi to be aware of application contexts. I do not know if my method is the best way to fix this problem, or if this work is already in progress, but it does work and allows me to use this useful package again. In case anybody else find this useful I have attached a labVIEW 8.2.1 copy of my fix below, it needs to replace the existing version in the the compare_vi_to_disk.llb in C:\Program Files\National Instruments\LabVIEW 8.2\project. I have only check it works for package version 1.1-1 compare_vi_to_disk__compare_vi_to_disk.vi compare_vi_to_disk__compare_vi_to_disk_auto_run_off.vi The second version is with the auto run at open disable, so less hassle to see the changes. How does one go about requesting, the package to be updated or offering help to get packages update ?