gmart

Hi Gmart

Will this ever change in the future (64bit being able to produce a 32bit build) or is it forced by the nature of the OS.

Cheers

JG

You can consider the 64 vs 32 bit application similar to building an app on Windows that will run on Mac. Essentially we would need to have the ability to cross compile VIs for a different OS (in this case bitness being the difference). I am not aware if there are plans to support building for the different OS's.

I'm waiting for the Developer Suite first....we use VLM as well (does anyone know if we need a new license file and when the upgrade DVDs will arrive? We just received new DVDs that still had 8.6.1...waste.)

One question that those of you who have installed it already might know; is it possible to build 32 bit apps in LabVIEW 64bit? We'll probably need to support 32 bit systems for a while, but it would be nice to run the 64 bit version of LV and just have it as an option to build the app as 32bit.

No. 64-bit LabVIEW will only build 64-bit apps. 32-bit LabVIEW will only build 32-bit apps.

We were using VSS but have since moved to TFS now. Is there a way to use TFS in LabVIEW like I did with VSS. I was able to connect to VSS and check-in/out code inside of VSS, however with TFS I have to use the client in Visual Studio 2008 to check in/out code.

Thanks,

Matt K.

I believe you need to install an integration plugin. See this Microsoft KB - http://www.microsoft.com/downloads/details.aspx?familyid=87E1FFBD-A484-4C3A-8776-D560AB1E6198&displaylang=en

QUOTE (silmaril @ Jun 11 2009, 11:32 AM)

So there is still the question: which of the two Perforce providers should I configure in LV?

I prefer the Perforce SCM provider, simply because it's faster when working with large projects.

If Perforce SCM works for you then stick with it. The Perforce command line provider works across all platforms, but if you're on Windows only, SCM will work for you.

QUOTE (jed @ Jun 8 2009, 02:53 PM)

Are the Perforce CL Provider tools available now? As I last recall, they were hidden away behind passwords a few years ago.

As of LabVIEW 8.0, the Perforce Command Line provider has been available. None of the VIs (except for a couple) are password protected.

QUOTE (shoneill @ Jun 8 2009, 07:51 AM)

Maybe a stupid Q but what's the practical difference when using the two providers.

I've been using the SCM up till now, I assumed one was a command-line version whereas the other was a GUI version. Silly me.

Shane.

Perforce SCM is a Perforce written provider. The dialogs and functionality provided there are provided by Perforce. The Perforce Command Line provider is a set of LabVIEW VIs that provide SCC functionality (including UIs) by using Perforce's command line tool (p4). For the most part both providers provide a similar level of functionality. An advantage of the Perforce Command Line provider is that it is cross-platform. Also, by using the command line, operations such as a native LabVIEW diff can be performed. You can diff LabVIEW files with Perforce SCM, but you have to configure a tool (such as lvdiff) from the client to do this.

QUOTE (jed @ Jun 5 2009, 03:34 PM)

I have been using P4 with LV since 2000. I have never liked the NI P4 SCC plugin,...

For the record, the P4 SCC plugin (Perforce SCM) is not written by NI (The "Perforce Command Line" provider is). LabVIEW calls into Peforce's implementation of their SCC provider. The functionality exposed through the Tools>>Source Control menus is based on a common source controlled interface so it will lack customization for each provider.

QUOTE (Ton @ May 7 2009, 03:46 AM)

I think this is called the Identity of a function.

For a AND Array the Identity is True where an OR Array has a FALSE Identity.

Ton

That is the reason that was given to me.

I had had the same reaction when I first ran into this. I asked a fellow developer and he said that from a computer science perspective, this results is correct. I don't recall the details but this is not considered a bug.

The trailer tease about Uhura and Kirk sure made their kiss back in the original series look like Sunday school.

Perforce has a plugin for Windows Explorer as well. It installs automatically. I now do not install it since one of the early releases had a problem hanging my computer when the server was down. Anything that integrates to Explorer that can connect to a remote server is asking for trouble in my book. Of course that's how Tortoise works (and has worked fine for many releases) but I'm still leery of Explorer plugins.

QUOTE (Darren @ Apr 21 2009, 11:26 AM)

I'm pretty sure the most advanced feature on that calculator is that you can type in "5318008" and turn it upside down.

-D

I was engineering student. That feature never worked for me .

QUOTE (crelf @ Apr 21 2009, 01:27 PM)

I think I have calculator envy :thumbup: . Down with reverse Polish notation!

QUOTE (Darren @ Apr 21 2009, 10:17 AM)

That's hilarious. Man, this is so cool that there's HP calculator zealots here. I guess it goes with the territory, though...you guys all have impeccable taste in programming language, so it only makes sense that you'd all like the best calculators too.

-D

I am proud to admit that I bucked the geek train and refused to use an HP calculator in college. I had a Casio FX-6300G (http://www.rskey.org/detail.asp?manufacturer=Casio&model=fx-6300G).

QUOTE (jpdrolet @ Apr 8 2009, 08:54 AM)

I did and P4SCC did request a server version 2004.2 or later (from LabVIEW or P4Win). P4SCC 2008.1 does support our server version, P4SCC 2008.2 doesn't.

Well LabVIEW can invoke the Revision Graph feature with our server and P4SCC 2008.1 while P4Win does request server version 2004.2 or later. Incentive to upgrade, maybe?

Perhaps. The requirements are interesting. I am not well versed on Perforce's needs so you'd have to ask them why they chose to do this. Just so I'm clear, you are not able to use the P4SCC 2008.1 because it wants a newer server correct? I believe the original problem you reported was fixed in a P4SCC with a 2005.x version and higher (though I'm not sure). You would need to verify this with Perforce, but I think it's possible to have a different version of P4SCC, P4, P4Win and the like all on the same machine.

