LabVIEW
How to pass structure into dll?
For this you'll have to consult the Linux headers and look at the actual definition of the structure. The complication here is that struct sockaddr* is only an incomplete definition. Depending on the actual protocol you want to pass information for, you'll have to use the correct sockaddr_XXX definition.
Also Linux does not use DLLs but shared object modules (*.so). (And VxWorks uses *.out modules).
From my Linux headers the struct to use for IPv4 is defined like this:
struct sockaddr_in {
int16_t sin_family; // e.g. AF_INET
uint16_t sin_port; // e.g. htons(3490)
struct in_addr sin_addr; // see struct in_addr, below
char sin_zero[8]; // filler bytes, zero this if you want to
};
struct in_addr {
unsigned char s_addr[4]; /* IPv4 address */
};
struct in_addr is again a fixed array of 4 bytes.
For IPv6 however the structure is like this:
struct sockaddr_in6 {
int16_t sin6_family; /* AF_INET6 */
uint16_t sin6_port; /* port number */
uint32_t sin6_flowinfo; /* IPv6 flow information */
struct in6_addr sin6_addr; /* IPv6 address */
uint32_t sin6_scope_id; /* Scope ID (new in 2.4) */
};
struct in6_addr {
unsigned char s6_addr[16]; /* IPv6 address */
};
The last parameter to the bind function should then receive the sizeof(struct sockaddr_in6) value.
Basically you can create a cluster in LabVIEW with the according elements and pass that to the function with the Adapt to Type setting for this parameter. Filling in the actual values for the elements is however tricky. Just remember that LabVIEW strings are not the same as C string pointers and even less like fixed size C string fields. In order to resemble the fixed size array elements in above struct you need to place a LabVIEW cluster with the number of elements of that size into the outer cluster.
While the definitions such as AF_INET, AF_INET6 are standardized by Posix, the actual numeric values they map to are not and can differ between socket implementations. There is a serious mismatch between those numbers between the WinSock and Linux socket implementation but even the numbers for Linux sockets which is just like the WinSock implementation derived from the Berkeley sockets implementation, are sometimes different to the numbers for BSD Unix variants such as FreeBSD. In the LabVIEW world things get even more interesting if you also want to support the older PPC based realtime systems that run VXWorks as OS. This OS also has a socket library that is heavily inspired by the Berkeley socket implementation, but its functions are not all the same and the numeric values for all those constants are different again.
So you really will need to install the development headers for your operating system and get the actual numeric values from there and not just go and take them from a Windows or another Unix system.
Please check here that your sbRIO is really using NI Linux Realtime and not VxWorks.
1) The development headers are not installed by default. You would need to do that with the opkg manager command on the cRIO or alternatively install the preconfigured Eclipse based C development tool chain on Windows that NI provides as a download. The .so file is a binary file like a DLL under Windows and contains no human readable parts. The structure definitions used in there are implied by the source code used to create the shared library, but this source code is NOT included in the shared library.
2) correct
3) I mean what I said. A fixed size array inside a struct in C is simply inlined in the struct. The only way to resemble that in LabVIEW is to place a cluster with the correct amount of elements inside the main cluster. E.g
struct
{
int32_t num;
char fixedSize[6];
} MyStruct;
will have to be created in LabVIEW as a cluster with an int32 element as first element followed by a cluster inside this cluster with 6 * uInt8 elements.
4) No the uint16_t elements in the struct definitions are simply uInt16 integers. They are always fixed size, according to the size definition used by the C compiler. While the standard C types int, short, long etc can change in byte size depending on the platform and C compiler used (but will always stay fixed size on a partular platform and compiler), int16_t and friends are newer definitions that are supposed to have the indicated number of bits from the type name independent of platform and C compiler (provided the C compiler toolchain supports the necessary C99 standard!). When a C programmer talks about fixed size arrays or strings he means an element like:
char string[16]; int array[256];
Unlike a pointer variable, these definitions instruct the C compiler to actually create an according string of 16 characters, or an array of 256 integer numbers.
Considering the pretty basic questions you have so far, I'm afraid this whole thing is going to be pretty hard to successfully tackle for you.
Interfacing external code is a pretty tricky exercise, and unfortunately even when it won't crash anymore you still have no guarantee that it will be correct if you don't understand the very basics of how a C compiler works and allocates structures and pointers in memory. If this is for a throw away school project, there is not much lost by trying anyhow, but if you intend to use this in an industrial setup I would recommend you to look for assistance from someone who has a real understanding of these things. Otherwise you are only creating a maintenance nightmare and a potential time bomb.
@JHugh wrote:
Where can I download the development headers?
Note that I've previously installed Eclipse from NI, but I cannot seem to find the headers on my disk. I also am uploading to my board via Ethernet so I do not have internet access while connected to my board.
Point 9 in this Getting Started document lists the system roots for various targets. You will probably find an "include" subdirectory at those locations, which hopefully contains the headers you're looking for.
You are very much over your head with this!
On your sbRIO you won't have any headers unless you install the whole gcc development package through opkg. If you don't know how to do this you definitely don't want to do it. With it you can use gcc directly on the target to compile C code.
The paths mentioned in the paper from NI refer to the Eclipse installation you claim to have done on your host computer and you will have to check there for the headers.
Just grabbing some random cygwin header files from the net is not gonna work. They are most likely for development under cygwin for Windows targets and therefore match the WinSock constants from the Microsoft SDKs, not the Linux headers from the NI Linux kernel. This setup, while apparently using the cygwin cross compile toolchain for the LabVIEW 2017 based development, does not have anything to do with cygwin for Windows development, other than that it makes use of the same toolchain but retargeted for cross compilation to the NI Linux Realtime system.
So if you installed the NI Eclipse development toolchain on your Windows computer, check in there for the appropriate include directory!
And no, whoever told you that you could use AF_CCITT in place of AF_INET6 does not understand socket programming at all.
