klessm1

I hope to have a alpha version ready by the end of today and posted. For right now I am just trying to get something that I can use to merge 10 files from two heads so I can get going on a project (also a good test case for this tool)...may not be the final implementation but maybe others may be interested in helping out. It is not a very large project so I don't know if I want to post it in the public domain of my Kiln site or not... I'll let you know.

I've been using Mercurial with TortoiseHG and Kiln (Kiln is free for two developers) since this last summer and I love it! It sometimes surprises me how easy some activities are compared to how I used to have to do them with VSS / Perforce / Surround SCM / DesignSync (don't ask about that one... ). It is really easy to manage when I am the only developer, but also isn't too bad in a multi-developer environment either. The ability to go back to a tagged release, make a small change, perform a build and release (and tag), and then merge that change to the mainline is so easy in mercurial and next to impossible in the other environments I have used. It has literally saved me days of work because of how easy it is to manage releases, bug fixes, major changes with the branching and merging features. I have a major project where another developer is making sweeping changes that are not all backward compatible yet, but we are working from the same repository and I can still perform stable maintence releases. Meanwhile I have another branch where I am gutting the entire structure of the program. The merging is a little lacking, but I am working on a simple tool to allow multi-file merges with TortoiseHG (LVMerge ends execution before the merge is actually complete and you miss the next file merge). A diff tool also needs a little work to support to diff changesets when multiple related files are different. Unfortunately LabVIEW's compile at edit time and sub vi dependency means that if multiple related files are different then the single file diff won't be entirely accurate. The only way I see is to use the Mercurial commands directly to "update" to each of the changesets being compared in their entirety and then compare them in different directly structures. Merging doesn't seem to have this issue. I was thinking a hierarchy ordering of the vi's to merge might be necessary in order to get it correct, but LVMerge (at least in 2010) is very good. Now I just need to trick out the interface to "wait" until the merging is finished, cancelled, or errors out. Right now I just have a "next" button. Is anyone else working on an implementation of the "LVMerge" for mercurial that supports multi-file merging? As far as an API for the project I don't really see a need except for maybe a hotkey shortcut to commit. One of the main reasons I think it is easier is that you don't have to "check in" and "check out" every file individually. I just make my updates for a certain feature or bug, then commit all files from explorer. When updating to different changesets you do have to revert all your files manually (I usually have everything closed when performing updates). On a final note...no annoying "status" files in my working directory!

