Leaderboard

I have the binaries as arrays of bytes in the Post Install. I convince VIPM to not include the binary dependency and then write out the binary from the Post Install. You can check in the Post install which bitness has invoked it to write out the correct bitness binary. Not sure if that would work on Linux though.

If you use LabVIEW native datatypes, the Import Shared Library Wizard is NOT the right tool to use. Generally speaking if you are not able to configure the Call Library Node yourself correctly, use of the Import Shared Library Wizard is simply a way to setup your code for failure. There is absolutely no way that an automated tool could create always correct code from a C header file alone, except for really trivial APIs. The C syntax is to ambiguous to describe all aspects of an API and it does not at all describe memory management issues for any parameters that are more complex than scalars. Generally speaking, you either have a non-LabVIEW specific DLL that hopefully uses generic C data types as parameters and is not trying to pass dynamically allocated memory buffers to the caller, or you start with a LabVIEW VI, configure a Call Library Node and connect native LabVIEW datatypes to it, configure the according parameters to Adapt To Type, right click on the Call Library Node and select "Create c. file" and then use the generated prototype and fill in the function body with what you want to implement in the C function. For the code example 2) I provided you have to: 1) NOT use the Import Library Wizard, it can NOT deal with the complex types that LabVIEW native datatypes are. 2) configure your C compiler to look in the cintools directory inside the LabVIEW directory for header files 3) Configure a Call Library Node yourself with three parameters: 1) Adapt to Type, pass Pointers to Handles and wiring an according 2D LabVIEW array of Int32 to it 2) Integer, Pointer sized, Pass by Value 3) Integer, Pointer sized, Pass by Value As to your code, yes you can do it like that. "#include extcode.h" is however useless, there is nothing in your code that would need that header file. You then create a Call Library Node and configure it to have these parameters: 1) Array, int32, 2 dimensions, Pass as Array Data Pointer 2) Integer, int32, Pass by Value 3) Integer, int32, Pass by Value Make sure to always use "Initialize Array" on the diagram to allocate a 2D array with the same sizes as what you pass to the function in the 2nd and 3rd parameter and wire that array to the 1st parameter!!!! If the array is not allocated or allocated smaller than what you tell the function to fill in, you just created a "crash your computer" program! It may usually not crash (right away), but it will corrupt memory and eventually your LabVIEW program will crash, eat your harddrive or do something else that is undesirable and there is nobody to blame for that but yourself. And about the used datatypes: While int is always a 32-bit integer for all platforms on which LabVIEW can run and use of it in your C code is therefore not really a problem, other basic C datatypes such as long are not the same size on some of the platforms. Therefore it is useful to use explicitly sized datatypes such as int32_t for parameters that interface with the LabVIEW diagram. LabVIEW is very strictly typed and always uses explicitly sized datatype, the only exception are the two pointer sized integer datatypes, but they only exist in the Call Library Node, never on the diagram.

Glad to hear that it was useful for your test. Thanks for the feedback!

Due to the overwhelming response I put together a solution using some free online tools. First, you will need a tool called yEd. (http://www.yworks.com/en/products_yed_about.html) This is a very nice free tool for generating various graphs and charts. Next you will need Excel because that is the file type yEd uses to import an adjacency matrix. Last, you will need some LV code to generate an adjacency matrix and node property list from a project. Here is one I made for Actor Framework. Please excuse the poor code layout as I hacked this together quickly. Generate AF Node Map Data.vi (Note: this can easily be adapted to other message systems. The only change would be the mapping for the color properties to the appropriate parent classes. Open the VI, choose your target project and your destination xlsx file and run it! You will get a file like this: AF Demo node list.zip (zipped for your protection. ) Next you need to open this file in yEd. When you do, you need to set the data ranges correctly, like this: and choose a presentation configuration like this: which I created earlier using this: The end result, after a few cosmetic tweaks results in this: Pretty cool, eh? (Well, I think it is useful. I always prefer to visualize my applications. Complex apps using messaging architectures can get pretty hard to follow without good documentation.) I hope others find this useful. -John