Frequently Asked Questions

Introduction

This document serves for providing answers to frequently asked questions. This document is frequently subject to changes.

Organization of software

What is a class?

A class must be located in the folder ROOTPATH\...\CSClass. A class is a class in the sense of C++. All classes provide attribute data and methods to work on the attribute data. Most classes provide active threads as well. Each class has a responsible maintainer that is described in ROOTPATH\LV71\GPL\Projects\cs-framework\Classes.xls. Each maintainer of a class is responsible for his/her classes.

What is a category?

All software is classified into a category. There are several categories.

1. Main: Contains software that is required for running a very basic CS system. All software in here must have a responsible maintinaer.
2. Contributed: Contains software that is used by more than one group/user/experiment/facility. All contributed software must have a responsible mainainer.
3. User: Contains software that
   1. is used by more than one group/user/experiment/facility AND has no responible maintainer.
   2. is used by only one group/user/experiment/facility AND has a responsible maintainer.
4. Deprecated: Software that is used by one or no group/user/experiment/facility and has no responsible maintainer.
5. Removed: Sofware, that no one is using and nobody takes care of. That software is moved to a folder ROOTPATH\...\cs-framework\CSGraveyard.

What is a package?

For release and distribution, the software is organized in packages. Packages are described in ROOTPATH\Packages\Packeges.xls. Each package has a maintainer. The maintainer is responsible for packing and distribution. The procedure of building a package is described in a dedicated How-To.

What is a library?

A library is a collection of routines and have a responsible maintainer as well. The most important libraries are also listed in the MS-Excel sheet mentioned above. Each maintainer of a library is responsible for his/her library. Libraries have no specific place in the source code tree.

What is a driver?

A driver is an interface to hardware or software

• Instrument Drivers are specific for dedicated type of hardware (instruments). They are located in ROOTPATH\...\instr.lib.
• Library Drivers are specific for a dedicated library like a dll (MS-Windows) or so (Linux). They are located in ROOTPATH\...\lib.lib.

What is a class group?

All classes are located in ROOTPATH/.../CSClass/... . The individual classes are grouped in sub-folders that denote a certain functionality like "CSAfg" for classes for AFGs (arbitrary function generators) or "CSAcquisition" for classes that do data acquisition. Class groups are only for convenience and having a structure in the source code. They have nothing to do with membership of a package or classification into a category.

What is a source code tree?

All software is installed in a tree-like folder structure. The source code tree should be placed in a path accessible for the user and not in the folder hierarchy, where National Instruments software is installed. By this, a tree can easily be used together with a source code control system like Subversion.

What is ROOTPATH?

ROOTPATH is the top folder of a source code tree.

Starting CS

Where can I get information about error codes of CS?

CS error codes are within the range from 8000 to 9999. Error codes of CS are defined in "CoreDefs.error_type.ctl". An offset is added to the error number. The offset is related to the "severity" of an error and is defined in "CoreDefs.error_type.ctl". For CS error codes as well as for LabVIEW error codes, you can get the error string by using the "CoreLib.get error string.vi". An important information is the call chain to the VI, that has produced the error. Typically, this information is added to the "source" string of the error. If you have a running CS system, go to "CS_Start->Help->Explain Errors".

Where can I get information about error codes of instrument drivers?

According to an old recommendation, error codes of instrument drivers are coded in the range of -1300 to -1399. According to a new recommendation by NI, instrument drivers should use a range from -1300 to -1210. Some instrument drivers as a so-called "error message" VI, that can be used to convert the error number to a message. Other instrument drivers use a text documentation like an Excel-Sheet to explain their errors.

Where can I get information about error codes of LabVIEW?

Use Help->Search the LabVIEW Help->"error codes" or Help->Explain Error or point your mouse on the "error control/indicator" on a front panel of a VI and right-mouse-click->"Explain Error/Warning". As for CS specific error codes, try "CS_Start->Help->Explain Error".

When I start CS, the CS_Start.vi stops with error code -1306.

If you get error -1306, you probably try to start a CS system with a name, that exists already elsewhere. This is a typical effect, that may happen, when one wants to rename a CS system on the fly.

Why can I not rename a CS system?

Once a CS system has started, it has a system name. The system name of the system is stored in a global variable. Moreover, each CS system is a DIM server that publishes its system name as a DIM service. Even if you shutdown the CS system, its DIM server (hidden in a shared library) stays alive and publishes some DIM services. Therefore, a CS system can not be renamed after it has been started. It can not be renamed, by shutting it down and re-starting.

If you would like to rename a CS system, close LabVIEW completely and start LabVIEW again.

When I start CS, the CS_Start.vi runs but shows error 9050

If a CS system starts, it first starts an object of the SuperProc class with the name "SYSTEMNAME\Super". This object tries to access the database to access its configuration data. At this point, error 9050 means that the database access for the SuperProc object failed. Either, the system can not connect to the database, or the object "SYSTEMNAME\Super" has no entry in the database. If this error has occurred, CS is still running but the SuperProc object has been started with default parameters.

When I start CS, the green light at the lower left of "CS_Start.vi" becomes red.

If the light is green (red), the SuperProc of object is alive (dead). Determining the status of the SuperProc object is done by

1. Sending a "Ping" event to the object to check it's event handling thread
2. Analyzing the timestamp of the counter of the periodic loop. If the timestamp is too old, it is assumed that the periodic loop is dead.

