Runtime error 2228

[brunobraun]

Dear all

I'm running in a 2228 error, when executing code in the run-time environment. The same code works fine on the same machine in the LabView development environment (windows 7, labview 2012). The same code works fine on Mac os X, in the devleopment as well as the runtime environment.

The partucular code is dynamically loaded as a member of a class. The class-loading works fine, however, the error occurs later when this particular vi should be executed.

My problem: How can I debug this problem?

Any help is highly appriciated,

brunobraun

[IanS]

Hi,

Have you included the dynamically called vi (or classes) into your build specifiation? If it is called dynamically, Labview won't automatically include it in the build. You add files to the "always included" section in the build specification.

[brunobraun]

Thanks for your reply.

Yes, it is included. It is also correctly loaded and working in the in LabView itself when loaded dynamically.

I systemacally disabled code step by step. The problem arises, when the sub-vi tries to access class-data, which is passed by a reference and accessed by a in-memory data structure.

I have the *impression*, that something goes wrong with the linking. The code is old, was not changed for more than one year and working in both, the development and the runtime environment. Unfortunately, mass-compiling does not solve the problem.

Windows is running virtualized and I recently had to switch the windows instance. It was the first time that I made a new build for the plug-in.

Regards,

Brunobraun

[HeinzG.]

Hi brunobraun,

I don't know if you know the option "enable debugging" in your build specs (see attached pic). Maybe it helps you.

Could you post a MAX report of your MAC and WIN system?

Can you Post your Project?

I assume there is a driver missing. Do you use any hardware?

Kind regards

[brunobraun]

Hi

Thanks. Debugging is enabled but did not really help me further (perhaps I'm missing here something).

It is working now by a changed hand-over method of the data. Unfortunately, it was really a public VI accessing private data of a class by a "in place memory structure". The same problem occured using property nodes. There were no drivers involved, all subVIs were present and the problem only arised in the runtime environment (Windows, worked on the same machine and account in LabView itself, worked on the Mac in the runtime environemnt and LabView). 

We had a LOT of linking problems using LabView 2011, especially in combination withn SVN. It happened, that mass compile got stuck in a loop. We fixed the problem then by opening all fles and force compiled them individually by hand. This poblem seems to have improved in LabView 2012, especially since all source code and compiled code can be really separated. I assume it is a a similar problem here.

Brunobraun