QUOTE (jpdrolet @ Apr 8 2009, 07:47 AM)

Thanks for replying.

Unfortunately, our Perforce server version is 2002.2 and the latest client supporting it is 2008.1 . Changing the SCC from Perforce SCM to Perforce Command Line prevents the popups. However we lose the neat Revision Graph feature.

That begs another question: using Perforce SCM why can LabVIEW invoke Perforce's Revision Graph feature (or close relative) while P4Win can't (or doesn't allow)? :ninja:

You shouldn't need to update the server version. What is needed is the later version of the P4SCC plugin. This plugin is typically installed with the P4Win or P4V installations. As far as the revision graph feature, Perforce SCM is Perforce's implementation of IDE SCC integration. So they expose whatever features they choose. I checked my P4Win (which is 2008.2) and it does have the Revision Graph option. I'm not sure if support for this is tied to the version of the server you are running.

QUOTE (jpdrolet @ Apr 7 2009, 09:21 AM)

When I build an application (LabVIEW 8.6) I get popups from Perforce (Perforce SCM version 2004.2) saying:

p4 fstat -P {1 files}

Path 'x:\Projets\BUILDS\internal.llb' is not under client's root 'c:\'.

Indeed the destination is not under the Perforce root as I don't keep executables under source control. The popups pause the build until I click OK. That is rather annoying since the second popup appears under the build status window so I have to check the windows bar (preventing me of doing http://xkcd.com/303/' rel='nofollow' target="_blank">other useful tasks).

It looks like a bug since internal.llb is a temporary file and there is no need to check its SCC status.

This is a combination of two bugs - one LabVIEW and one Perforce. The Perforce 2004.2 was showing this dialog whenever there was an fstat problem. This was corrected in a later version (the current version is 2008.2). Secondly, LabVIEW is checking source control status on files during a build. This is a known issue and has been reported to LabVIEW R&D. Updating the Perforce version should eliminate the dialog.

QUOTE (335x @ Apr 5 2009, 10:47 PM)

Of course... i just... well i have the student version...

Thanks for the response.

QUOTE (335x @ Apr 4 2009, 10:37 PM)

I'm sorry if this is a lame question or has been ask so many times before but I really need to know, I've like a month experience and no one is teaching me how to use this software… so… is there any option to build a .exe from a .vi ???

Out of curiosity, did you try to search LabVIEW's menus or help and could not find your answer or are you asking before having done this?

QUOTE (jlokanis @ Mar 26 2009, 04:52 PM)

Yes, but what 'App.Kind' is a web service?

App.kind returns what type of application is running the VI. So in the development environment, the property will return "Dev system" (or whatever it is). If a VI is loaded via the run-time engine, the property should return "Run Time System".

QUOTE (jlokanis @ Mar 26 2009, 02:07 PM)

I have a question about this. What if you want to write some code that will work in both the case of running under the dev env where you ahve a project open AND running as a compiled EXE, were the main exe is in the main app (default) instance. Can you test for DEV vs RTE in the web service? Does it even run as if it were in the DEV env? Is there a better was to detect this?

thanks,

-John

You could try using the App.Kind VI server property.

QUOTE (Jim Kring @ Mar 18 2009, 06:44 PM)

Hi George,

I apologize, in advance, for not reading this whole thread (or testing to answer my own question, below). I just have a quick question:

Are lvlib members really also loaded into memory when the project is loaded? I thought that only class members were loaded into memory when the project was loaded.

Thanks,

-Jim

In general, no. I was trying to cover my bases since it's possible that a library owns a class and such. In that case, loading a library would load VIs but only due to a class being a member of the library.

QUOTE (Cmal @ Mar 18 2009, 03:36 PM)

Here are some of my thoughts on projects that I hope will help make a believer of you:

• One of the nice things about the project (in my opinion) is that all VIs are loaded into memory when a project is loaded. This helps ensure that there are no missing VIs, and it has saved me a lot of confusion more than a few times.
  
• The project integrates nicely with source code control. You can see which VIs are checked out, or which ones haven't been added to SCC from the project window. Once again, this has saved me the pain of accidentally creating VIs and forgetting to submit them the SCC.
  
• Auto-populating folders are not required. I personally use virtual folders instead.
  
• If you ever decide to use native LabVIEW classes (and you should), then the project is pretty much required. The same goes for XControls, Shared Variables, and many more LabVIEW features that don't come to mind right now.
  

Chris M

A clarification. A project ,by itself, does not load VIs into memory when it is loaded. It is able to determine what dependencies are needed/used without loading VIs into memory. The project does load project items such as libraries or classes which may load VIs.

Are you able to whittle this down to where driver's are not involved? Also is the application able to be posted for evaluation?

QUOTE (Dan DeFriese @ Feb 12 2009, 04:30 PM)

I disagree, I think user.lib contents should be under SCC or some other approapriate alternative. However, since these VIs are, presumably, used in multiple projects I wouldn't want to maintain multiple repositories.

In any event, I think the biggest problem with integrating SCC with the LabVIEW is that the repository path is tied to the LabVIEW.ini file and not the *.lvproj file. This is why I don't use the feature... Now that I know how to create and custom preference files I may start playing with this again.

As of LabVIEW 8.5, you can configure source control project settings at a LabVIEW project level. You still need to enable source control for the environment though.