klessm1

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

Well if you have a look at the provided examples they all start with creating a task, this is a very good habit.

So yes I would try such a thing.

Ton

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)

I have a problem with the library LVSOUND2. I would like to read less than 50ms of samples each time from my sound card microphone. I checked the example "Continuous Sound Input.vi" and found that for configuration: 8kHz/1ch/8bit reading 160 samples gives me error within first few seconds (attached file) . the VI is not fast enough and sometimes it takes over 100ms to read 10ms buffer of samples. I'm wondering what the LVSOUND2 library is using exactly? What library in windows does it use? is it Direct Sound or maybe some other APIs? I'm thinking of creating my own library which can be more accurate that will use direct sound or other windows sound library.

QUOTE (Ton @ Dec 17 2008, 01:07 PM)

My thoughts on auto-populating folders:

• I agree with the original LVProject developers to not use auto-populating folders (the feature was added after begging from the users), creation of VIs should be done with the project in mind, currently I dump all VIs in a VI folder on disk and structure them in the project.
  
• Using auto-populating folders together with libraries (XControls/classes/lvlibs) can (and will be) very confusing. (my :2cents: )
  
• I never had a need for auto-populating folders
  

However I think LabVIEW ignores hidden files/folders.

Ton

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)

LabVIEW 8.5 does use the QTLib for something in its user interface or whatever but I'm not sure for what. Look in your LabVIEW 8.5 directory to see those DLLs. The problem you are having is that your Surround SCC software uses that library too but not the same version as LabVIEW 8.5 uses. That gets you into the so called DLL hell. LabVIEW already has loaded it's own QTLib DLLs when the Surround SCC client gets loaded. This client also wants to load his QTLib for some functionality but since Windows sees that that DLL is already loaded into the current process it will simply attempt to have this client library link to LabVIEWs version of the DLL. And that goes wrong since those libraries are not binary compatible, something Unix shared library developers never usually worry to much about since they are used to versioning of the shared library name to resolve such issues.

I'm afraid you run into a roadblock with Surround and LabVIEW 8.5. As I have no idea for what LabVIEW 8.5 brings its QTLib stuff with it I can also not help you with any ideas if and what would have to be disabled in LabVIEW in order to not have it load QTLib, if anything can be disabled. For its UI Widget stuff I can't really imagine that they replaced the entire existing windows manager code to use QTLib instead of continuing to use their own already implemented window management code, so what QTLib really is good for in LabVIEW 8.5 is really a secret to me.

Rolf Kalbermatter

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)

Move the tool to the 'File menu' (the wizard folder) and after a reboot you can link your shortcut to the VI.

I wouldn't know why they would allow that but not allow it in the Tools menu.

Ton

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.

Cool, glad you like it.

I'll post up a few more demos soon, one demonstrating active objects would be interesting. At the moment I'm manually editing the existing demos described in the GOOP Developer Tutorial, but what I'll be working on very shortly is how to auto generate the code, which will be both challenging and fun. I'll keep everyone updated with how I'm progressing with that.

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

Hi Everyone

I've been tinkering with LVOOP and playing with ways to merge LVOOP and the Open Source GOOP Template. It actually hasn't turned out too difficult to take some existing demo classes built using GOOP Developer and edit them so that they use the LabVIEW class datatype. The immediate benefit of this is that dynamic dispatching (or virtual methods) are automatically handled, no more registering virtual methods.

The next step is to start investigating how to get GOOP Developer to auto generate the classes and also build children, I'm just starting to look at the scripting options and I'm sure its possible.

Demo code attached

Download File:post-1058-1162936616.zip

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:

Have you tried invoking the server object with the desired version? For example, "LabVIEW.Application.7.1" instead of just "LabVIEW.Application".

Saludos,

Aitor

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.

Hello!

I use:

LabView 8.2

Tortoise 1.4.0

Subversion 1.4

PushOk SVN SCC plugin 1.4

Lvdiff 2.3

The Problem:

Everything works fine (check in, check out, revert to an older revision

I have noticed that when you call the LabVIEW developement environment using ActiveX it will only open a reference to the last used version of LabVIEW. Is there a simple way to call the version you want. I can think of two ways, but they are not very pretty. One is to open the version of LabVIEW using the call exe function before calling the ActiveX open (haven't tried this, so I don't know if it will work). The other is to update the registry so the ActiveX call thinks the last LabVIEW opened was the one that you want. Isn't there a simple way out there?

The target application I am thinking of using this functionality are tools that can save vi's in any version, but the entire tool is written in only one version. It would be an EXE that calls out to the LabVIEW development environment using ActiveX for the save.

Thanks for any inputs.