In most cases, the light becomes red due to a misconfiguration of the periodic loop. Either, the SuperProc object had no entry in the database and was started with default parameters or the entry is badly configured. Check the database entries PdcIntervall (iteration time for periodic loop) and PresetPdcWatchD (preset value for watchdog for periodic loop). The value for the iteration time should be smaller than the preset value for the watchdog.

When I start CS, the CS_Start.vi yields error code 1, "TCP Write in CS SQL Server.lvlib:CS SQL Client.vi..."

This happens, if your CS system has no connection to the SQL server. Possible reasons are: you forgot to specify the node of the SQL server (maybe a type mismatch?), you specified a wrong node, the SQL server has not been started on that node, there might be a network problem...

When I start CS, the CS_Start.vi yields error code -2147467259 (Hex: 80004005) "Exception occured in ADODB.Recordset..."

This happens, if the database does not exist. Maybe, you just made a type mismatch of the database name.

When I start CS, the CS_Start.vi yields error code -2146824579 (Hex: 800A0E7D) "Exception occured in ADODB.Recordset..."

This happens, if the data exists, but the SuperProc object has not been configured in the database. Example: If the system ID of your CS system is "TestSystem", your database must contain an object named "TestSystem\Super" of the SuperProc class.

I get an error message "Microsoft Visual C: Debug Assertion Failed, ..."

this problem occurs, when working with an account that has no administrator rights (as recommended) but National Instruments software has been installed by an administrator. Then, you cannot modify anything below .../Program Files/National Instruments/... . The problem is, that the runtime system of LabVIEW (non administrator) wants to modify some entries in that folder.

Solution: The folder ".../Program Files/National Instruments" and all sub-folders need access to all users. - File Explorer->Browse to ".../Program Files/National Instruments"->Right Mouse Click->Properties->Security->Select "Users"->Grant "Modify" (or "Full Control") to the folder and all sub-folders.

Operation

At some point I get an error like -1306, and then lots of things don't work anymore. What could be the reason?

Probably, your application performed an illegal operation in the DIM communication layer. A typical example, is to publish a DIM service that has already been published by an other appliation on the same or a different node. Then, your application is disconnected from DIM. See hints on debugging the communication layer for fundamental problems.

When an object is killed and then re-created, I get an error message like "object already exists".

Maybe the destructor was not properly executed. The most common problem is the attribute handling of a class. If resources are allocated in the constructor, they (or their references) are typically written to the attribute data. In case the thread or panel of the object does not use its attribute data (= the VI "CLASSNAME.get i attribute" or "CLASSNAME.get data to modify"), the functional global variable of class containing the attribute data goes out of scope: It is removed by the garbage collector of LabVIEW. The destructor can't access the attribute data any more, and cleaning up resources fails. Then, some panels or threads might remain alive. Then, re-creating the class will produce an error. Solution: Always include at least the VI "CLASSNAME.get i attribute" somewhere in your code.

When I selected "About Me..." from a menu, the message box is so large that I can't access the "Close" button.

Just press the "Return" key on your keyboard.

Debugging

How can I debug objects on-the fly?

• Using the ObjectInspector. The ObjectInspector works on all objects within a CS domain. It can be used by developers as well as users. The ObjectInspector can be used to view certain properties like
  1. error of the event handler,
  2. error of periodic action loop,
  3. error of state machine,
  4. loop counter of event handler
  5. loop counter of periodic action loop,
  6. watchdog status,
  7. ...
• Using the ClassUtilities.TestClass tool. This tool allows to view basic attribute data of object in the local CS system. Here, you can check things like references, registered events and others. This tool is meant for developers.

How can I debug the communication layer for fundamental problems?

There are two possibilities.

1. Via command line output of the DIM Name Server. Using the DIM tools (DID or DIMTree), send the DEBUG_ON command to the DIM Name Server. Then, have a look at the command line output of the DIM Name Server.
2. Via command line output of your application.
   1. On Windows, LabVIEW does not write to the console where it has been started. Therefore, the command line output is redirected to a file called "DimWrapper.log". From DimWrapper version 1.01 on, this log file will be written to the folder specified in the environment variable "DIMWRAPPER_LOGPATH".
   2. In Linux, just have a look at the command line output of LabVIEW.

Domain Management System

A program is not started by the DMSClient but therer is an error message "Possible resonas(s) Labview:memory is full, NI-480 Write detected no listeners - System Exec.vi Command "..."

The error message is created by LabVIEW and a bit unclear. It basically says, that it can't start the application that was requested. Typically, this has might have two reasons. Either the binary with the specified name does not exist, or the environment variable PATH does not include the location of the binary. Please include the folders(s) of all binaries in the PATH environment variable prior to starting the DMSClient.

Devices

PPB_ABC class. The object does not detect that the pattern output has stopped

This class determines the state by polling the FPGA status in the ProcPeriodic method. Thus, the "PeriodicInterval" should be set to a reasonable value. Use the "import ini-file" of the CSDBTools to get an example entry of that class in the database.

Other

When I close a VI (or quit LabVIEW), there is an error message "exception error ...".

Note: This issue should be fixed with package DimWrapper version 1.01 and LVDimInterface version 1.13. With older versions, the following might be observed:

This is a normal behaviour, when VIs that are using DIM are closed. Then, LabVIEW disconnects from the DIM libraries. Obviously, LabVIEW does not survive the closing down of the DIM threads. The only workaround is to keep one VI opened, that uses DIM. As an example, don't close the CS_Start.vi.

-- DietrichBeck - 23 Sep 2008