LabVIEW
DLL API plugin communication (XPLANE)
Solved!
Hello everyone.
I'm trying to read information from an external software, in this case Xplane simulator; So for this purpose the xplane provides a dll program for external programs to access the simulator data.
So in labview, we have the function Call Library Function to open a .dll and do the commands for dll.
I'm having trouble accessing this data. The main problem is how I can transpose these codes (see below) into the Labview Call Library Function interface in porper mode to read this data?
> I'm going to upload some photos to better explain my problems.
I tried to do many things without success.
I've been trying to read many references before, made this post.
> My version of labview is 13;
and here are some instructions for manipulating the xplane dll from the original site.
XPLMDataAccess
XPLM Data Access API - Theory of Operation
The data access API gives you a generic, flexible, high performance way to read and write data to and from X-Plane and other plug-ins. For example, this API allows you to read and set the nav radios, get the plane location, determine the current effective graphics frame rate, etc.
The data access APIs are the way that you read and write data from the sim as well as other plugins.
The API works using opaque data references. A data reference is a source of data; you do not know where it comes from, but once you have it you can read the data quickly and possibly write it. To get a data reference, you look it up.
Data references are identified by verbose string names (sim/cockpit/radios/nav1_freq_hz). The actual numeric value of the data reference is implementation defined and is likely to change each time the simulator is run (or the plugin that provides the datareference is reloaded).
The task of looking up a data reference is relatively expensive; look up your data references once based on verbose strings, and save the opaque data reference value for the duration of your plugin's operation. Reading and writing data references is relatively fast (the cost is equivalent to two function calls through function pointers).
This allows data access to be high performance, while leaving in abstraction; since data references are opaque and are searched for, the underlying data access system can be rebuilt.
A note on typing: you must know the correct data type to read and write. APIs are provided for reading and writing data in a number of ways. You can also double check the data type for a data ref. Note that automatic conversion is not done for you.
A note for plugins sharing data with other plugins: the load order of plugins is not guaranteed. To make sure that every plugin publishing data has published their data references before other plugins try to subscribe, publish your data references in your start routine but resolve them the first time your 'enable' routine is called, or the first time they are needed in code.
X-Plane publishes well over 1000 datarefs; a complete list may be found in the reference section of the SDK online documentation (from the SDK home page, choose Documentation).
READING AND WRITING DATA
These routines allow you to access a wide variety of data from within x-plane and modify some of it.
XPLMDataRef
typedef void * XPLMDataRef;A data ref is an opaque handle to data provided by the simulator or another plugin. It uniquely identifies one variable (or array of variables) over the lifetime of your plugin. You never hard code these values; you always get them from XPLMFindDataRef.
XPLMDataTypeID
This is an enumeration that defines the type of the data behind a data reference. This allows you to sanity check that the data type matches what you expect. But for the most part, you will know the type of data you are expecting from the online documentation.
Data types each take a bit field, so sets of data types may be formed.
| xplmType_Unknown | 0 | Data of a type the current XPLM doesn't do. |
| xplmType_Int | 1 | A single 4-byte integer, native endian. |
| xplmType_Float | 2 | A single 4-byte float, native endian. |
| xplmType_Double | 4 | A single 8-byte double, native endian. |
| xplmType_FloatArray | 8 | An array of 4-byte floats, native endian. |
| xplmType_IntArray | 16 | An array of 4-byte integers, native endian. |
| xplmType_Data | 32 | A variable block of data. |
XPLMFindDataRef
XPLM_API XPLMDataRef XPLMFindDataRef(
const char * inDataRefName);
Given a c-style string that names the data ref, this routine looks up the actual opaque XPLMDataRef that you use to read and write the data. The string names for datarefs are published on the x-plane SDK web site.
This function returns NULL if the data ref cannot be found.
NOTE: this function is relatively expensive; save the XPLMDataRef this function returns for future use. Do not look up your data ref by string every time you need to read or write it.
Thanks all.
From the look of what you show, this is going to be pretty much over your head. You seem to have no understanding of even the basic principles of C programming. And for using Call Library Nodes you need to have a fairly sound understanding of C programming, since the DLL interface is simply C programming based, without any fancy managed code that holds your hands and makes sure you can only configure things that make somehow sense.
And while the Import Library Wizard is a nice tool and has impressive features it can NOT do magic despite its fancy name. But to create VIs with 100% correctly configured Call Library Nodes from the very limited information that a C header file can describe would be truely magic. It would be able to import this specific function correctly but almost certainly has to fail with more complex functions that need to return array or string data to the caller. The difficulty here is then that unless you are able to configure the Call Library Node yourself correctly, you are in no way able to asses that the wizard generated code is correct. It may be or not and if it isn't it may still seem to work or not or simply crash or not, or maybe only after you build the application and distributed it to your test machines, or depending on the moon phase or some other fancy unbelievable fact. In the best case the Call Library Node will return error 1097 and while it often may seem to have worked anyhow, ignoring error 1097 will ALWAYS bite you in your ass rather sooner than later. It means almost always that the call corrupted something somewhere in memory or in the state of the process and while everything still can seem to work for a while it WILL crash at some point, maybe a few seconds later, or minutes or hours.
As to this specific function you would need to configure the Call Library Node as follows:
Thread: Depends on the DLL and should be described in the documentation if it is multithreading safe. If you can't find this in the documentation the safe thing to do is to set it to Run in UI thread. Choosing Run in any thread when the DLL is not multithreading safe could crash randomly but more likely will appear to work most of the time, except when it doesn't and produces completely nonsense results that are impossible to explain logically.
Caling Convention: possibly C, but you don't show the full header file and project file so it could be also stdcall. Choosing the wrong here will usually crash or the DLL node will return error 1097.
Function Name: XPLMFindDataRef
return value:
Type: Numeric
Data Type: Pointer sized Unsigned Integer
1st parameter:
Name: inDataRefName
Type: String
Constant: True
String Format: Data String Pointer
Minimum Size: None
But your API clearly supports functions to retrieve data and probably also arrays and according to the type ID also variable sized elements. Calling these correctly with the Call Library Node will be something where the wizard at best can create inefficient VI configurations and more likely than not will simply go ashtray.
