LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Project conflicts using SVN

Solved!
Go to solution

I agree with you, so we aren't really "agreeing to disagree", we're "agreeing to nuanced interpretations".

 

BS

0 Kudos
Message 11 of 16
(1,037 Views)

Does anybody know if the VIPM tool checks for the system bit version? Is it possible that the VIPM tool is installing a sepearte code base of Open G that is optimized for 64 bit? That would explain why Open G is not finding the VI's even if they have the same name. 

 

Also,

Just want to make sure, You do have the "separate compiled code from VI" checked?

 

When using source control this is a time saver, and there are only a few caveaat where this would cause an issue.

 

 

 

 


Engineering - The art of applied creativity  ~Theo Sutton
0 Kudos
Message 12 of 16
(1,025 Views)
There is nothing in OpenG that is "optimized" for 64 bit. To tell the truth, there's a lot of OpenG is superfluous. The problem is that as far as I can tell there is no one maintaining the libraries with the result that there are many routines that are no longer needed because there are built-in functions doing the same thing.

Concerning separating source code, there is a check box in VI properties for setting it. In addition you can change it programmatically using VI Server.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 13 of 16
(1,000 Views)

@Bob_Schor wrote:

(...) if you open a LabVIEW 2012 32-bit Working Copy and manipulate it with either (a) a later version (say, LabVIEW 2014) or (b) a "different-bit" version (say, LabVIEW 2012 64-bit), if you commit this to the trunk, when you update it you will not be able to open it again in the original LabVIEW.

  

Bob Schor


Actually, whereas your (a) is true, the (b) is false. There is a full both way compatibility between the 32 and 64 bit LV versions within the same "major" revision (2012, 2014 etc). In addition, it is independent of the compiled code separation setting. The other thing is that these versions have diffrent root paths (Program files and Program files (x86)) which apparently has an influence on the dependencies on some older extra packages (this OpenG mentioned here).

0 Kudos
Message 14 of 16
(983 Views)

@MrQuestion wrote:

(...)

 

Also,

Just want to make sure, You do have the "separate compiled code from VI" checked?

 

When using source control this is a time saver, and there are only a few caveaat where this would cause an issue.

 

 

 


Yes, I changed this setting together with moving all of my code to an identical folder structure on both machines. This folder structure was originally outside the LV root, but was diffrent on both systems. Additionally, I switched to exactly the same LV rev. on both systems. I have not (yet?) changed the user.lib position, as mikeporter suggested. The benefits are not quite clear to me yet in my einvironment. Besides, I'd need an extra portion of courage to do thisSmiley Wink

So I cannot tell how much (time) I won with this one particuliar setting, but I do realize the benefits.

All in all it got much smoother and faster.

Thanks to all of you.

 

0 Kudos
Message 15 of 16
(974 Views)

Thank you for telling me that!  I've never worked with 64-bit LabVIEW -- I naively assumed that, just as with almost every other system I know that has 32- and 64-bit versions, there would be differences (though I'll grant that C code, saved in a Repository, would be the same if it was designed for a 32-bit or 64-bit compiler, so this is probably Fuzzy Thinking on my part).

 

Fortunately, one can say silly things on the Forum and be gently corrected ...

 

Bob Schor

0 Kudos
Message 16 of 16
(950 Views)