Why would I get different sized exe's if I build the same source code and target the same RT target?

[Ben]

Hi Bob P (Dr. RT) et al,

This is driving me nuts! I have a VI that uses different amount of memory depending on which machine I use to do the build.

I use the same build file and the same source.

It is targeted at the same cFP2000.

FP version is the same.

LV version is the same.

If I build it from the one machine, there is enough memory available to target the RT platform, show the front panel and do a "show RT engine info".

If I try this from the other machine, the cFP crashes, starts flashing the "status light" and latter on the crash dump file indicate "insuffiecient memory to complete this operation".

The OS on the two machines are both XP. O
ne is a laptop (the one that works) the other is a tower.

Are there any LV ini file settings that could be hitting me?

My customer is seeing the same issue, so it not just me.

Any clues?

Ben

[Bob_Preis]

I'm assuming you're building while targeted, embedding startup.exe in c:\ni-rt\startup on the cFP.

Few questions:
1)Ftp to your target. Are the exes the same size on disk?
2)Build the exes on the hosts. Are they the same size on disk?
3)Can you determine whether the exes consume the same amount of memory when loaded on the hosts?
4)Does your application call any dlls via an NI driver or custom-built?

I'm doubtful that any LV ini settings are causing this behavior. If I had to take a guess, it could be related to dll versioning. Do the hosts have identical versions of *all* drivers/dlls called by your app?

[Ben]

Hi Bob,

Few questions:
1)Ftp to your target. Are the exes the same size on disk?

No


2)Build the exes on the hosts. Are they the same size on disk?

I will have to look at this.


3)Can you determine whether the exes consume the same amount of memory when loaded on the hosts?
They will not run on the host because they use inport/output (to control serial port handshake lines).


4)Does your application call any dlls via an NI driver or custom-built?
THey use the "Settime.dll. At build time the builder says the target OS has its own version of this (and FP).


I'm doubtful that any LV ini settings are causing this behavior. If I had to take a guess, it could be related to dll versioning. Do the hosts have identical versions of *all*
drivers/dlls called by your app?"

Can you give me a suggestion on how verify this.

I have double checked LV (6.1) and FP.

Ben

[Bob_Preis]

So you're calling settime.dll (via Set Date and Time.vi) and cviVXDWrapper.dll (via In Port and Out Port). Are there any other dlls called by your application?

Do a search on both hosts for those two dlls (and all other dlls called by your app if applicable). First, if either host has multiple copies of a given dll, backup/delete all but one copy on each host. Make sure that the one and only copy of a particular dll is identical in size and date created/modified on both hosts.

So you will have the following:
Host A
X.dll
Y.dll
Z.dll

Host B
X.dll
Y.dll
Z.dll

Host A and Host B have only one instance of X,Y,Z.dlls and Host A's X,Y,Z.dlls are identical to Host B's X,Y,Z.dlls. Once you have this set up, is the behavior different?

[Ben]

IF the builder knows at build time that the target has its own version of the setime.dll, why would ".dll" I have on my developement machine make a difference?

The only dll's listed at build time are the two I mentioned.

Is there a good way of figuring out what dll are being called by the NI password protected VI's?

Ben

[Bob_Preis]

Settime.dll is not installed on RT systems by MAX. It gets sucked into the build as a dependency. On the other hand, cviVXDWrapper.dll does get installed on RT systems. To verify this, you can do a search for the files on your RT Images folder.

Sounds like you're not calling any custom built dlls, so besides settime.dll, I can't imagine what else might possibly cause two different builds.

Here are a few more suggestions:
1) You might want to try using the same host LabVIEW.ini file on both build machines in case there is an environment setting affecting the build.
2) Build/download exe from Host A, then connect from Host B. (then swap A and B in above sentence)
3) Check exe size on disk when built untargeted on both ho
sts.

[Ben]

Wow!

"2"
Building from one machine and then attempting to connect from another has never worked in the past. This usually result in LV-RT telling me that VI's have changed. The VI's that are listed are the VI's that call FP VI's.

I have not tried this since tossing the polymorphic FP VI's but I will see if this can be done now.

THank for your replies!

Ben