app runs in development environment but won't run as a standalone application

[Sloppy]

I have an application that runs in the development environment, but produces i/o errors when I build it to run as a stand alone application. It worked fine up until a very minor modification made several days ago. I added a single connection to an OR gate.

The kicker is, the identical modified stand alone app runs fine on three other systems, all Windows 2000 systems, but produces I/O errors on only this one Windows 2000 computer. All fours systems are very similiar, 600-800 mhz pentiums with 512 mbytes ram. However, it runs fine under the development environment on this troublesome system, but the stand alone app immediately produces I/O errors at the first attempt to access the Fieldpoint hardware on only this one system. The app ran fine before the minor modification.

Given that it runs ok under the debugger I'm having some trouble seeing what the problem is when it runs as a stand alone app. The error number returned is 34107 when I attempt to run it as a stand alone application on this one system.

Any suggestions on what the problem might be would be most appreciated

thanks

[sergesl]

Hello Sloppy,

What exactely is your configuration (software and hardware)? If I assume that you are using LabVIEW to build the executable, are building the executable with an installer and adding the all the support files that are needed?
You said that it worked before. If you go back to the previous configuration, does it work still? If so, what does the minor change involve?

Serges Lemo
AE
National Instruments

[Sloppy]

Hi Serges

>>What exactely is your configuration (software and hardware)?

LV 6.1 with FP 4.1. There are two separate FP controllers and module sets

First hardware configuration is (FPRES1.IAK)

FP1601 controller, 1 - FP-TC-120s , 1 -FP-RLY-410, 1 - FP-AO-210

Second hardware configuration is (FPRES2.IAK)

FP1601 controller, 2 - FP-TC-120s , 1 -FP-RLY-410, 1 - FP-AO-210

These control 10 separate process stations. The main VI selects the appropriate hardware configuration and IAK file based on the process station selected in the main VI.

>>If I assume that you are using LabVIEW to build the executable,

yes

>>are building the executable with an installer

yes

>>adding the all the support files that are needed?

well that might be a point. The only files I'm including are the main VI, which calls a number of sub VIs. The sub VIs are NOT included in the list. Do they need to be if they are called by the main VI? I don't recall if these were included before or not, as it has been quite a while since I have made any mods to this system. It has been running fine for almost two years prior to the minor mod I made recently that started the problems.

>>If you go back to the previous configuration, does it work still?

No, undoing the minor change does not rectify the problem, it remains leading me to beleive it is not the code by something external to the code.

I have since tested the stand alone app on another system and it doesn't work on that one either. So that means I have two systems on which it does work and two that it does not work on, which seems rather odd to me.

It runs fine on all four systems in the development environment

Thanks for your time and effort Serges

[Aaron_G]

Serges,

In addition to creating and installing the executable on a target system, you also need to install the NI-FieldPoint software on the target system. You should add the .IAK file from the development system as a support file to be included with the installer. Once you have installed the NI-FieldPoint software, you should make the IAK file that was installed as part of the installer active as the IAK file for the target system. You should then be able to run the application without a problem.

Regards,
Aaron

[sergesl]

Helly Sloppy,

I would advise you to try and build the executable with an installer with all the support files and subVIs added and see if that clears the trouble.
Let me know.

Serges Lemo
AE
National Instruments

[Sloppy]

Hi Serges and Aaron

Well I tried adding the subVIs I wrote for the application in the build, made no difference. The stand alone app still will not run although it will still run in the environement.

Aaron, yes FP is installed on the target machines. As i said, this app has been running for almost two years before I rebuilt to implement the minor change I made.

Do I need to include all the FP VIs in the build, for example READ, OPEN WRITE etc etc? I know for sure I have never included them before.

When I look under the VI Settings tab in the build dialog I see all the subvis I've written as well as all the FP vis, so does that not mean they are being included in the app?

I'm stumped. And this is going to be a serious problem soon if I can't get these systems running again.

Thanks for your input guys. Any other suggestions?

[sergesl]

Hello Sloppy

If they appear when you build the application, then they are being added. I ran accross something using the error code that you provided. You might want to read it at http://digital.ni.com/public.nsf/websearch/A2CC1E80ECA6661F8625660800617DBA?OpenDocument . Can you give more details about the minor change that you made (software changes, hardware changes)?

Serges Lemo
AE
National Instruments

[Sloppy]

Hi Serges

>>Can you give more details about the minor change that you made (software changes, hardware changes)?

In the main loop of one of the subVIs, several pressures and a temperature are monitored by one of the FP-TC-120s. The pressure readings are all 0-100mv so I use the FP-TC in that mode to monitor the pressures. I added a line from a LED indicator that is turned ON if a pressure value rises above a preset level to an OR gate that was already there to terminate the loop on a couple of other conditions.

Thats all I did, add a node to the OR gate and wire the output of the LED indicator to it, so that the loop is terminated on one more possible condition.

I had a look at the page you posted. The FPLVMgr.dll file is on all the target systems and the IAK file locations are hard coded into the app. All the systems use the same IAK files, I am certain of that as I have been bitten by that problem before. They are all read the IAK files from a comman network location.

There have been no hardware upgrades or changes and no hardware changes to the computers or the fp hardware.

Thanks again for you inputs. It is appreciated.

[Sloppy]

Hi Serges

Ok I figured it out.

About 4 months ago I installed LabView 7.1, mistakenly, as it was in fact intended for another engineer here. After installing it I realised it didn't have the "build an app" feature but I had already saved some of my VIS in 7.1 and couldn't get them back to 6.1. However, our local rep found an NI guy that took them back to 7.0 and then back to 6.1 for me.

However, at that time I didn't rebuild the app in 6.1 as I had just played around with 7.1 to see what it i was like. Earlier this week, after the minor mod, was the first time I had actually rebuilt the app in 6.1 after having installed and removed 7.1 and that was when the trouble started.

So I copied all the source VIs to an older development machine that had never seen 7.1, built the app and presto, the problem is gone.

So it would seem some vestige of 7.1 has been left behind on my current 6.1 development machine that is causing this build problem. I think I will try removing 6.1 and FP from the maochine and go for a fresh install to see if that cleans out the problem.

Your questions about hardware or software changes is what twigged me to the 7.1 install that I had forgotten about.

Thanks again, very much appreciated.

[sergesl]

Hello Sloppy

Thanks for making my day. I am very glad that my questions helped you figured out what went wrong. Good thing you are back on your feet. As I always say, we will always go the extra mile to help our customers.

Serges Lemo
AE
National Instruments