LabVIEW 64 bit <-> 32 bit and version control

[mishklyar]

Hello,

I have some annoying behavior when using labview 32 and 64 bit versions on different machines

and transferring the VI's from one machine to another using version control.

I have already selected the option of "separate the source from compiled code", however the controls

and classes do recompiled  when transferred from one machine to another.

May be there is some way to avoid it?

Thanks,

Michael.

[Norbert_B]

Michael,

if you seperated the compiled code from all LV sources you are using, this is unexpected behavior as each system has to recompile everything, but contains the compiled code as separate image file.

I assume that you do not have the exact version on each system. Can you check for SP/hotfixes?

Norbert

[MaveenD]

Sorry,but What are SP\hotfixes?

[Norbert_B]

SP = Service Pack. NI usually creates one service pack for each individual application development environment (e.g. LV, CVI, ..) before releasing a complete new version (2011 => 2012). SP's are liable to cost.

Hotfixes are patches for specific versions of the development environments if NI finds critical issues in that version. Hotfixes are provided for instance by using the NI Update Service and are free of cost.

For example LV 2012 SP1f4 means:

LV version 2012, Service Pack 1 with hotfix 4.

Norbert

[mishklyar]

Hello Norbert,

Thank you for the detailed answer, the versions do actually different:

The 32 bit one is SP1 + f1 patch.

The 64 one is without any update.

I am downloading the relevant updates now, so both machines would have the same version.

Would post the results.

Thanks,

Michael..

[KathrynB]

Hi,

I'm not sure that seperating the source and compiled code will have an effect. I'm assuming you're running two version of LabVIEW rather than one being compiled and just using the RTE...

I've been having great fun (and will do for a long while) moving between 64-bit and 32-bit versions adn because they are so different then they will always recompile on each machine depending on which version it was saved in. I'd imagine if the decoupling achieves anything it would be to force a recompile in every situation instead... Which is what you are seeing.

[mishklyar]

I have looked closer at this problem.Installed all the SP1 and updates so that both 64 and 32 bit would  the

same version.The problem still persist.The interesting thing, that only small fraction of controls and classes is

modified when transferring from 64 to 32 bit platform.Something like 36 controls/classes/vi's out of 1500+.

Just for curiosity I have looked at the difference between class .ctr presentation on 64 and 32 bit.

Only one line is different out of many, attaching the screenshot with a difference highlighted.

It seems like some kind of variables stored differently on 32 or 64 platforms.

Would be interesting to have some insight, if I can avoid it from user point of view.

[MCurie]

[KathrynB]

Well done, that has shown far more dedication that we did! I think we just accepted that with programmes of differing 'bitnesses' we would have compilation issues, as there would be different methods of referencing memory - which is what you seem to have found - I think. If there is a solution I'll be interested, but I'm not sure there could be one, this may be something at a deep fundamental level that can't be dealt with - a bit like trying to call a 32-bit dll in a 64-bit application - can't be done...