I know this can be done using the project file menu, but I would like to programatically save a project for a previous version and specify the version to save it to instead of it just defaulting to 2009 (you can for vi's, just not a project). I have a post build action at the end of a source code build script that puts everything into a project which I would then like to save to LabVIEW 8.5 for distrubution. Is there anyway to do this beside using keyboard events to execute the save for previous file menu item in the project? Note: This is double posted on NI forums. http://forums.ni.com/t5/LabVIEW/Save-LabVIEW-Project-and-contents-from-2010-to-8-5/td-p/1259386 Thanks, Michael

I tried setting up a TCPIP instrument using max under the CRIO and it said it wasn't supported. The crio I am using doesn't have two ethernet ports so I am assuming to keep determinism they can't add VISA support to that ethernet? Maybe a newer one that has two would work?

I don't have the device in front of me at this moment to see the software installed, but I would have to say yes. If I understand correctly, it is required to download the FPGA code which we have been able to do. In this case I have the cRIO connected to a hub with the host PC and a programmable power supply (ethernet interface) conneted to the hub as well. Everything is on the same subnet. I can execute VISA commands to the programmable power supply from the host PC running windows, but when I drag it down to the controller in the project and run it I get a VISA open error. I was able to use the fundemental TCPIP drivers to communication from the cRIO controller to the programmable power supply. For the VISA definition I was using "TCPIP0::192.168.1.3::3000::SOCKET". Maybe it has to do with the "TCPIP0" definition? I don't know if this is correct for real time on a cRIO. I found this post on NI's website saying that it can't be done, but it is before 2009 was released. Is the information in that post still correct? Does real time ship with Enet passport? http://forums.ni.com...uireLogin=False If not is there any way around it to get Enet passport on the cRIO. By the way I have not setup the instrument with an alias on the cRIO. Is that required? I would think the TCPIP0::192.168.1.3::3000::SOCKET string in the VISA control would work without having to set anything up.

I have posted an issue I have over at the NI site with no responses. Wondering if anyone know the answer. Basically, can I use VISA to communicate with an instrument over ethernet on a CRIO 9004 using 2009. Here is the link. http://forums.ni.com/ni/board/message?board.id=280&message.id=7670&jump=true Thanks!

Issue reported to NI RD (#201244 CAR ID). See cross post link in previous post.

I just converted a project over from 8.5 to 2009 and I found that some of the funtionality that I was working in 8.5 no longer works in 2009 (probably for good reason...). Anyway, I found that if I tried to use the stop timed loop vi to stop any timed loops in reentrant vi's that I get a -804 error. The stop timed loop sub vi was in the same reentrant vi in the application, but I found it also did not work if it was outside the reentrant vi. It does get a little hairy when thinking which loop you are trying to stop because of the reentrancy, but if the names passed into the instances are different for the loops then it shouldn't be a problem right? See attached for a very simple example of this occuring. Note: Just running in windows...not in RT Stop Time Loop.LLB

Most of the analog output examples I have seen create a channel not a task. Usually the task is created after calling the timing or other DAQmx function. I am looking at the example "Cont Gen Voltage Wfm-Int Clk-Non Regeneration.vi" and it has the same issue as what I am seeing. If you have too fast of a sample clock rate (over the 20k) then it gives the same error depending on the speed of the PC. I have been looking into using DMA instead of interrupts and it seems to work a little better. I have attached the error screen...I forgot it in my original post. Thanks

I am running into some problems outputing an analog output sine wave with my DAQ using the onboard sampleclock. At one point I was able to get the vi running quite well and repeatable. When revisited however, I started seeing error that the driver could not provide the device with the points fast enough. I was running the sampling rate at 250k for a 1k tone, but I seem to only be able to get about 20k sampling rate. This creates a fairly choppy signal expecially when the frequency is bumped up to 8k. I am only producing 1 second of data. See attached bmp. The I/O references passed in are channels not tasks. Could this be the problem? I'm a little frustrated as this should be a very simple vi to create and I am having all kinds of trouble with it.

Thanks. I used the edge detection followed by the histogram and the mean and stdev follows the focus very well. The better the focus the more edges and the higher the mean and stdev. Especially with the star and zone charts that I am using.

I am using 8.6.1 with the vision 8.6.4 Vision toolkit. I am grabbing images from the 1422 frame grabber from a CCD sensor and need to generate a test to detect how focused the lens for the sensor is. The user will manually focus the lens using a test pattern and then I need to display a level of how in focus the image is (beyond the human eye detection). I am very new to testing video and images and have not used the Vision toolkit before. I would like to know if anyone knows how to go about using the vision toolkit to detect levels of focus. Right now we are using standard star charts and zone charts to detect focus, but I don't know if these will work well for automation with the vision toolkit. Do I need to make a custom chart with objects that are close together and use the object detection algorithm? Like I said, I am very green in the vision arena. Any help would be greatly appreciated. Thanks.

I believe they use the MME drivers. If you are looking for repeatable latency then these are not the drivers you want to use as they are based off the OS timing. Probably the best choice is to use an ASIO driver. ASIO4ALL is an open source driver you can use. There are others out there which I do not wish to look up as I am currently busy drinking a beer. :beer: QUOTE (fonzo @ Jan 30 2009, 06:21 AM)

QUOTE (Ton @ Dec 17 2008, 01:07 PM) Thanks, I never really use them much for the same reasons. It is nice to have newly created files show up in your project automatically though. I will try the hidden file idea. Thanks

Is there a way to exclude certain files from showing up in an auto-populate folder like say SCC files. Many SCC applications put an extra file in every directory to link to repository. These files show up in your auto-populate folders even though you don't need or want them there. Thanks.

I see most everyone here using TortiseSVN. When I switched jobs about a year ago I was tasked in picking an SCC product for embedded firmware development, LabVIEW\TestStand Verification and Manufacturing development. They were currently using VSS, but were not too attached (luckily). I ended up picking Seapine's Surround SCC as they already were using Seapine's TestTrack product for issue tracking. I looked at subversion, VSS, Perforce, and Surround. I think the deal breaker was that the VSS to SVN port did not go too smooth and we already had licenses for TestTrack. The VSS to Surround port went great and included all of the history. The downside to Surround is that it is pretty expensive (about the same as Perforce) with yearly maintence cost if you want support and free upgrades. As far as architecture, performance (especially over VPN), and SCM features (like workflow and branching) I think Surround was the best tool I looked at. Perforce was close but had some issues with LabVIEW environments (reuse in user.lib and project code off of c:\ had to be split up). That said, if I was working alone I would probably use TortiseSVN. One question I have for crelf is do you use SVN throughout VIE? If so, do you share code across offices? Do you have one central server, or do you have proxy applications to sync up code bases? Surround came with a proxy server for remote locations which was yet another reason it looked like a good solution. I was wondering if the SVN solution had something like that.

QUOTE(rolfk @ Oct 7 2007, 11:49 AM) Thanks for your reply. For some reason I wasn't able to reply on my PC at home over the weekend. My browser settings must be hosed. Someone answered from the NI forums as well with the same diagnosis. I was able to replace LabVIEW's QTLib with Surrounds newer version and was able to get it to work. Now I have no idea is that is going to effect something in LabVIEW (something I haven't used yet). I have a support case with NI for this to see if they have any idea if the 4.3.0.0 version can be used, or if there is some way to trick LabVIEW and Surround to use their respective QTLib's. Thanks for the info!

I have also posted this on the NI website, but I know you can get answers faster on this site. I am wondering if anyone else ran into this issue (probably not because most of you use SVN). I am getting an error when trying to configure LabVIEW 8.5 to use Surround SCM version 5.0.4, and their new beta version 2008.0.25. I also get the error when just trying to make a dll call using the call library function (after I point to the dll and the function it gives the error). I have used two computers, and LabVIEW will load perforce and vss just fine through the options window. I also have TestStand on the systems and it integrates fine with both versions of the Seapine Surround SCM client. I tried a couple of different installation types (with and without the JRE) with no luck. I get two different errors when I run the two different versions, but they are similar types of errors. The errors are attached. I looked into if the dlls need to be registered, but I get the error that they don't have a register entry point, so they probably are not supposed to be registered. I do have the path for the dlls in the environment variables (put there by the installation of surround). The only thing I could maybe think of is somthing needs to be setup in LabVIEW to recognize the dll links. Like I said, no problem with TestStand 4.0 linking to either version (I believe it calls the same dll). The dll in question is: Surround SCM SCCI.dll That is the dll that is pointed to in the registry. Final Notes: The nice thing about Surround is that it allows you to set the working folder for the lowest project to the root (c:\). This allows me to contain the project specific code as well as the reuse code (user.lib) in the same repository. Therefore allowing me to control all of the code in my project through the LabVIEW project window without having to change the project settings for the SCC. VSS also allows this, but I do not really want this to come to that (size limitations, no atomic commits :thumbdown: ). I was not able to get Perforce to allow me to set the root project to C:\. I did test out subversion, but it took me quite awhile to set it up (even without apache). I also could not see how to capture revisions of a release for a LabVIEW project that calls reuse code outside it's project directory. Would you just record the global version and save the names of all of the VI's (and TestStand sequences) called by the project? To restore that version of the project on your system you would get individual files per the revision, or would you get the entire repository based on that global revision? Help me out here almighty Subversion masters. :worship: Thanks for any inputs.

QUOTE(tcplomp @ Jul 31 2007, 10:50 AM) The File menu shortcut works. Thanks for the info. Thanks for reporting it to R&D. Seems like they just overlooked the tools menu if the code is already in the File menu.

Does anyone know of a way to create a shortcut key combination to select a cutom tool that is put in the Tools menu (project directory)? The menu screen in the options does not contain any custom tools in the list. Is there a certain naming structure that you can use to add it to the LabVIEW.ini file? Is there a trick with the supporting ".txt" file for adding a shortcut (I tried the underscore to see if I get an "alt" shortcut, but it didn't work). I have a little tool that filles out a VI information template for me and it would be extremely helpful to have a shortcut for this. THX

There is a bug in the add key - False - True - False where the Add Quotes.vi is not used and it is probably supposed to be used. All of the other cases have the add quotes vi where a value is written except for this case.

Do you include the virtual table for backward compatability (code upgraded from 7.1.1).

Very nice... and very useful. I was looking into ways to create multiple LVOOP objects and still have data protection, and this looks good. :thumbup:

Yeah...you can't really do that. You can't really force the activeX through the registry, or by calling the exe first and then calling the activeX. It will call the LabVIEW version that was first opened when multiple versions are opened, the version that is open if you are just using one version, and the last called version if you call the ActiveX from an EXE with no versions open. The way we are going to use the function though I think it will work as long as they don't have more than one version of the devlepment environment open. It will use the version that is open that they are calling the EXE from.