LabVIEW Wiki - User contributions [en]

DCO

2020-08-05T22:19:30Z

Mefistotelis: /* DCO Cluster */

''DCO'' stands for '''Data Controller Object'''.
''DCO''s are related to control of data flow within [[VI|VI files]]. They can be attached to [[DDO]]s in both [[Front Panel]] and [[Block Diagram]].

Within [[VI|VI files]], ''DCO''s are stored as an array of [[Cluster]]s which is a part of [[Data Space]].

== DCO Cluster ==

Below are the [[Cluster]] fields which make up DCO within [[Data Space]].

{| class="wikitable"
! Data Type
! Field Name
! Description
|-
|[[I16 data type|I16]]
|dcoIndex
|Index of the DCO currently being defined. DCOs are stored within VI files sorted by this index.
|--
|[[U16 data type|U16]]
|ipCon
|
|--
|[[U8 data type|U8]]
|syncDisplay
|
|--
|[[U8 data type|U8]]
|extraUsed
|
|--
|[[U8 data type|U8]]
|flat
|
|--
|[[I8 data type|I8]]
|conNum
|
|--
|[[I32 data type|I32]]
|flagDSO
|[[Data Space]] Offset which is start of the data for the [[Type descriptor]] referenced by flagTMI.
|--
|[[I32 data type|I32]]
|flagTMI
|Type Map Index which references [[Type descriptor]] containing flags.
|--
|[[I32 data type|I32]]
|defaultDataTMI
|Type Map Index which references [[Type descriptor]] containing Default Data for the DCO.
|--
|[[I32 data type|I32]]
|extraDataTMI
|Type Map Index which references [[Type descriptor]] containing Extra Data associated with the DCO.
|--
|[[I32 data type|I32]]
|dsSz
|
|--
|[[U8 data type|U8]]
|ddoWriteCode
|
|--
|[[U8 data type|U8]]
|ddoNeedsSubVIStartup
|
|--
|[[U8 data type|U8]]
|isIndicator
|Boolean value which informs whether this DCO is a [[Control]] or an [[Indicator]].
|--
|[[U8 data type|U8]]
|isScalar
|
|--
|[[I32 data type|I32]]
|defaultDataOffset
|Offset within the [[Data Space]] which is start of the data for the [[Type descriptor]] referenced by defaultDataTMI.
|--
|[[I32 data type|I32]]
|transferDataOffset
|
|--
|[[I32 data type|I32]]
|extraDataOffset
|
|--
|[[I32 data type|I32]]
|execDataPtrOffset
|
|--
|[[I32 data type|I32]]
|eltDsSz
|
|--
|[[U8 data type|U8]]
|copyReq
|
|--
|[[U8 data type|U8]]
|local
|
|--
|[[U8 data type|U8]]
|feo
|
|--
|[[U8 data type|U8]]
|nDims
|
|--
|[[U8 data type|U8]]
|copyProcIdx
|
|--
|[[U8 data type|U8]]
|copyFromRtnIdx
|
|--
|[[U8 data type|U8]]
|misclFlags
|
|--
|[[U8 data type|U8]]
|unusedFillerByte
|
|--
|[[I32 data type|I32]]
|subTypeDSO
|
|--
|4 x [[U8 data type|U8]]
|customCopyFromOffset
|
|--
|4 x [[U8 data type|U8]]
|customCopyToOffset
|
|--
|4 x [[U8 data type|U8]]
|customCopyOffset
|
|}

[[Category:LabVIEW internals]]

DCO

2020-08-05T22:17:47Z

Mefistotelis: /* DCO Cluster */

''DCO'' stands for '''Data Controller Object'''.
''DCO''s are related to control of data flow within [[VI|VI files]]. They can be attached to [[DDO]]s in both [[Front Panel]] and [[Block Diagram]].

Within [[VI|VI files]], ''DCO''s are stored as an array of [[Cluster]]s which is a part of [[Data Space]].

== DCO Cluster ==

Below are the [[Cluster]] fields which make up DCO within [[Data Space]].

{| class="wikitable"
! Data Type
! Field Name
! Description
|-
|[[I16 data type|I16]]
|dcoIndex
|Index of the DCO currently being defined. DCOs are stored within VI files sorted by this index.
|--
|[[U16 data type|U16]]
|ipCon
|
|--
|[[U8 data type|U8]]
|syncDisplay
|
|--
|[[U8 data type|U8]]
|extraUsed
|
|--
|[[U8 data type|U8]]
|flat
|
|--
|[[I8 data type|I8]]
|conNum
|
|--
|[[I32 data type|I32]]
|flagDSO
|[[Data Space]] Offset which is start of the data for the TypeDesc referenced by flagTMI.
|--
|[[I32 data type|I32]]
|flagTMI
|Type Map Index which references TypeDesc containing flags.
|--
|[[I32 data type|I32]]
|defaultDataTMI
|Type Map Index which references TypeDesc containing Default Data for the DCO.
|--
|[[I32 data type|I32]]
|extraDataTMI
|Type Map Index which references TypeDesc containing Extra Data associated with the DCO.
|--
|[[I32 data type|I32]]
|dsSz
|
|--
|[[U8 data type|U8]]
|ddoWriteCode
|
|--
|[[U8 data type|U8]]
|ddoNeedsSubVIStartup
|
|--
|[[U8 data type|U8]]
|isIndicator
|Boolean value which informs whether this DCO is a control or an indicator.
|--
|[[U8 data type|U8]]
|isScalar
|
|--
|[[I32 data type|I32]]
|defaultDataOffset
|Offset within the [[Data Space]] which is start of the data for the TypeDesc referenced by defaultDataTMI.
|--
|[[I32 data type|I32]]
|transferDataOffset
|
|--
|[[I32 data type|I32]]
|extraDataOffset
|
|--
|[[I32 data type|I32]]
|execDataPtrOffset
|
|--
|[[I32 data type|I32]]
|eltDsSz
|
|--
|[[U8 data type|U8]]
|copyReq
|
|--
|[[U8 data type|U8]]
|local
|
|--
|[[U8 data type|U8]]
|feo
|
|--
|[[U8 data type|U8]]
|nDims
|
|--
|[[U8 data type|U8]]
|copyProcIdx
|
|--
|[[U8 data type|U8]]
|copyFromRtnIdx
|
|--
|[[U8 data type|U8]]
|misclFlags
|
|--
|[[U8 data type|U8]]
|unusedFillerByte
|
|--
|[[I32 data type|I32]]
|subTypeDSO
|
|--
|4 x [[U8 data type|U8]]
|customCopyFromOffset
|
|--
|4 x [[U8 data type|U8]]
|customCopyToOffset
|
|--
|4 x [[U8 data type|U8]]
|customCopyOffset
|
|}

[[Category:LabVIEW internals]]

DCO

2020-06-18T09:26:29Z

Mefistotelis: cluster def

''DCO'' stands for '''Data Controller Object'''.
''DCO''s are related to control of data flow within [[VI|VI files]]. They can be attached to [[DDO]]s in both [[Front Panel]] and [[Block Diagram]].

Within [[VI|VI files]], ''DCO''s are stored as an array of [[Cluster]]s which is a part of [[Data Space]].

== DCO Cluster ==

Below are the [[Cluster]] fields which make up DCO within [[Data Space]].

{| class="wikitable"
! Data Type
! Field Name
! Description
|-
|[[I16 data type|I16]]
|dcoIndex
|
|--
|[[U16 data type|U16]]
|ipCon
|
|--
|[[U8 data type|U8]]
|syncDisplay
|
|--
|[[U8 data type|U8]]
|extraUsed
|
|--
|[[U8 data type|U8]]
|flat
|
|--
|[[I8 data type|I8]]
|conNum
|
|--
|[[I32 data type|I32]]
|flagDSO
|
|--
|[[I32 data type|I32]]
|flagTMI
|
|--
|[[I32 data type|I32]]
|defaultDataTMI
|
|--
|[[I32 data type|I32]]
|extraDataTMI
|
|--
|[[I32 data type|I32]]
|dsSz
|
|--
|[[U8 data type|U8]]
|ddoWriteCode
|
|--
|[[U8 data type|U8]]
|ddoNeedsSubVIStartup
|
|--
|[[U8 data type|U8]]
|isIndicator
|
|--
|[[U8 data type|U8]]
|isScalar
|
|--
|[[I32 data type|I32]]
|defaultDataOffset
|
|--
|[[I32 data type|I32]]
|transferDataOffset
|
|--
|[[I32 data type|I32]]
|extraDataOffset
|
|--
|[[I32 data type|I32]]
|execDataPtrOffset
|
|--
|[[I32 data type|I32]]
|eltDsSz
|
|--
|[[U8 data type|U8]]
|copyReq
|
|--
|[[U8 data type|U8]]
|local
|
|--
|[[U8 data type|U8]]
|feo
|
|--
|[[U8 data type|U8]]
|nDims
|
|--
|[[U8 data type|U8]]
|copyProcIdx
|
|--
|[[U8 data type|U8]]
|copyFromRtnIdx
|
|--
|[[U8 data type|U8]]
|misclFlags
|
|--
|[[U8 data type|U8]]
|unusedFillerByte
|
|--
|[[I32 data type|I32]]
|subTypeDSO
|
|--
|4 x [[U8 data type|U8]]
|customCopyFromOffset
|
|--
|4 x [[U8 data type|U8]]
|customCopyToOffset
|
|--
|4 x [[U8 data type|U8]]
|customCopyOffset
|
|}

[[Category:LabVIEW internals]]

DCO

2020-06-18T09:07:38Z

Mefistotelis: dco's within vi files

LabVIEW configuration file

2020-06-15T17:41:46Z

Mefistotelis: /* Configuration file location */

This article contains information related to the LabVIEW configuration file. This file is used by LabVIEW to store configuration information related to the LabVIEW development environment. If you are interested in finding out how to read and write your own [[Configuration file]] then see the article on the [[Configuration file|configuration file VIs]].

== Editing the LabVIEW configuration file - A disclaimer ==

The options that aren't in the preferences dialog are generally considered to be not useful or even harmful. They are sometimes there to allow National Instruments a backdoor or a workaround for when the LabVIEW development team changes a behavior. They are also used to turn on obscure development features that the developers use to make or debug LabVIEW. These obscure features are typically kind of like the attic or basement of a house, not finished out, not very interesting, and potentially harmful.

The LabVIEW developers have never tried to hide any of these strings, but it is unlikely that you will gain any benefit from trying out various combinations of the settings. If you ask technical support what a setting is, they will likely tell you that they have no idea. They are telling you the truth.

Even some of the folks in NI R&D may not know what some of the settings do without checking the code. Others, such as exoticcontrols, no longer do anything. It was once used to show a control palette submenu that contained controls that were still in work and not ready for prime-time. They were experiments, unsupported features, and guaranteed to crash if you did much with them. Just the sort of thing that is needed for development, but not useful to even advanced LabVIEW users unless they have a death-wish.

If you experiment with the .ini file and you crash mysteriously losing hours of work, I'd suggest putting the file back to the way LabVIEW left it. Don't ask tech support to fix it or complain that the LabVIEW attic has rusty nails and splinters.<br> Resedit is a low level tool that in the right hands is useful, in the wrong hands, well, its in the wrong hands. For the person that likes taking a multimeter and a soldering iron to computers and household appliances, its exactly what you always wanted. If you start monkeying with things in the resources or the .ini file, use common sense and do it on a copy or you will just end up reinstalling LabVIEW.

Once the fun and experimentation is over with, I think you will agree that the useful options, with very few exceptions are in the Preferences dialog.

== Configuration file location ==

Depending on your platform, location at which LV searches for options may vary:
* on Mac, use ''ResEdit''
* on Windows, edit text file `labview.ini` located in LV installation directory (where `LabVIEW.exe` is)
* on Linux, edit `/home/<username>/natinst/.config/LabVIEW-x/labview.conf`

