Facing Issue while creating EXE in new PC

[மணிகண்டன்]

Hi, 

I have been using one test PC for a Code development and testing purpose. We have duplicated that Test PC to increase the productivity. 

When I Create new exe in the old test PC, I'm not able to use it on the New test PC. It's throwing DAQ error(Attached screen shot here).

When I create EXE on new test PC, I can use it in old test PC. but the problem is New PC is taking more than 1 hour to create new exe.

Please help me to fix this issue.

[JÞB]

I would guess that you have a newer version of DAQmx on the new machine.

What happens when you checkout the source code (From your SCC repository) on the new machine?  If you say, "We don't use source code control." You have found your first problem...fix that FIRST.

An hour to build an executable sounds excessive.  I could guess all day long about what you've done wrong but it would be simpler if you either:

A) sent a screenshot of the project files view or

B) attached a copy of the lvproj renamed with a txt extension. 

[மணிகண்டன்]

We have installed same version of DAQmx installed on both PC.

We are using perforce as a version control tool. when I checkout files on new PC, it's not asked me to save it again on the new PC & nothing is getting changed.  

I tried to mass compile the source code to fix all the VIs. even after that also it's taking more time to compile the EXE.

Thanks,

Manikandan

[altenbach]

So you have two problems:

1. Some DAQmx incompatibility
2. excessive build time (>1 hour) on the new PC (You did not say how long the build takes on the old PC, so we don't really have a good reference. Minutes? Two hours??)

What are the differences between old and new PC (OS version, OS bitness, other software such as antivirus, etc. etc.)

If it needs to, but cannot load the front panel, it is possible that the builder accidentally removes it. Have you tried clearing the build cache on the old PC?

[JÞB]

---

@மணிகண்டன் wrote:

We have installed same version of DAQmx installed on both PC.

We are using perforce as a version control tool. when I checkout files on new PC, it's not asked me to save it again on the new PC & nothing is getting changed.  

I tried to mass compile the source code to fix all the VIs. even after that also it's taking more time to compile the EXE.

Thanks,

Manikandan

---

That helps a little.  I would expect that the vi error is actually a poly instance vi stuck in dead code.  Since the code is dead the build removes the unused poly instance from the poly vi.  If debugging is also enabled the FP would be gone gone gone and the exe won't load right.  Check the advanced exclusions of the build spec and deselect remove unused polymorphic instances and unused library members.

Long build.  First problem to look for is dependencies that really belong in the project.  Second is autopopulating folders.   Both can cause long searches to load and relink items in the temporary source distribution.   

Then look at the new PCs RAM. I won't touch "Build" with less than 16Gb DDR4 and 32Gb DDR5 is what I spec for development machines.

[Bob_Schor]

There are many significant (but unknown-to-us) potential differences between the "original" PC and the "new" PC, which makes speculation (as a colleague of mine, who worked at NASA Headquarters, taught me) somewhere between a ROM and a WAG (Government 3-letter Acronyms for "Rough Order of Magniture" and "Wild A*s Guess").  Some significant differences have been mentioned, but no data provided:

• PC Hardware, including amount and type of RAM, not to mention type and capacity of Hard Drive, Display, etc.
• PC Software, including version of Windows.
• Version of LabVIEW, including exact structure of LabVIEW installation.  Are both 32 and 64 bit versions installed?  Assuming that the rest of the PC Software structure is identical, are the two LabVIEW installations identical?
• What other Tools/Toolkits are installed on the two systems?  This would include both LabVIEW-ish "features" (such as VIPM Toolkits) and third-party utilities that the "code under consideration" uses.
• What other software gets "rolled into" the LabVIEW executable(s)?  Are identical versions installed on the two Test systems?
• Finally, the key question, what LabVIEW Features (and possible Foibles) are inherent in the LabVIEW code that is the topic of this query?  Is this a "single CPU" LabVIEW routine?  A LabVIEW Real-Time (a "dual CPU") routine?  Does it involve an FPGA (a "triple CPU" routine)?  Are Asynchronous Channel Wires part of the mix (resulting in a shall-we-say "flexible" ExtraVILib folder)?

It seems to me that the situation being described here has some "hidden features" that make it difficult to diagnose "from afar".  Might be a good time to bring in some Consultants who can spend some time "asking embarrassing questions" and possibly working with a "clone" of your test PC, where you can keep the differences down to a manageable number).

Bob Schor