== Settings Descriptions ==

This is a relatively comprehensive list of the settings that can be included in a labview.ini file (or a compiled executable's ini file). While some of these settings appear in the files by default, others may only appear when the features used require them to be there. Some settings can only be added manually to provide access to back door features and operations.

LabVIEW configuration keys are organized into the following categories (in alphabetical order):

*[[LabVIEW configuration file/Block Diagram|Block Diagram]]
*[[LabVIEW configuration file/Colors|Colors]]
*[[LabVIEW configuration file/Debugging|Debugging]]
*[[LabVIEW configuration file/Execution System|Execution System]]
*[[LabVIEW configuration file/Fonts|Fonts]]
*[[LabVIEW configuration file/Front Panel|Front Panel]]
*[[LabVIEW configuration file/Getting Started Window|Getting Started Window]]
*[[LabVIEW configuration file/History|History]]
*[[LabVIEW configuration file/Miscellaneous|Miscellaneous]]
*[[LabVIEW configuration file/Paths|Paths]]
*[[LabVIEW configuration file/Performance|Performance]]
*[[LabVIEW configuration file/Printing|Printing]]
*[[LabVIEW configuration file/Time and Date|Time and Date]]
*[[LabVIEW configuration file/VI Server|VI Server]]
*[[LabVIEW configuration file/Web Server|Web Server]]
*[[LabVIEW configuration file/Unknown|Uncategorized]] - Do you recognize any of these? Move them to the right place!
*[[LabVIEW configuration file/Easter Eggs|Easter Eggs]] - Reveal hidden messages and features (no functional advantage. Just for fun)

<br> '''Editor's Note:''' To add new configuration keys to any of the above pages, please use the [[Template:Labviewconfigurationkey|LabVIEW Configuration Key Template]]

----

== See Also ==

*[[Custom LabVIEW configuration file]]

== External Links ==

*[http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/customizing_your_work_environment/#How_LabVIEW_Stores_Options NI.com online help for LV configuration files]
*[http://sthmac.magnet.fsu.edu/labview/LVOptionsList.html Scott Hannahs's LabVIEW Info Page]

[[Category:Configuration File]]

CXT data type

2020-06-15T17:21:17Z

Mefistotelis: description

Complex Extended Float data type stores a [https://en.wikipedia.org/wiki/Complex_number Complex number] in which both real and imaginary components are of [[EXT data type]].

[[Category:Numeric data types]]

CDB data type

2020-06-15T17:20:52Z

Mefistotelis: description

Complex Double-precision Float data type stores a [https://en.wikipedia.org/wiki/Complex_number Complex number] in which both real and imaginary components are of [[DBL data type]].

[[Category:Numeric data types]]

DBL data type

2020-06-15T17:19:40Z

Mefistotelis: Undo revision 28369 by Mefistotelis (talk)

{{stub}}
Double-precision Float data type

[[Category:Numeric data types]]

DBL data type

2020-06-15T17:18:48Z

Mefistotelis: description

{{stub}}
Double-precision Float data type stores a [https://en.wikipedia.org/wiki/Complex_number Complex number] in which both real and imaginary components are of [[DBL data type]].

[[Category:Numeric data types]]

CSG data type

2020-06-15T17:17:48Z

Mefistotelis: proper description

Complex Single-precision Float data type stores a [https://en.wikipedia.org/wiki/Complex_number Complex number] in which both real and imaginary components are of [[SGL data type]].

[[Category:Numeric data types]]

CXT data type

2020-06-15T17:11:10Z

Mefistotelis: initial page

Complex Extended Float data type

[[Category:Numeric data types]]

Type descriptor

2020-06-15T17:10:46Z

Mefistotelis: lv naming in refs

'''Type descriptors''' are used to define [[Data type|data types]] in [[LabVIEW]]. Simplest types consist of only ''TypeDesc ID'', but more advanced ones have additional properties describing them. Compound types also contain references to the sub-types they include.

From the LabVIEW Help:

LabVIEW associates each wire and terminal on the block diagram with a data type. LabVIEW keeps track of this type with a structure in memory called a ''type descriptor''. This type descriptor is a sequence of 32-bit integers that can describe any data type in LabVIEW. Numeric values are written in hexadecimal format, unless otherwise noted.

'''Note:''' The help text above explain how ''Type descriptors'' are stored in memory when a [[VI|VI file]] is loaded. Their [[Flattening|flattened]] form conserves space and mostly uses values smaller than 32-bit.

== List of TD types ==

{| class="wikitable"
! TypeDesc ID
! Description
! Data Type
|-
|0x00
|Void type, stores no data
| [[Void data type]]
|-
|0x01
|Integer with signed 1 byte (8 bit) data
| [[I8 data type]]
|-
|0x02
|Integer with signed 2 byte (16 bit) data
| [[I16 data type]]
|-
|0x03
|Integer with signed 4 byte (32 bit) data
| [[I32 data type]]
|-
|0x04
|Integer with signed 8 byte (64 bit) data
| [[I64 data type]]
|-
|0x05
|Integer with unsigned 1 byte (8 bit) data
| [[U8 data type]]
|-
|0x06
|Integer with unsigned 2 byte (16 bit) data
| [[U16 data type]]
|-
|0x07
|Integer with unsigned 4 byte (32 bit) data
| [[U32 data type]]
|-
|0x08
|Integer with unsigned 8 byte (64 bit) data
| [[U64 data type]]
|-
|0x09
|Floating point with single precision 4 byte data
| [[SGL data type]]
|-
|0x0A
|Floating point with double precision 8 byte data
| [[DBL data type]]
|-
|0x0B
|Floating point with extended (quad precision) data
| [[EXT data type]]
|-
|0x0C
|Complex floating point with 8 byte data
| [[CSG data type]]
|-
|0x0D
|Complex floating point with 16 byte data
| [[CDB data type]]
|-
|0x0E
|Complex floating point with extended (quad precision) data
| [[CXT data type]]
|-
|0x15
|Enumerated UInt8
| [[Enum U8 data type]]
|-
|0x16
|Enumerated UInt16
| [[Enum U16 data type]]
|-
|0x17
|Enumerated UInt32
| [[Enum U32 data type]]
|-
|0x19
|Unit Float32
|
|-
|0x1A
|Unit Float64
|
|-
|0x1B
|Unit FloatExt
|
|-
|0x1C
|Unit Complex64
|
|-
|0x1D
|Unit Complex128
|
|-
|0x1E
|Unit ComplexExt
|
|-
|0x20
|Boolean value stored on 2 bytes (16 bit), rarely used
|
|-
|0x21
|Boolean value stored on 1 byte (8 bit)
| [[Boolean data type]]
|-
|0x30
|String value
| [[String data type]]
|-
|0x31
|Variation of String value, probably never used
|
|-
|0x32
|Path value, used for disk paths, sometimes for URLs
| [[Path data type]]
|-
|0x33
|Picture data
| [[Picture data type]]
|-
|0x34
|CString
|
|-
|0x35
|PasString
|
|-
|0x37
|Tag
|
|-
|0x3F
|SubString
|
|-
|0x40
|Array
|
|-
|0x41
|Array Data Ptr
|
|-
|0x4F
|SubArray
|
|-
|0x50
|Cluster, storing several sub-TDs in a sequence
| [[Cluster data type]]
|-
|0x53
|Variant data type
| [[Variant data type]]
|-
|0x54
|Measurement (Waveform) data; has [[Waveform descriptor|multiple sub-types]]
| [[Waveform data type]]
|-
|0x5E
|Complex fixed point number
|
|-
|0x5F
|Fixed point number
| [[Fixed-point data type]]
|-
|0x60
|Block
|
|-
|0x61
|Type block
|
|-
|0x62
|Void block
|
|-
|0x63
|Aligned block
|
|-
|0x64
|Repeated block, stores amount of repeats and one sub-TD to be repeated
|
|-
|0x65
|Alignment marker
|
|-
|0x70
|Refnum; has [[Refnum descriptor|multiple sub-types]], each with different set of properties
| [[Reference data type]]
|-
|0x80
|Ptr
|
|-
|0x83
|Ptr to
|
|-
|0x84
|Ext Data
|
|-
|0xA0
|Array interface
|
|-
|0xA1
|Interface to data
|
|-
|0xF0
|Function
|
|-
|0xF1
|TypeDef
|
|-
|0xF2
|PolyVI
|
|}

==External links==

*[http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/type_descriptors/ LabVIEW 8.2 Help>>Type Descriptors]
*[http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/how_labview_stores_data_in_memory/ LabVIEW 8.2 Help>>How LabVIEW Stores Data in Memory]

[[Category:LabVIEW internals]]
[[Category:Data types]]

CDB data type

2020-06-15T17:09:53Z

Mefistotelis: initial page

Complex Double-precision Float data type

[[Category:Numeric data types]]

CSG data type

2020-06-15T17:09:37Z

Mefistotelis: initial page

Complex Single-precision Float data type

[[Category:Numeric data types]]

Type descriptor

2020-06-15T17:09:15Z

Mefistotelis: lv naming in refs

'''Type descriptors''' are used to define [[Data type|data types]] in [[LabVIEW]]. Simplest types consist of only ''TypeDesc ID'', but more advanced ones have additional properties describing them. Compound types also contain references to the sub-types they include.

From the LabVIEW Help:

LabVIEW associates each wire and terminal on the block diagram with a data type. LabVIEW keeps track of this type with a structure in memory called a ''type descriptor''. This type descriptor is a sequence of 32-bit integers that can describe any data type in LabVIEW. Numeric values are written in hexadecimal format, unless otherwise noted.

'''Note:''' The help text above explain how ''Type descriptors'' are stored in memory when a [[VI|VI file]] is loaded. Their [[Flattening|flattened]] form conserves space and mostly uses values smaller than 32-bit.

== List of TD types ==

{| class="wikitable"
! TypeDesc ID
! Description
! Data Type
|-
|0x00
|Void type, stores no data
| [[Void data type]]
|-
|0x01
|Integer with signed 1 byte (8 bit) data
| [[I8 data type]]
|-
|0x02
|Integer with signed 2 byte (16 bit) data
| [[I16 data type]]
|-
|0x03
|Integer with signed 4 byte (32 bit) data
| [[I32 data type]]
|-
|0x04
|Integer with signed 8 byte (64 bit) data
| [[I64 data type]]
|-
|0x05
|Integer with unsigned 1 byte (8 bit) data
| [[U8 data type]]
|-
|0x06
|Integer with unsigned 2 byte (16 bit) data
| [[U16 data type]]
|-
|0x07
|Integer with unsigned 4 byte (32 bit) data
| [[U32 data type]]
|-
|0x08
|Integer with unsigned 8 byte (64 bit) data
| [[U64 data type]]
|-
|0x09
|Floating point with single precision 4 byte data
| [[SGL data type]]
|-
|0x0A
|Floating point with double precision 8 byte data
| [[DBL data type]]
|-
|0x0B
|Floating point with extended (quad precision) data
| [[EXT data type]]
|-
|0x0C
|Complex floating point with 8 byte data
| [[CSG data type]]
|-
|0x0D
|Complex floating point with 16 byte data
| [[CDB data type]]
|-
|0x0E
|Complex floating point with extended (quad precision) data
| [[Complex Extended Float data type]]
|-
|0x15
|Enumerated UInt8
| [[Enum U8 data type]]
|-
|0x16
|Enumerated UInt16
| [[Enum U16 data type]]
|-
|0x17
|Enumerated UInt32
| [[Enum U32 data type]]
|-
|0x19
|Unit Float32
|
|-
|0x1A
|Unit Float64
|
|-
|0x1B
|Unit FloatExt
|
|-
|0x1C
|Unit Complex64
|
|-
|0x1D
|Unit Complex128
|
|-
|0x1E
|Unit ComplexExt
|
|-
|0x20
|Boolean value stored on 2 bytes (16 bit), rarely used
|
|-
|0x21
|Boolean value stored on 1 byte (8 bit)
| [[Boolean data type]]
|-
|0x30
|String value
| [[String data type]]
|-
|0x31
|Variation of String value, probably never used
|
|-
|0x32
|Path value, used for disk paths, sometimes for URLs
| [[Path data type]]
|-
|0x33
|Picture data
| [[Picture data type]]
|-
|0x34
|CString
|
|-
|0x35
|PasString
|
|-
|0x37
|Tag
|
|-
|0x3F
|SubString
|
|-
|0x40
|Array
|
|-
|0x41
|Array Data Ptr
|
|-
|0x4F
|SubArray
|
|-
|0x50
|Cluster, storing several sub-TDs in a sequence
| [[Cluster data type]]
|-
|0x53
|Variant data type
| [[Variant data type]]
|-
|0x54
|Measurement (Waveform) data; has [[Waveform descriptor|multiple sub-types]]
| [[Waveform data type]]
|-
|0x5E
|Complex fixed point number
|
|-
|0x5F
|Fixed point number
| [[Fixed-point data type]]
|-
|0x60
|Block
|
|-
|0x61
|Type block
|
|-
|0x62
|Void block
|
|-
|0x63
|Aligned block
|
|-
|0x64
|Repeated block, stores amount of repeats and one sub-TD to be repeated
|
|-
|0x65
|Alignment marker
|
|-
|0x70
|Refnum; has [[Refnum descriptor|multiple sub-types]], each with different set of properties
| [[Reference data type]]
|-
|0x80
|Ptr
|
|-
|0x83
|Ptr to
|
|-
|0x84
|Ext Data
|
|-
|0xA0
|Array interface
|
|-
|0xA1
|Interface to data
|
|-
|0xF0
|Function
|
|-
|0xF1
|TypeDef
|
|-
|0xF2
|PolyVI
|
|}

==External links==

*[http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/type_descriptors/ LabVIEW 8.2 Help>>Type Descriptors]
*[http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/how_labview_stores_data_in_memory/ LabVIEW 8.2 Help>>How LabVIEW Stores Data in Memory]

[[Category:LabVIEW internals]]
[[Category:Data types]]

EXT data type

2020-06-15T17:07:50Z

Mefistotelis: initial page

Extended precision (Quad precision) Float data type

[[Category:Numeric data types]]

Type descriptor

2020-06-15T17:07:05Z

Mefistotelis: lv naming in refs

'''Type descriptors''' are used to define [[Data type|data types]] in [[LabVIEW]]. Simplest types consist of only ''TypeDesc ID'', but more advanced ones have additional properties describing them. Compound types also contain references to the sub-types they include.

From the LabVIEW Help:

LabVIEW associates each wire and terminal on the block diagram with a data type. LabVIEW keeps track of this type with a structure in memory called a ''type descriptor''. This type descriptor is a sequence of 32-bit integers that can describe any data type in LabVIEW. Numeric values are written in hexadecimal format, unless otherwise noted.

'''Note:''' The help text above explain how ''Type descriptors'' are stored in memory when a [[VI|VI file]] is loaded. Their [[Flattening|flattened]] form conserves space and mostly uses values smaller than 32-bit.

== List of TD types ==

{| class="wikitable"
! TypeDesc ID
! Description
! Data Type
|-
|0x00
|Void type, stores no data
| [[Void data type]]
|-
|0x01
|Integer with signed 1 byte (8 bit) data
| [[I8 data type]]
|-
|0x02
|Integer with signed 2 byte (16 bit) data
| [[I16 data type]]
|-
|0x03
|Integer with signed 4 byte (32 bit) data
| [[I32 data type]]
|-
|0x04
|Integer with signed 8 byte (64 bit) data
| [[I64 data type]]
|-
|0x05
|Integer with unsigned 1 byte (8 bit) data
| [[U8 data type]]
|-
|0x06
|Integer with unsigned 2 byte (16 bit) data
| [[U16 data type]]
|-
|0x07
|Integer with unsigned 4 byte (32 bit) data
| [[U32 data type]]
|-
|0x08
|Integer with unsigned 8 byte (64 bit) data
| [[U64 data type]]
|-
|0x09
|Floating point with single precision 4 byte data
| [[SGL data type]]
|-
|0x0A
|Floating point with double precision 8 byte data
| [[DBL data type]]
|-
|0x0B
|Floating point with extended (quad precision) data
| [[EXT data type]]
|-
|0x0C
|Complex floating point with 8 byte data
| [[Complex Single Float data type]]
|-
|0x0D
|Complex floating point with 16 byte data
| [[Complex Double Float data type]]
|-
|0x0E
|Complex floating point with extended (quad precision) data
| [[Complex Extended Float data type]]
|-
|0x15
|Enumerated UInt8
| [[Enum U8 data type]]
|-
|0x16
|Enumerated UInt16
| [[Enum U16 data type]]
|-
|0x17
|Enumerated UInt32
| [[Enum U32 data type]]
|-
|0x19
|Unit Float32
|
|-
|0x1A
|Unit Float64
|
|-
|0x1B
|Unit FloatExt
|
|-
|0x1C
|Unit Complex64
|
|-
|0x1D
|Unit Complex128
|
|-
|0x1E
|Unit ComplexExt
|
|-
|0x20
|Boolean value stored on 2 bytes (16 bit), rarely used
|
|-
|0x21
|Boolean value stored on 1 byte (8 bit)
| [[Boolean data type]]
|-
|0x30
|String value
| [[String data type]]
|-
|0x31
|Variation of String value, probably never used
|
|-
|0x32
|Path value, used for disk paths, sometimes for URLs
| [[Path data type]]
|-
|0x33
|Picture data
| [[Picture data type]]
|-
|0x34
|CString
|
|-
|0x35
|PasString
|
|-
|0x37
|Tag
|
|-
|0x3F
|SubString
|
|-
|0x40
|Array
|
|-
|0x41
|Array Data Ptr
|
|-
|0x4F
|SubArray
|
|-
|0x50
|Cluster, storing several sub-TDs in a sequence
| [[Cluster data type]]
|-
|0x53
|Variant data type
| [[Variant data type]]
|-
|0x54
|Measurement (Waveform) data; has [[Waveform descriptor|multiple sub-types]]
| [[Waveform data type]]
|-
|0x5E
|Complex fixed point number
|
|-
|0x5F
|Fixed point number
| [[Fixed-point data type]]
|-
|0x60
|Block
|
|-
|0x61
|Type block
|
|-
|0x62
|Void block
|
|-
|0x63
|Aligned block
|
|-
|0x64
|Repeated block, stores amount of repeats and one sub-TD to be repeated
|
|-
|0x65
|Alignment marker
|
|-
|0x70
|Refnum; has [[Refnum descriptor|multiple sub-types]], each with different set of properties
| [[Reference data type]]
|-
|0x80
|Ptr
|
|-
|0x83
|Ptr to
|
|-
|0x84
|Ext Data
|
|-
|0xA0
|Array interface
|
|-
|0xA1
|Interface to data
|
|-
|0xF0
|Function
|
|-
|0xF1
|TypeDef
|
|-
|0xF2
|PolyVI
|
|}

==External links==

*[http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/type_descriptors/ LabVIEW 8.2 Help>>Type Descriptors]
*[http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/how_labview_stores_data_in_memory/ LabVIEW 8.2 Help>>How LabVIEW Stores Data in Memory]

[[Category:LabVIEW internals]]
[[Category:Data types]]

Waveform descriptor

2020-06-15T17:05:11Z

Mefistotelis: /* List of Waveform types */

'''Waveform descriptor''' is a kind of [[type descriptor]] which stores properties of [[Waveform data type]].

== List of Waveform types ==

The following table lists the sub-type codes used in the [[type descriptor]] of the [[Waveform data type]].

{| class="wikitable"
|-
! Sub-Type Code
! Description
! Waveform Type
|-
| 0x01
| Old Float64 Waveform
| [[WDT data type]]
|-
| 0x02
| Int16 Waveform
| [[I16 Waveform data type]]
|-
| 0x03
| Float64 Waveform
| [[DBL Waveform data type]]
|-
| 0x05
| Float32 Waveform
| [[SGL Waveform data type]]
|-
| 0x06
| TimeStamp
| [[Timestamp data type]]
|-
| 0x07
| Digital data
| [[Digital Data data type]]
|-
| 0x08
| Digital Waveform
| [[Digital Waveform data type]]
|-
| 0x09
| Dynamic data
| [[Dynamic Data data type]]
|-
| 0x0a
| FloatExt Waveform
| [[EXT Waveform data type]]
|-
| 0x0b
| UInt8 Waveform
| [[U8 Waveform data type]]
|-
| 0x0c
| UInt16 Waveform
| [[U16 Waveform data type]]
|-
| 0x0d
| UInt32 Waveform
| [[U32 Waveform data type]]
|-
| 0x0e
| Int8 Waveform
| [[I8 Waveform data type]]
|-
| 0x0f
| Int32 Waveform
| [[I32 Waveform data type]]
|-
| 0x10
| Complex64 Waveform
| [[CSG Waveform data type]]
|-
| 0x11
| Complex128 Waveform
| [[CDB Waveform data type]]
|-
| 0x12
| ComplexExt Waveform
| [[CXT Waveform data type]]
|-
| 0x13
| Int64 Waveform
| [[I64 Waveform data type]]
|-
| 0x14
| UInt64 Waveform
| [[U64 Waveform data type]]
|}

==See Also==
*[[type descriptor]]

[[Category:LabVIEW internals]]
[[Category:Data types]]

DBL data type

2020-06-15T17:00:22Z

Mefistotelis: description

{{stub}}
Double-precision Float data type

[[Category:Numeric data types]]

Double Float data type

2020-06-15T16:59:55Z

Mefistotelis: Mefistotelis moved page Double Float data type to DBL data type: lv naming

#REDIRECT [[DBL data type]]

DBL data type

2020-06-15T16:59:55Z

Mefistotelis: Mefistotelis moved page Double Float data type to DBL data type: lv naming

{{stub}}

[[Category:Numeric data types]]

Type descriptor

2020-06-15T16:59:20Z

Mefistotelis: lv naming in refs

'''Type descriptors''' are used to define [[Data type|data types]] in [[LabVIEW]]. Simplest types consist of only ''TypeDesc ID'', but more advanced ones have additional properties describing them. Compound types also contain references to the sub-types they include.

From the LabVIEW Help:

LabVIEW associates each wire and terminal on the block diagram with a data type. LabVIEW keeps track of this type with a structure in memory called a ''type descriptor''. This type descriptor is a sequence of 32-bit integers that can describe any data type in LabVIEW. Numeric values are written in hexadecimal format, unless otherwise noted.

'''Note:''' The help text above explain how ''Type descriptors'' are stored in memory when a [[VI|VI file]] is loaded. Their [[Flattening|flattened]] form conserves space and mostly uses values smaller than 32-bit.

== List of TD types ==

{| class="wikitable"
! TypeDesc ID
! Description
! Data Type
|-
|0x00
|Void type, stores no data
| [[Void data type]]
|-
|0x01
|Integer with signed 1 byte (8 bit) data
| [[I8 data type]]
|-
|0x02
|Integer with signed 2 byte (16 bit) data
| [[I16 data type]]
|-
|0x03
|Integer with signed 4 byte (32 bit) data
| [[I32 data type]]
|-
|0x04
|Integer with signed 8 byte (64 bit) data
| [[I64 data type]]
|-
|0x05
|Integer with unsigned 1 byte (8 bit) data
| [[U8 data type]]
|-
|0x06
|Integer with unsigned 2 byte (16 bit) data
| [[U16 data type]]
|-
|0x07
|Integer with unsigned 4 byte (32 bit) data
| [[U32 data type]]
|-
|0x08
|Integer with unsigned 8 byte (64 bit) data
| [[U64 data type]]
|-
|0x09
|Floating point with single precision 4 byte data
| [[SGL data type]]
|-
|0x0A
|Floating point with double precision 8 byte data
| [[DBL data type]]
|-
|0x0B
|Floating point with extended (quad precision) data
| [[Extended Float data type]]
|-
|0x0C
|Complex floating point with 8 byte data
| [[Complex Single Float data type]]
|-
|0x0D
|Complex floating point with 16 byte data
| [[Complex Double Float data type]]
|-
|0x0E
|Complex floating point with extended (quad precision) data
| [[Complex Extended Float data type]]
|-
|0x15
|Enumerated UInt8
| [[Enum U8 data type]]
|-
|0x16
|Enumerated UInt16
| [[Enum U16 data type]]
|-
|0x17
|Enumerated UInt32
| [[Enum U32 data type]]
|-
|0x19
|Unit Float32
|
|-
|0x1A
|Unit Float64
|
|-
|0x1B
|Unit FloatExt
|
|-
|0x1C
|Unit Complex64
|
|-
|0x1D
|Unit Complex128
|
|-
|0x1E
|Unit ComplexExt
|
|-
|0x20
|Boolean value stored on 2 bytes (16 bit), rarely used
|
|-
|0x21
|Boolean value stored on 1 byte (8 bit)
| [[Boolean data type]]
|-
|0x30
|String value
| [[String data type]]
|-
|0x31
|Variation of String value, probably never used
|
|-
|0x32
|Path value, used for disk paths, sometimes for URLs
| [[Path data type]]
|-
|0x33
|Picture data
| [[Picture data type]]
|-
|0x34
|CString
|
|-
|0x35
|PasString
|
|-
|0x37
|Tag
|
|-
|0x3F
|SubString
|
|-
|0x40
|Array
|
|-
|0x41
|Array Data Ptr
|
|-
|0x4F
|SubArray
|
|-
|0x50
|Cluster, storing several sub-TDs in a sequence
| [[Cluster data type]]
|-
|0x53
|Variant data type
| [[Variant data type]]
|-
|0x54
|Measurement (Waveform) data; has [[Waveform descriptor|multiple sub-types]]
| [[Waveform data type]]
|-
|0x5E
|Complex fixed point number
|
|-
|0x5F
|Fixed point number
| [[Fixed-point data type]]
|-
|0x60
|Block
|
|-
|0x61
|Type block
|
|-
|0x62
|Void block
|
|-
|0x63
|Aligned block
|
|-
|0x64
|Repeated block, stores amount of repeats and one sub-TD to be repeated
|
|-
|0x65
|Alignment marker
|
|-
|0x70
|Refnum; has [[Refnum descriptor|multiple sub-types]], each with different set of properties
| [[Reference data type]]
|-
|0x80
|Ptr
|
|-
|0x83
|Ptr to
|
|-
|0x84
|Ext Data
|
|-
|0xA0
|Array interface
|
|-
|0xA1
|Interface to data
|
|-
|0xF0
|Function
|
|-
|0xF1
|TypeDef
|
|-
|0xF2
|PolyVI
|
|}

==External links==

*[http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/type_descriptors/ LabVIEW 8.2 Help>>Type Descriptors]
*[http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/how_labview_stores_data_in_memory/ LabVIEW 8.2 Help>>How LabVIEW Stores Data in Memory]

[[Category:LabVIEW internals]]
[[Category:Data types]]

SGL data type

2020-06-15T16:57:08Z

Mefistotelis: description

{{stub}}

Single-precision Float data type.

[[Category:Numeric data types]]

Single Float data type

2020-06-15T16:56:26Z

Mefistotelis: Mefistotelis moved page Single Float data type to SGL data type: lv naming

#REDIRECT [[SGL data type]]

SGL data type

2020-06-15T16:56:26Z

Mefistotelis: Mefistotelis moved page Single Float data type to SGL data type: lv naming

{{stub}}

[[Category:Numeric data types]]

Waveform descriptor

2020-06-15T16:48:11Z

Mefistotelis: category

Waveform descriptor

2020-06-15T16:42:41Z

Mefistotelis: /* List of Waveform types */

Waveform descriptor

2020-06-15T16:41:17Z

Mefistotelis: /* List of Waveform types */

Waveform descriptor

2020-06-15T16:39:46Z

Mefistotelis: /* List of Refnum types */

Waveform descriptor

2020-06-15T16:39:16Z

Mefistotelis: /* List of Refnum types */

'''Waveform descriptor''' is a kind of [[type descriptor]] which stores properties of [[Waveform data type]].

== List of Refnum types ==

The following table lists the sub-type codes used in the [[type descriptor]] of the [[Waveform data type]].

{| class="wikitable"
|-
! Sub-Type Code
! Waveform Type
! Description
|-
| 0x01
| Old Float64 Waveform
|
|-
| 0x03
| Float64 Waveform
|
|-
| 0x05
| Float32 Waveform
|
|-
| 0x06
| TimeStamp
|
|-
| 0x07
| Digital data
|
|-
| 0x08
| Digital Waveform
|
|-
| 0x09
| Dynamic data
|
|-
| 0x0a
| FloatExt Waveform
|
|-
| 0x0b
| UInt8 Waveform
|
|-
| 0x0c
| UInt16 Waveform
|
|-
| 0x13
| Int64 Waveform
|
|-
| 0x14
| UInt64 Waveform
|
|}

==See Also==
*[[type descriptor]]

Waveform descriptor

2020-06-15T16:37:33Z

Mefistotelis: initial page

'''Waveform descriptor''' is a kind of [[type descriptor]] which stores properties of [[Waveform data type]].

== List of Refnum types ==

The following table lists the sub-type codes used in the [[type descriptor]] of the [[Waveform data type]].

{| class="wikitable"
|-
! Sub-Type Code
! Waveform Type
! Description
|-
| 0x01
| Old Float64 Waveform
|
|-
| 0x03
| Float64 Waveform
|
|-
| 0x05
| Float32 Waveform
|
|-
| 0x06
| TimeStamp
|
|-
| 0x07
| Digital data
|
|-
| 0x08
| Digital Waveform
|
|-
| 0x14
| UInt64 Waveform
|
|}

==See Also==
*[[type descriptor]]

Type descriptor

2020-06-15T16:33:29Z

Mefistotelis: waveform descriptors ref

'''Type descriptors''' are used to define [[Data type|data types]] in [[LabVIEW]]. Simplest types consist of only ''TypeDesc ID'', but more advanced ones have additional properties describing them. Compound types also contain references to the sub-types they include.

From the LabVIEW Help:

LabVIEW associates each wire and terminal on the block diagram with a data type. LabVIEW keeps track of this type with a structure in memory called a ''type descriptor''. This type descriptor is a sequence of 32-bit integers that can describe any data type in LabVIEW. Numeric values are written in hexadecimal format, unless otherwise noted.

'''Note:''' The help text above explain how ''Type descriptors'' are stored in memory when a [[VI|VI file]] is loaded. Their [[Flattening|flattened]] form conserves space and mostly uses values smaller than 32-bit.

== List of TD types ==

{| class="wikitable"
! TypeDesc ID
! Description
! Data Type
|-
|0x00
|Void type, stores no data
| [[Void data type]]
|-
|0x01
|Integer with signed 1 byte (8 bit) data
| [[I8 data type]]
|-
|0x02
|Integer with signed 2 byte (16 bit) data
| [[I16 data type]]
|-
|0x03
|Integer with signed 4 byte (32 bit) data
| [[I32 data type]]
|-
|0x04
|Integer with signed 8 byte (64 bit) data
| [[I64 data type]]
|-
|0x05
|Integer with unsigned 1 byte (8 bit) data
| [[U8 data type]]
|-
|0x06
|Integer with unsigned 2 byte (16 bit) data
| [[U16 data type]]
|-
|0x07
|Integer with unsigned 4 byte (32 bit) data
| [[U32 data type]]
|-
|0x08
|Integer with unsigned 8 byte (64 bit) data
| [[U64 data type]]
|-
|0x09
|Floating point with single precision 4 byte data
| [[Single Float data type]]
|-
|0x0A
|Floating point with double precision 8 byte data
| [[Double Float data type]]
|-
|0x0B
|Floating point with extended (quad precision) data
| [[Extended Float data type]]
|-
|0x0C
|Complex floating point with 8 byte data
| [[Complex Single Float data type]]
|-
|0x0D
|Complex floating point with 16 byte data
| [[Complex Double Float data type]]
|-
|0x0E
|Complex floating point with extended (quad precision) data
| [[Complex Extended Float data type]]
|-
|0x15
|Enumerated UInt8
| [[Enum U8 data type]]
|-
|0x16
|Enumerated UInt16
| [[Enum U16 data type]]
|-
|0x17
|Enumerated UInt32
| [[Enum U32 data type]]
|-
|0x19
|Unit Float32
|
|-
|0x1A
|Unit Float64
|
|-
|0x1B
|Unit FloatExt
|
|-
|0x1C
|Unit Complex64
|
|-
|0x1D
|Unit Complex128
|
|-
|0x1E
|Unit ComplexExt
|
|-
|0x20
|Boolean value stored on 2 bytes (16 bit), rarely used
|
|-
|0x21
|Boolean value stored on 1 byte (8 bit)
| [[Boolean data type]]
|-
|0x30
|String value
| [[String data type]]
|-
|0x31
|Variation of String value, probably never used
|
|-
|0x32
|Path value, used for disk paths, sometimes for URLs
| [[Path data type]]
|-
|0x33
|Picture data
| [[Picture data type]]
|-
|0x34
|CString
|
|-
|0x35
|PasString
|
|-
|0x37
|Tag
|
|-
|0x3F
|SubString
|
|-
|0x40
|Array
|
|-
|0x41
|Array Data Ptr
|
|-
|0x4F
|SubArray
|
|-
|0x50
|Cluster, storing several sub-TDs in a sequence
| [[Cluster data type]]
|-
|0x53
|Variant data type
| [[Variant data type]]
|-
|0x54
|Measurement (Waveform) data; has [[Waveform descriptor|multiple sub-types]]
| [[Waveform data type]]
|-
|0x5E
|Complex fixed point number
|
|-
|0x5F
|Fixed point number
| [[Fixed-point data type]]
|-
|0x60
|Block
|
|-
|0x61
|Type block
|
|-
|0x62
|Void block
|
|-
|0x63
|Aligned block
|
|-
|0x64
|Repeated block, stores amount of repeats and one sub-TD to be repeated
|
|-
|0x65
|Alignment marker
|
|-
|0x70
|Refnum; has [[Refnum descriptor|multiple sub-types]], each with different set of properties
| [[Reference data type]]
|-
|0x80
|Ptr
|
|-
|0x83
|Ptr to
|
|-
|0x84
|Ext Data
|
|-
|0xA0
|Array interface
|
|-
|0xA1
|Interface to data
|
|-
|0xF0
|Function
|
|-
|0xF1
|TypeDef
|
|-
|0xF2
|PolyVI
|
|}

==External links==

*[http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/type_descriptors/ LabVIEW 8.2 Help>>Type Descriptors]
*[http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/how_labview_stores_data_in_memory/ LabVIEW 8.2 Help>>How LabVIEW Stores Data in Memory]

[[Category:LabVIEW internals]]
[[Category:Data types]]

Insane Objects

2020-06-15T16:25:39Z

Mefistotelis: lv internals ref fix

All objects within [[LabVIEW]], have a self-verification mechanism, which makes each object able to audit whether its internal state is within expected bounds set by LV developers. On specific operations, LabVIEW triggers that sanity check on objects. If any object fails the verification, it is marked as Insane.

For example, if a connection-related object has ''state'' set to connected, but the underlying connection reference is ''NULL'' - the object will fail its sanity test. Another example might be an object which flags suggest it is compiled properly and there was no ''source code'' change which would require re-compilation, but the related machine code references objects which were removed.

The insane object message is what LabVIEW puts in a dialog when one of the objects on the diagram does not meet its consistency test. In other words, this object isn't in a state LabVIEW expects it to be in. Most of the time these errors are not fatal -- LabVIEW simply puts the object in the state it does expect. But it raises questions about how the object got into that bad state and what might have been done with that object between the last time LabVIEW checked and it was good and the time it became insane.

== Reporting bugs ==

There is no need to necessarily report generically to [[NI]] that LabVIEW has insane objects; it is a mechanism which developers intentionally introduced. These are NOT merely bugs: insane objects can be generated as part of the LabVIEW internal verification process.

If you get a message about insane object, it is good to check the known bugs of LabVIEW at ni.com, and if the particular insanity in your dialog is not listed, only then should you report the insanity to NI technical support. As always in such cases, it is important to describe the situation which lead to the insane object appearing.

The insane object messages are something NI works on with each version of LabVIEW. But as it is a generic error message that can apply to anything from a simple cosmetic to the [[Front Panel]] itself, you'll still see them in any version of LabVIEW that has a bug -- a fact of life unfortunately for the foreseeable future.

== The displayed message ==

An example of the insanity message may be:

'''''Insane object at FPHP+4C in "name.vi": {dsitem} 0x400: Panel (FPSC)'''''

The cryptic nature of the message can be deciphered as follows:
* FPHP -- this will be either FP or BD for "front panel heap" or "block diagram heap"
* 4C -- this is a hexadecimal number indicating which object.
* name.vi -- which [[VI]] had the insanity
* {dsitem} 0x400 -- really only meaningful if you know how [[:Category:LabVIEW_internals|LabVIEW internals]] work; in this example it is [[Data Space]] item identification
* Panel (FPSC) -- the type of object that has problems. The four letter codes are usually descriptive (COSM for a cosmetic or simple drawn part, SGNL for a signal aka wire). A common one that you won't guess is DDOD, which stands for [[DDO|Data Display Object]] (the last D is because it has to be 4 chars).

Most of the time, deleting the offending object and recreating it from scratch is sufficient to fix your VI and allow you to continue working.

== Using Heap Peek ==

There is a way to find and delete an insane object. When you get an insane error, you will get a code that identifies the object that is insane - write down that code. For example in the section above, the number "4C" is the number that tells you which object is the culprit.

After you have the number, [[Heap_Peek#Enabling_Heap_Peek|enable and invoke Heap Peek window]] with your VI opened (instruction is in the link).

The window is divided into several sections. The functionality of the various parts is obscure and mystical; you can read more about it on the [[Heap Peek|Heap Peek page]]. We're just going to focus on the bits that help with finding and deleting insane objects.

* Check the error message given about the insane object. It includes either the letters ''BDHP'' or ''FPHP''. Scroll through the top-left list box until you find those 4 letters and the name of your VI. Left click to select that item. This will change what is displayed in the top-right section of the window.
* In the top-right section, find the line that begins with the number identifying the object. These are sorted numerically. Left click to select the object when you find it.
* In the middle region, there is a box with an F inside it. This is a button (heap peek doesn't use a lot of advanced drawing, so it doesn't really look like a button, but it is). Click on the F button to find the offending object.
* LabVIEW will switch to the block diagram or front panel and select some object. Whatever object it is, delete it.

'''Note:''' [[Heap Peek]] does not have any ability to change the objects. It is display information only. There are VIs in LV that are not real VIs (for example, a pseudo VI that is created to represent a Call By Reference to another application instance on another machine), and attempting to do Find to jump to their components can cause problems because those VIs never expect to actually draw themselves. But other than that state change, there are no edits to VIs possible using this tool as of November 2007.

== See also ==
* [[Heap Peek]]

[[Category:LabVIEW internals]]
[[Category:Development Environment]]

Insane Objects

2020-06-15T16:17:47Z

Mefistotelis: more refs

All objects within [[LabVIEW]], have a self-verification mechanism, which makes each object able to audit whether its internal state is within expected bounds set by LV developers. On specific operations, LabVIEW triggers that sanity check on objects. If any object fails the verification, it is marked as Insane.

For example, if a connection-related object has ''state'' set to connected, but the underlying connection reference is ''NULL'' - the object will fail its sanity test. Another example might be an object which flags suggest it is compiled properly and there was no ''source code'' change which would require re-compilation, but the related machine code references objects which were removed.

The insane object message is what LabVIEW puts in a dialog when one of the objects on the diagram does not meet its consistency test. In other words, this object isn't in a state LabVIEW expects it to be in. Most of the time these errors are not fatal -- LabVIEW simply puts the object in the state it does expect. But it raises questions about how the object got into that bad state and what might have been done with that object between the last time LabVIEW checked and it was good and the time it became insane.

== Reporting bugs ==

There is no need to necessarily report generically to [[NI]] that LabVIEW has insane objects; it is a mechanism which developers intentionally introduced. These are NOT merely bugs: insane objects can be generated as part of the LabVIEW internal verification process.

If you get a message about insane object, it is good to check the known bugs of LabVIEW at ni.com, and if the particular insanity in your dialog is not listed, only then should you report the insanity to NI technical support. As always in such cases, it is important to describe the situation which lead to the insane object appearing.

The insane object messages are something NI works on with each version of LabVIEW. But as it is a generic error message that can apply to anything from a simple cosmetic to the [[Front Panel]] itself, you'll still see them in any version of LabVIEW that has a bug -- a fact of life unfortunately for the foreseeable future.

== The displayed message ==

An example of the insanity message may be:

'''''Insane object at FPHP+4C in "name.vi": {dsitem} 0x400: Panel (FPSC)'''''

The cryptic nature of the message can be deciphered as follows:
* FPHP -- this will be either FP or BD for "front panel heap" or "block diagram heap"
* 4C -- this is a hexadecimal number indicating which object.
* name.vi -- which [[VI]] had the insanity
* {dsitem} 0x400 -- really only meaningful if you know how [[LabVIEW internals]] work; in this example it is [[Data Space]] item identification
* Panel (FPSC) -- the type of object that has problems. The four letter codes are usually descriptive (COSM for a cosmetic or simple drawn part, SGNL for a signal aka wire). A common one that you won't guess is DDOD, which stands for [[DDO|Data Display Object]] (the last D is because it has to be 4 chars).

Most of the time, deleting the offending object and recreating it from scratch is sufficient to fix your VI and allow you to continue working.

== Using Heap Peek ==

There is a way to find and delete an insane object. When you get an insane error, you will get a code that identifies the object that is insane - write down that code. For example in the section above, the number "4C" is the number that tells you which object is the culprit.

After you have the number, [[Heap_Peek#Enabling_Heap_Peek|enable and invoke Heap Peek window]] with your VI opened (instruction is in the link).

The window is divided into several sections. The functionality of the various parts is obscure and mystical; you can read more about it on the [[Heap Peek|Heap Peek page]]. We're just going to focus on the bits that help with finding and deleting insane objects.

* Check the error message given about the insane object. It includes either the letters ''BDHP'' or ''FPHP''. Scroll through the top-left list box until you find those 4 letters and the name of your VI. Left click to select that item. This will change what is displayed in the top-right section of the window.
* In the top-right section, find the line that begins with the number identifying the object. These are sorted numerically. Left click to select the object when you find it.
* In the middle region, there is a box with an F inside it. This is a button (heap peek doesn't use a lot of advanced drawing, so it doesn't really look like a button, but it is). Click on the F button to find the offending object.
* LabVIEW will switch to the block diagram or front panel and select some object. Whatever object it is, delete it.

'''Note:''' [[Heap Peek]] does not have any ability to change the objects. It is display information only. There are VIs in LV that are not real VIs (for example, a pseudo VI that is created to represent a Call By Reference to another application instance on another machine), and attempting to do Find to jump to their components can cause problems because those VIs never expect to actually draw themselves. But other than that state change, there are no edits to VIs possible using this tool as of November 2007.

== See also ==
* [[Heap Peek]]

[[Category:LabVIEW internals]]
[[Category:Development Environment]]

Insane Objects

2020-06-10T23:22:40Z

Mefistotelis: /* The displayed message */

All objects within [[LabVIEW]], have a self-verification mechanism, which makes each object able to audit whether its internal state is within expected bounds set by LV developers. On specific operations, LabVIEW triggers that sanity check on objects. If any object fails the verification, it is marked as Insane.

For example, if a connection-related object has ''state'' set to connected, but the underlying connection reference is ''NULL'' - the object will fail its sanity test. Another example might be an object which flags suggest it is compiled properly and there was no ''source code'' change which would require re-compilation, but the related machine code references objects which were removed.

The insane object message is what LabVIEW puts in a dialog when one of the objects on the diagram does not meet its consistency test. In other words, this object isn't in a state LabVIEW expects it to be in. Most of the time these errors are not fatal -- LabVIEW simply puts the object in the state it does expect. But it raises questions about how the object got into that bad state and what might have been done with that object between the last time LabVIEW checked and it was good and the time it became insane.

== Reporting bugs ==

There is no need to necessarily report generically to [[NI]] that LabVIEW has insane objects; it is a mechanism which developers intentionally introduced. These are NOT merely bugs: insane objects can be generated as part of the LabVIEW internal verification process.

If you get a message about insane object, it is good to check the known bugs of LabVIEW at ni.com, and if the particular insanity in your dialog is not listed, only then should you report the insanity to NI technical support. As always in such cases, it is important to describe the situation which lead to the insane object appearing.

The insane object messages are something NI works on with each version of LabVIEW. But as it is a generic error message that can apply to anything from a simple cosmetic to the [[Front Panel]] itself, you'll still see them in any version of LabVIEW that has a bug -- a fact of life unfortunately for the foreseeable future.

== The displayed message ==

An example of the insanity message may be:

'''''Insane object at FPHP+4C in "name.vi": {dsitem} 0x400: Panel (FPSC)'''''

The cryptic nature of the message can be deciphered as follows:
* FPHP -- this will be either FP or BD for "front panel heap" or "block diagram heap"
* 4C -- this is a hexadecimal number indicating which object.
* name.vi -- which [[VI]] had the insanity
* {dsitem} 0x400 -- really only meaningful if you know how LabVIEW internals work; I'll skip it here
* Panel (FPSC) -- the type of object that has problems. The four letter codes are usually descriptive (COSM for a cosmetic or simple drawn part, SGNL for a signal aka wire). A common one that you won't guess is DDOD, which stands for Data Display Object (the last D is because it has to be 4 chars). A DDO is either a control or an indicator.

Most of the time, deleting the offending object and recreating it from scratch is sufficient to fix your VI and allow you to continue working.

== Using Heap Peek ==

There is a way to find and delete an insane object. When you get an insane error, you will get a code that identifies the object that is insane - write down that code. For example in the section above, the number "4C" is the number that tells you which object is the culprit.

After you have the number, [[Heap_Peek#Enabling_Heap_Peek|enable and invoke Heap Peek window]] with your VI opened (instruction is in the link).

The window is divided into several sections. The functionality of the various parts is obscure and mystical; you can read more about it on the [[Heap Peek|Heap Peek page]]. We're just going to focus on the bits that help with finding and deleting insane objects.

* Check the error message given about the insane object. It includes either the letters ''BDHP'' or ''FPHP''. Scroll through the top-left list box until you find those 4 letters and the name of your VI. Left click to select that item. This will change what is displayed in the top-right section of the window.
* In the top-right section, find the line that begins with the number identifying the object. These are sorted numerically. Left click to select the object when you find it.
* In the middle region, there is a box with an F inside it. This is a button (heap peek doesn't use a lot of advanced drawing, so it doesn't really look like a button, but it is). Click on the F button to find the offending object.
* LabVIEW will switch to the block diagram or front panel and select some object. Whatever object it is, delete it.

'''Note:''' [[Heap Peek]] does not have any ability to change the objects. It is display information only. There are VIs in LV that are not real VIs (for example, a pseudo VI that is created to represent a Call By Reference to another application instance on another machine), and attempting to do Find to jump to their components can cause problems because those VIs never expect to actually draw themselves. But other than that state change, there are no edits to VIs possible using this tool as of November 2007.

[[Category:LabVIEW internals]]
[[Category:Development Environment]]

Insane Objects

2020-06-10T23:22:25Z

Mefistotelis: style

All objects within [[LabVIEW]], have a self-verification mechanism, which makes each object able to audit whether its internal state is within expected bounds set by LV developers. On specific operations, LabVIEW triggers that sanity check on objects. If any object fails the verification, it is marked as Insane.

For example, if a connection-related object has ''state'' set to connected, but the underlying connection reference is ''NULL'' - the object will fail its sanity test. Another example might be an object which flags suggest it is compiled properly and there was no ''source code'' change which would require re-compilation, but the related machine code references objects which were removed.

The insane object message is what LabVIEW puts in a dialog when one of the objects on the diagram does not meet its consistency test. In other words, this object isn't in a state LabVIEW expects it to be in. Most of the time these errors are not fatal -- LabVIEW simply puts the object in the state it does expect. But it raises questions about how the object got into that bad state and what might have been done with that object between the last time LabVIEW checked and it was good and the time it became insane.

== Reporting bugs ==

There is no need to necessarily report generically to [[NI]] that LabVIEW has insane objects; it is a mechanism which developers intentionally introduced. These are NOT merely bugs: insane objects can be generated as part of the LabVIEW internal verification process.

If you get a message about insane object, it is good to check the known bugs of LabVIEW at ni.com, and if the particular insanity in your dialog is not listed, only then should you report the insanity to NI technical support. As always in such cases, it is important to describe the situation which lead to the insane object appearing.

The insane object messages are something NI works on with each version of LabVIEW. But as it is a generic error message that can apply to anything from a simple cosmetic to the [[Front Panel]] itself, you'll still see them in any version of LabVIEW that has a bug -- a fact of life unfortunately for the foreseeable future.

== The displayed message ==

An example of the insanity message may be:
'''''Insane object at FPHP+4C in "name.vi": {dsitem} 0x400: Panel (FPSC)'''''
The cryptic nature of the message can be deciphered as follows:
* FPHP -- this will be either FP or BD for "front panel heap" or "block diagram heap"
* 4C -- this is a hexadecimal number indicating which object.
* name.vi -- which [[VI]] had the insanity
* {dsitem} 0x400 -- really only meaningful if you know how LabVIEW internals work; I'll skip it here
* Panel (FPSC) -- the type of object that has problems. The four letter codes are usually descriptive (COSM for a cosmetic or simple drawn part, SGNL for a signal aka wire). A common one that you won't guess is DDOD, which stands for Data Display Object (the last D is because it has to be 4 chars). A DDO is either a control or an indicator.

Most of the time, deleting the offending object and recreating it from scratch is sufficient to fix your VI and allow you to continue working.

== Using Heap Peek ==

There is a way to find and delete an insane object. When you get an insane error, you will get a code that identifies the object that is insane - write down that code. For example in the section above, the number "4C" is the number that tells you which object is the culprit.

After you have the number, [[Heap_Peek#Enabling_Heap_Peek|enable and invoke Heap Peek window]] with your VI opened (instruction is in the link).

The window is divided into several sections. The functionality of the various parts is obscure and mystical; you can read more about it on the [[Heap Peek|Heap Peek page]]. We're just going to focus on the bits that help with finding and deleting insane objects.

* Check the error message given about the insane object. It includes either the letters ''BDHP'' or ''FPHP''. Scroll through the top-left list box until you find those 4 letters and the name of your VI. Left click to select that item. This will change what is displayed in the top-right section of the window.
* In the top-right section, find the line that begins with the number identifying the object. These are sorted numerically. Left click to select the object when you find it.
* In the middle region, there is a box with an F inside it. This is a button (heap peek doesn't use a lot of advanced drawing, so it doesn't really look like a button, but it is). Click on the F button to find the offending object.
* LabVIEW will switch to the block diagram or front panel and select some object. Whatever object it is, delete it.

'''Note:''' [[Heap Peek]] does not have any ability to change the objects. It is display information only. There are VIs in LV that are not real VIs (for example, a pseudo VI that is created to represent a Call By Reference to another application instance on another machine), and attempting to do Find to jump to their components can cause problems because those VIs never expect to actually draw themselves. But other than that state change, there are no edits to VIs possible using this tool as of November 2007.

[[Category:LabVIEW internals]]
[[Category:Development Environment]]

Insane Objects

2020-06-10T23:15:14Z

Mefistotelis: explanation at top, better structure

All objects within [[LabVIEW]], have a self-verification mechanism, which makes each object able to audit whether its internal state is within expected bounds set by LV developers. On specific operations, LabVIEW triggers that sanity check on objects. If any object fails the verification, it is marked as Insane.

For example, if a connection-related object has ''state'' set to connected, but the underlying connection reference is ''NULL'' - the object will fail its sanity test. Another example might be an object which flags suggest it is compiled properly and there was no ''source code'' change which would require re-compilation, but the related machine code references objects which were removed.

The insane object message is what LabVIEW puts in a dialog when one of the objects on the diagram does not meet its consistency test. In other words, this object isn't in a state LabVIEW expects it to be in. Most of the time these errors are not fatal -- LabVIEW simply puts the object in the state it does expect. But it raises questions about how the object got into that bad state and what might have been done with that object between the last time LabVIEW checked and it was good and the time it became insane.

== Reporting bugs ==

There is no need to necessarily report generically to [[NI]] that LabVIEW has insane objects; it is a mechanism which developers intentionally introduced. These are NOT merely bugs: insane objects can be generated as part of the LabVIEW internal verification process.

If you get a message about insane object, it is good to check the known bugs of LabVIEW at ni.com, and if the particular insanity in your dialog is not listed, only then should you report the insanity to NI technical support. As always in such cases, it is important to describe the situation which lead to the insane object appearing.

The insane object messages are something NI works on with each version of LabVIEW. But as it is a generic error message that can apply to anything from a simple cosmetic to the [[front panel]] itself, you'll still see them in any version of LabVIEW that has a bug -- a fact of life unfortunately for the foreseeable future.

== The displayed message ==

The cryptic nature of the message can be deciphered as follows:
Insane object at FPHP+4C in "name.vi": {dsitem} 0x400: Panel (FPSC)
* FPHP -- this will be either FP or BD for "front panel heap" or "block diagram heap"
* 4C -- this is a hexadecimal number indicating which object.
* name.vi -- which VI had the insanity
* {dsitem} 0x400 -- really only meaningful if you know how LabVIEW internals work; I'll skip it here
* Panel (FPSC) -- the type of object that has problems. The four letter codes are usually descriptive (COSM for a cosmetic or simple drawn part, SGNL for a signal aka wire). A common one that you won't guess is DDOD, which stands for Data Display Object (the last D is because it has to be 4 chars). A DDO is either a control or an indicator.

Most of the time, deleting the offending object and recreating it from scratch is sufficient to fix your VI and allow you to continue working.

== Using Heap Peek ==

There is a way to find and delete an insane object. When you get an insane error, you will get a code that identifies the object that is insane - write down that code. For example in the section above, the number "4C" is the number that tells you which object is the culpit.

After you have the number, [[Heap_Peek#Enabling_Heap_Peek|enable and invoke Heap Peek window]] with your VI opened (instruction is in the link).

The window is divided into several sections. The functionality of the various parts is obscure and mystical; you can read more about it on the [[Heap Peek|Heap Peek page]]. We're just going to focus on the bits that help with finding and deleting insane objects.

* Check the error message given about the insane object. It includes either the letters ''BDHP'' or ''FPHP''. Scroll through the top-left list box until you find those 4 letters and the name of your VI. Left click to select that item. This will change what is displayed in the top-right section of the window.
* In the top-right section, find the line that begins with the number identifying the object. These are sorted numerically. Left click to select the object when you find it.
* In the middle region, there is a box with an F inside it. This is a button (heap peek doesn't use a lot of advanced drawing, so it doesn't really look like a button, but it is). Click on the F button to find the offending object.
* LabVIEW will switch to the block diagram or front panel and select some object. Whatever object it is, delete it.

'''Note:''' [[Heap Peek]] does not have any ability to change the objects. It is display information only. There are VIs in LV that are not real VIs (for example, a pseudo VI that is created to represent a Call By Reference to another application instance on another machine), and attempting to do Find to jump to their components can cause problems because those VIs never expect to actually draw themselves. But other than that state change, there are no edits to VIs possible using this tool as of November 2007.

[[Category:LabVIEW internals]]
[[Category:Development Environment]]

LabVIEW configuration file

2020-06-10T21:15:25Z

Mefistotelis: location

This article contains information related to the LabVIEW configuration file. This file is used by LabVIEW to store configuration information related to the LabVIEW development environment. If you are interested in finding out how to read and write your own [[Configuration file]] then see the article on the [[Configuration file|configuration file VIs]].

== Editing the LabVIEW configuration file - A disclaimer ==

The options that aren't in the preferences dialog are generally considered to be not useful or even harmful. They are sometimes there to allow National Instruments a backdoor or a workaround for when the LabVIEW development team changes a behavior. They are also used to turn on obscure development features that the developers use to make or debug LabVIEW. These obscure features are typically kind of like the attic or basement of a house, not finished out, not very interesting, and potentially harmful.

The LabVIEW developers have never tried to hide any of these strings, but it is unlikely that you will gain any benefit from trying out various combinations of the settings. If you ask technical support what a setting is, they will likely tell you that they have no idea. They are telling you the truth.

Even some of the folks in NI R&D may not know what some of the settings do without checking the code. Others, such as exoticcontrols, no longer do anything. It was once used to show a control palette submenu that contained controls that were still in work and not ready for prime-time. They were experiments, unsupported features, and guaranteed to crash if you did much with them. Just the sort of thing that is needed for development, but not useful to even advanced LabVIEW users unless they have a death-wish.

If you experiment with the .ini file and you crash mysteriously losing hours of work, I'd suggest putting the file back to the way LabVIEW left it. Don't ask tech support to fix it or complain that the LabVIEW attic has rusty nails and splinters.<br> Resedit is a low level tool that in the right hands is useful, in the wrong hands, well, its in the wrong hands. For the person that likes taking a multimeter and a soldering iron to computers and household appliances, its exactly what you always wanted. If you start monkeying with things in the resources or the .ini file, use common sense and do it on a copy or you will just end up reinstalling LabVIEW.

Once the fun and experimentation is over with, I think you will agree that the useful options, with very few exceptions are in the Preferences dialog.

== Configuration file location ==

Depending on your platform, location at which LV searches for options may vary:
* on Mac, use ''ResEdit''
* on Windows, edit text file `labview.ini` located in LV installation directory (where `LabVIEW.exe` is)

== Settings Descriptions ==

This is a relatively comprehensive list of the settings that can be included in a labview.ini file (or a compiled executable's ini file). While some of these settings appear in the files by default, others may only appear when the features used require them to be there. Some settings can only be added manually to provide access to back door features and operations.

LabVIEW configuration keys are organized into the following categories (in alphabetical order):

*[[LabVIEW configuration file/Block Diagram|Block Diagram]]
*[[LabVIEW configuration file/Colors|Colors]]
*[[LabVIEW configuration file/Debugging|Debugging]]
*[[LabVIEW configuration file/Execution System|Execution System]]
*[[LabVIEW configuration file/Fonts|Fonts]]
*[[LabVIEW configuration file/Front Panel|Front Panel]]
*[[LabVIEW configuration file/Getting Started Window|Getting Started Window]]
*[[LabVIEW configuration file/History|History]]
*[[LabVIEW configuration file/Miscellaneous|Miscellaneous]]
*[[LabVIEW configuration file/Paths|Paths]]
*[[LabVIEW configuration file/Performance|Performance]]
*[[LabVIEW configuration file/Printing|Printing]]
*[[LabVIEW configuration file/Time and Date|Time and Date]]
*[[LabVIEW configuration file/VI Server|VI Server]]
*[[LabVIEW configuration file/Web Server|Web Server]]
*[[LabVIEW configuration file/Unknown|Uncategorized]] - Do you recognize any of these? Move them to the right place!
*[[LabVIEW configuration file/Easter Eggs|Easter Eggs]] - Reveal hidden messages and features (no functional advantage. Just for fun)

<br> '''Editor's Note:''' To add new configuration keys to any of the above pages, please use the [[Template:Labviewconfigurationkey|LabVIEW Configuration Key Template]]

----

== See Also ==

*[[Custom LabVIEW configuration file]]

== External Links ==

*[http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/customizing_your_work_environment/#How_LabVIEW_Stores_Options NI.com online help for LV configuration files]
*[http://sthmac.magnet.fsu.edu/labview/LVOptionsList.html Scott Hannahs's LabVIEW Info Page]

[[Category:Configuration File]]

Ned options

2020-06-10T19:23:26Z

Mefistotelis: tag

'''Ned, the friendly configuration manager''' is a debug feature of [[LabVIEW]] in form of a window with list of options. The private, internal set of settings available on that list allow changing various aspects of LabVIEW inner mechanisms.

== Enabling Ned Options ==

Like [[Heap Peek]], Ned Options keyboard shortcut is by default disabled in fresh installations of [[LabVIEW]]. To enable it:
* Close LabVIEW
* Put the key "LVdebugKeys=True" in your [[LabVIEW configuration file]]

Then, to trigger the Ned Options window:
* Open your VI
* Press CTRL+SHIFT+D+N. On Mac, use the command key instead of CTRL. This will open the Ned Options window.

== Using Ned Options ==

Clicking once on a option will switch it, cycling through two or more values.

[[Category:Debugging]]
[[Category:LabVIEW internals]]

Ned options

2020-06-10T19:23:02Z

Mefistotelis: using

Ned options

2020-06-10T19:21:42Z

Mefistotelis: initial page

''Ned, the friendly configuration manager'' is a debug feature of [[LabVIEW]] in form of a window with list of options. The private, internal set of settings available on that list allow changing various aspects of LabVIEW inner mechanisms.

== Enabling Ned Options ==

Like [[Heap Peek]], Ned Options keyboard shortcut is by default disabled in fresh installations of [[LabVIEW]]. To enable it:
* Close LabVIEW
* Put the key "LVdebugKeys=True" in your [[LabVIEW configuration file]]

Then, to trigger the Ned Options window:
* Open your VI
* Press CTRL+SHIFT+D+N. On Mac, use the command key instead of CTRL. This will open the Ned Options window.

[[Category:Debugging]]

Refnum descriptor

2020-06-10T19:09:56Z

Mefistotelis: better description

'''Refnum descriptor''' is a kind of [[type descriptor]] which stores properties of [[Reference data type]].

== List of Refnum types ==

The following table lists the sub-type codes used in the [[type descriptor]] of the [[Reference data type]].

{| class="wikitable"
|-
! Sub-Type Code
! Refnum Type
! Description
|-
| 0x00
| Generic
| the generic type 0x00 is generated only by getting the TD of the "Not a Refnum Constant".
|-
| 0x01
| Datalog File Refnum
|
|-
| 0x02
| Byte Stream File Refnum
|
|-
| 0x03
| Device Refnum
| used in legacy Serial VIs
|-
| 0x04
| Occurence Refnum
|
|-
| 0x05
| TCP Connection Refnum
|
|-
| 0x06
| VISA Refnum (Obsolete)
| obsolete VISA refnum type up to LabVIEW 5.1
|-
| 0x07
| Automation Refnum
|
|-
| 0x08
| VI Server Refnum
|
|-
| 0x09
| Menu Refnum
|
|-
| 0x0A
| IVI Refnum (Obsolete)
| obsolete IVI refnum type up to LabVIEW 5.1
|-
| 0x0B
| IMAQ Session
|
|-
| 0x0D
| DataSocket Refnum
|
|-
| 0x0E
| VISA Resource
|
|-
| 0x0F
| IVI Logical Name
|
|-
| 0x10
| UDP Connection Refnum
|
|-
| 0x11
| Notifier Refnum
|
|-
| 0x12
| Queue Refnum
|
|-
| 0x13
| IrDA Refnum
|
|-
| 0x14
| Storage Refnum
|
|-
| 0x15
| FieldPoint IO Point/Motion Resource
|
|-
| 0x17
| Event Registration Refnum
|
|-
| 0x18
| .NET Refnum
|
|-
| 0x19
| User Event Refnum
|
|-
| 0x1B
| Event Callback
|
|-
| 0x1F
| Bluetooth Refnum
|
|}

==See Also==
*[[type descriptor]]

[[Category:Data types]]
[[Category:LabVIEW internals]]

Refnum descriptor

2020-06-10T19:04:03Z

Mefistotelis: header

The following table lists the subtype codes used in the [[type descriptor]] of the [[Reference data type]].

== List of Refnum types ==

{| class="wikitable"
|-
! Sub-Type Code
! Refnum Type
! Description
|-
| 0x00
| Generic
| the generic type 0x00 is generated only by getting the TD of the "Not a Refnum Constant".
|-
| 0x01
| Datalog File Refnum
|
|-
| 0x02
| Byte Stream File Refnum
|
|-
| 0x03
| Device Refnum
| used in legacy Serial VIs
|-
| 0x04
| Occurence Refnum
|
|-
| 0x05
| TCP Connection Refnum
|
|-
| 0x06
| VISA Refnum (Obsolete)
| obsolete VISA refnum type up to LabVIEW 5.1
|-
| 0x07
| Automation Refnum
|
|-
| 0x08
| VI Server Refnum
|
|-
| 0x09
| Menu Refnum
|
|-
| 0x0A
| IVI Refnum (Obsolete)
| obsolete IVI refnum type up to LabVIEW 5.1
|-
| 0x0B
| IMAQ Session
|
|-
| 0x0D
| DataSocket Refnum
|
|-
| 0x0E
| VISA Resource
|
|-
| 0x0F
| IVI Logical Name
|
|-
| 0x10
| UDP Connection Refnum
|
|-
| 0x11
| Notifier Refnum
|
|-
| 0x12
| Queue Refnum
|
|-
| 0x13
| IrDA Refnum
|
|-
| 0x14
| Storage Refnum
|
|-
| 0x15
| FieldPoint IO Point/Motion Resource
|
|-
| 0x17
| Event Registration Refnum
|
|-
| 0x18
| .NET Refnum
|
|-
| 0x19
| User Event Refnum
|
|-
| 0x1B
| Event Callback
|
|-
| 0x1F
| Bluetooth Refnum
|
|}

==See Also==
*[[type descriptor]]

[[Category:Data types]]
[[Category:LabVIEW internals]]

Type descriptor

2020-06-10T19:02:08Z

Mefistotelis: tag

'''Type descriptors''' are used to define [[Data type|data types]] in [[LabVIEW]]. Simplest types consist of only ''TypeDesc ID'', but more advanced ones have additional properties describing them. Compound types also contain references to the sub-types they include.

From the LabVIEW Help:

LabVIEW associates each wire and terminal on the block diagram with a data type. LabVIEW keeps track of this type with a structure in memory called a ''type descriptor''. This type descriptor is a sequence of 32-bit integers that can describe any data type in LabVIEW. Numeric values are written in hexadecimal format, unless otherwise noted.

'''Note:''' The help text above explain how ''Type descriptors'' are stored in memory when a [[VI|VI file]] is loaded. Their [[Flattening|flattened]] form conserves space and mostly uses values smaller than 32-bit.

== List of TD types ==

{| class="wikitable"
! TypeDesc ID
! Description
! Data Type
|-
|0x00
|Void type, stores no data
| [[Void data type]]
|-
|0x01
|Integer with signed 1 byte (8 bit) data
| [[I8 data type]]
|-
|0x02
|Integer with signed 2 byte (16 bit) data
| [[I16 data type]]
|-
|0x03
|Integer with signed 4 byte (32 bit) data
| [[I32 data type]]
|-
|0x04
|Integer with signed 8 byte (64 bit) data
| [[I64 data type]]
|-
|0x05
|Integer with unsigned 1 byte (8 bit) data
| [[U8 data type]]
|-
|0x06
|Integer with unsigned 2 byte (16 bit) data
| [[U16 data type]]
|-
|0x07
|Integer with unsigned 4 byte (32 bit) data
| [[U32 data type]]
|-
|0x08
|Integer with unsigned 8 byte (64 bit) data
| [[U64 data type]]
|-
|0x09
|Floating point with single precision 4 byte data
| [[Single Float data type]]
|-
|0x0A
|Floating point with double precision 8 byte data
| [[Double Float data type]]
|-
|0x0B
|Floating point with extended (quad precision) data
| [[Extended Float data type]]
|-
|0x0C
|Complex floating point with 8 byte data
| [[Complex Single Float data type]]
|-
|0x0D
|Complex floating point with 16 byte data
| [[Complex Double Float data type]]
|-
|0x0E
|Complex floating point with extended (quad precision) data
| [[Complex Extended Float data type]]
|-
|0x15
|Enumerated UInt8
| [[Enum U8 data type]]
|-
|0x16
|Enumerated UInt16
| [[Enum U16 data type]]
|-
|0x17
|Enumerated UInt32
| [[Enum U32 data type]]
|-
|0x19
|Unit Float32
|
|-
|0x1A
|Unit Float64
|
|-
|0x1B
|Unit FloatExt
|
|-
|0x1C
|Unit Complex64
|
|-
|0x1D
|Unit Complex128
|
|-
|0x1E
|Unit ComplexExt
|
|-
|0x20
|Boolean value stored on 2 bytes (16 bit), rarely used
|
|-
|0x21
|Boolean value stored on 1 byte (8 bit)
| [[Boolean data type]]
|-
|0x30
|String value
| [[String data type]]
|-
|0x31
|Variation of String value, probably never used
|
|-
|0x32
|Path value, used for disk paths, sometimes for URLs
| [[Path data type]]
|-
|0x33
|Picture data
| [[Picture data type]]
|-
|0x34
|CString
|
|-
|0x35
|PasString
|
|-
|0x37
|Tag
|
|-
|0x3F
|SubString
|
|-
|0x40
|Array
|
|-
|0x41
|Array Data Ptr
|
|-
|0x4F
|SubArray
|
|-
|0x50
|Cluster, storing several sub-TDs in a sequence
| [[Cluster data type]]
|-
|0x53
|Variant data type
| [[Variant data type]]
|-
|0x54
|Measurement (Waveform) data
| [[Waveform data type]]
|-
|0x5E
|Complex fixed point number
|
|-
|0x5F
|Fixed point number
| [[Fixed-point data type]]
|-
|0x60
|Block
|
|-
|0x61
|Type block
|
|-
|0x62
|Void block
|
|-
|0x63
|Aligned block
|
|-
|0x64
|Repeated block, stores amount of repeats and one sub-TD to be repeated
|
|-
|0x65
|Alignment marker
|
|-
|0x70
|Refnum; has [[Refnum descriptor|multiple sub-types]], each with different set of properties
| [[Reference data type]]
|-
|0x80
|Ptr
|
|-
|0x83
|Ptr to
|
|-
|0x84
|Ext Data
|
|-
|0xA0
|Array interface
|
|-
|0xA1
|Interface to data
|
|-
|0xF0
|Function
|
|-
|0xF1
|TypeDef
|
|-
|0xF2
|PolyVI
|
|}

==External links==

*[http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/type_descriptors/ LabVIEW 8.2 Help>>Type Descriptors]
*[http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/how_labview_stores_data_in_memory/ LabVIEW 8.2 Help>>How LabVIEW Stores Data in Memory]

[[Category:LabVIEW internals]]
[[Category:Data types]]

Type descriptor

2020-06-10T19:01:47Z

Mefistotelis: refnum ref

'''Type descriptors''' are used to define [[Data type|data types]] in [[LabVIEW]]. Simplest types consist of only ''TypeDesc ID'', but more advanced ones have additional properties describing them. Compound types also contain references to the sub-types they include.

From the LabVIEW Help:

LabVIEW associates each wire and terminal on the block diagram with a data type. LabVIEW keeps track of this type with a structure in memory called a ''type descriptor''. This type descriptor is a sequence of 32-bit integers that can describe any data type in LabVIEW. Numeric values are written in hexadecimal format, unless otherwise noted.

'''Note:''' The help text above explain how ''Type descriptors'' are stored in memory when a [[VI|VI file]] is loaded. Their [[Flattening|flattened]] form conserves space and mostly uses values smaller than 32-bit.

== List of TD types ==

{| class="wikitable"
! TypeDesc ID
! Description
! Data Type
|-
|0x00
|Void type, stores no data
| [[Void data type]]
|-
|0x01
|Integer with signed 1 byte (8 bit) data
| [[I8 data type]]
|-
|0x02
|Integer with signed 2 byte (16 bit) data
| [[I16 data type]]
|-
|0x03
|Integer with signed 4 byte (32 bit) data
| [[I32 data type]]
|-
|0x04
|Integer with signed 8 byte (64 bit) data
| [[I64 data type]]
|-
|0x05
|Integer with unsigned 1 byte (8 bit) data
| [[U8 data type]]
|-
|0x06
|Integer with unsigned 2 byte (16 bit) data
| [[U16 data type]]
|-
|0x07
|Integer with unsigned 4 byte (32 bit) data
| [[U32 data type]]
|-
|0x08
|Integer with unsigned 8 byte (64 bit) data
| [[U64 data type]]
|-
|0x09
|Floating point with single precision 4 byte data
| [[Single Float data type]]
|-
|0x0A
|Floating point with double precision 8 byte data
| [[Double Float data type]]
|-
|0x0B
|Floating point with extended (quad precision) data
| [[Extended Float data type]]
|-
|0x0C
|Complex floating point with 8 byte data
| [[Complex Single Float data type]]
|-
|0x0D
|Complex floating point with 16 byte data
| [[Complex Double Float data type]]
|-
|0x0E
|Complex floating point with extended (quad precision) data
| [[Complex Extended Float data type]]
|-
|0x15
|Enumerated UInt8
| [[Enum U8 data type]]
|-
|0x16
|Enumerated UInt16
| [[Enum U16 data type]]
|-
|0x17
|Enumerated UInt32
| [[Enum U32 data type]]
|-
|0x19
|Unit Float32
|
|-
|0x1A
|Unit Float64
|
|-
|0x1B
|Unit FloatExt
|
|-
|0x1C
|Unit Complex64
|
|-
|0x1D
|Unit Complex128
|
|-
|0x1E
|Unit ComplexExt
|
|-
|0x20
|Boolean value stored on 2 bytes (16 bit), rarely used
|
|-
|0x21
|Boolean value stored on 1 byte (8 bit)
| [[Boolean data type]]
|-
|0x30
|String value
| [[String data type]]
|-
|0x31
|Variation of String value, probably never used
|
|-
|0x32
|Path value, used for disk paths, sometimes for URLs
| [[Path data type]]
|-
|0x33
|Picture data
| [[Picture data type]]
|-
|0x34
|CString
|
|-
|0x35
|PasString
|
|-
|0x37
|Tag
|
|-
|0x3F
|SubString
|
|-
|0x40
|Array
|
|-
|0x41
|Array Data Ptr
|
|-
|0x4F
|SubArray
|
|-
|0x50
|Cluster, storing several sub-TDs in a sequence
| [[Cluster data type]]
|-
|0x53
|Variant data type
| [[Variant data type]]
|-
|0x54
|Measurement (Waveform) data
| [[Waveform data type]]
|-
|0x5E
|Complex fixed point number
|
|-
|0x5F
|Fixed point number
| [[Fixed-point data type]]
|-
|0x60
|Block
|
|-
|0x61
|Type block
|
|-
|0x62
|Void block
|
|-
|0x63
|Aligned block
|
|-
|0x64
|Repeated block, stores amount of repeats and one sub-TD to be repeated
|
|-
|0x65
|Alignment marker
|
|-
|0x70
|Refnum; has [[Refnum descriptor|multiple sub-types]], each with different set of properties
| [[Reference data type]]
|-
|0x80
|Ptr
|
|-
|0x83
|Ptr to
|
|-
|0x84
|Ext Data
|
|-
|0xA0
|Array interface
|
|-
|0xA1
|Interface to data
|
|-
|0xF0
|Function
|
|-
|0xF1
|TypeDef
|
|-
|0xF2
|PolyVI
|
|}

==External links==

*[http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/type_descriptors/ LabVIEW 8.2 Help>>Type Descriptors]
*[http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/how_labview_stores_data_in_memory/ LabVIEW 8.2 Help>>How LabVIEW Stores Data in Memory]

[[Category:LabVIEW internals]]

Refnum

2020-06-10T19:00:49Z

Mefistotelis: Mefistotelis moved page Refnum to Refnum descriptor

#REDIRECT [[Refnum descriptor]]

Refnum descriptor

2020-06-10T19:00:49Z

Mefistotelis: Mefistotelis moved page Refnum to Refnum descriptor

The following table lists the subtype codes used in the [[type descriptor]] of the [[Reference data type]].

{| class="wikitable"
|-
! Sub-Type Code
! Refnum Type
! Description
|-
| 0x00
| Generic
| the generic type 0x00 is generated only by getting the TD of the "Not a Refnum Constant".
|-
| 0x01
| Datalog File Refnum
|
|-
| 0x02
| Byte Stream File Refnum
|
|-
| 0x03
| Device Refnum
| used in legacy Serial VIs
|-
| 0x04
| Occurence Refnum
|
|-
| 0x05
| TCP Connection Refnum
|
|-
| 0x06
| VISA Refnum (Obsolete)
| obsolete VISA refnum type up to LabVIEW 5.1
|-
| 0x07
| Automation Refnum
|
|-
| 0x08
| VI Server Refnum
|
|-
| 0x09
| Menu Refnum
|
|-
| 0x0A
| IVI Refnum (Obsolete)
| obsolete IVI refnum type up to LabVIEW 5.1
|-
| 0x0B
| IMAQ Session
|
|-
| 0x0D
| DataSocket Refnum
|
|-
| 0x0E
| VISA Resource
|
|-
| 0x0F
| IVI Logical Name
|
|-
| 0x10
| UDP Connection Refnum
|
|-
| 0x11
| Notifier Refnum
|
|-
| 0x12
| Queue Refnum
|
|-
| 0x13
| IrDA Refnum
|
|-
| 0x14
| Storage Refnum
|
|-
| 0x15
| FieldPoint IO Point/Motion Resource
|
|-
| 0x17
| Event Registration Refnum
|
|-
| 0x18
| .NET Refnum
|
|-
| 0x19
| User Event Refnum
|
|-
| 0x1B
| Event Callback
|
|-
| 0x1F
| Bluetooth Refnum
|
|}

==See Also==
*[[type descriptor]]

[[Category:Data types]]
[[Category:LabVIEW internals]]

Refnum descriptor

2020-06-10T18:57:33Z

Mefistotelis: ref

Data Space

2020-06-10T18:54:15Z

Mefistotelis: typo

'''Data Space''' is a continuous block of memory, existing for each [[VI|VI file]], which stores values of instantiated [[data type]]s.

''Data Space'' contains filling for all data elements. The data elements are instances of [[data type]]s defined by [[Type descriptor]]s. Type map is used to assign place in ''Data Space'' for [[Type descriptor]]s.

Longer explanation:
* Like in all languages, you can define [[Data type|data types]] in [[LabVIEW]]. You don't need any action to define [[Boolean data type|boolean]] - you just place the [[control]] which uses it, and ''data type'' is added automatically. But compound types, like [[Cluster data type|Clusters]] and Arrays - these you need to define manually.
* LV stores all [[Data type|data types]] used within a [[VI]] in form of [[Type descriptor|Type Descriptors]] ('''TD'''s). There is a table of these in every VI file.
* When an instance of data type is required - real variable needs to be created - the '''TD''' is added to '''Type Map'''. Type Map is just another table, which maps TDs into Data Space. That '''Type Map Entry''' is a confirmation that there is an area reserved in ''Data Space'' for the variable, and it also points to the specific place where data starts.
* ''Data Space'' is a continuous block of memory, which consists only of data. Reading ''Data Space'' requires information of what is stored where - so Type Map Entries are required to give meaning to the binary values stored in Data Space.

Some of the types stored in ''Data Space'' are not linked directly to user created code, and are LV internal data instead. For example, the data space always contains a block of 51 integer values - these are settings internal to LabVIEW, called [[DSInit Table]]. It also contains a list of [[DCO]]s - objects which contain selected properties of controls and indicators from [[Front Panel]], and are retained even when FP is removed form VI file.

Offsets of specific items within ''data space'' block do not change when values within data are modified. This means that any variable size values (ie. strings) are not stored directly in the continuous ''data space'', but are allocated separately and ''data space'' only contains pointer to the real data. This means that data space is size invariant, as long as Type Map remains unchanged.

''Data space'' of a [[VI|VI file]] can be viewed in detail within [[Heap Peek]] window.

[[Category:LabVIEW internals|LV internal]]
[[Category:LabVIEW internals]]

Data Space

2020-06-10T18:53:51Z

Mefistotelis: ref to heap peek

'''Data Space''' is a continuous block of memory, existing for each [[VI|VI file]], which stores values of instantiated [[data type]]s.

''Data Space'' contains filling for all data elements. The data elements are instances of [[data type]]s defined by [[Type descriptor]]s. Type map is used to assign place in ''Data Space'' for [[Type descriptor]]s.

Longer explanation:
* Like in all languages, you can define [[Data type|data types]] in [[LabVIEW]]. You don't need any action to define [[Boolean data type|boolean]] - you just place the [[control]] which uses it, and ''data type'' is added automatically. But compound types, like [[Cluster data type|Clusters]] and Arrays - these you need to define manually.
* LV stores all [[Data type|data types]] used within a [[VI]] in form of [[Type descriptor|Type Descriptors]] ('''TD'''s). There is a table of these in every VI file.
* When an instance of data type is required - real variable needs to be created - the '''TD''' is added to '''Type Map'''. Type Map is just another table, which maps TDs into Data Space. That '''Type Map Entry''' is a confirmation that there is an area reserved in ''Data Space'' for the variable, and it also points to the specific place where data starts.
* ''Data Space'' is a continuous block of memory, which consists only of data. Reading ''Data Space'' requires information of what is stored where - so Type Map Entries are required to give meaning to the binary values stored in Data Space.

Some of the types stored in ''Data Space'' are not linked directly to user created code, and are LV internal data instead. For example, the data space always contains a block of 51 integer values - these are settings internal to LabVIEW, called [[DSInit Table]]. It also contains a list of [[DCO]]s - objects which contain selected properties of controls and indicators from [[Front Panel]], and are retained even when FP is removed form VI file.

Offsets of specific items within ''data space'' block do not change when values within data are modified. This means that any variable size values (ie. strings) are not stored directly in the continuous ''data space'', but are allocated separately and ''data space'' only contains pointer to the real data. This means that data space is size invariant, as long as Type Map remains unchanged.

''Data space'' of a [[VI|VI file]] can be viewed in detail within [[Heap Peak]] window.

[[Category:LabVIEW internals|LV internal]]
[[Category:LabVIEW internals]]