LabVIEW
Profibus DLL implementation doesn't work
Solved!
The official Windows documentation says that 0 is FALSE and anything else is TRUE. You can't rely on 1 being used for TRUE!
This is consistent with C logic. You don't really have a boolean in C.
If you want to test an element for boolean values you have to test like this:
int booleanVal;
int booleanArray;
#define SOME_BOOL_MASK 0x0100
if (booleanVal)
printf("TRUE");
if (!booleanVal)
printf("TRUE");
if (booleanArray & SOME_BOOL_MASK)
printf("Bit 0x%x is TRUE", SOME_BOOL_MASK);
if (!(booleanArray & SOME_BOOL_MASK))
printf("Bit 0x%x is FALSE", SOME_BOOL_MASK);
@MaSta wrote:
OK, so the struct elements are packed in groups of 8 bytes. I would have to expect the Visual Studio compiler to add fill bytes for those elements not fitting into a group of 8 bytes, which would explain why sizeof() returns 1456. Means, in my struct definition I will also have to put some fill bytes? And where? I cannot even know if the compiler would perhaps rearrange the struct elements in memory to fill up groups of 8 bytes.
No, the struct elements are packed at a multiple of 8 bytes or the actual elements datasize, whichever is smaller!
There is NO right or wrong packing. It is whatever the client (DLL) was compiled with and there is NO way for the caller to know that automatically. You as programmer are responsible to know what packing is needed if any, what default alignment was used to compile the DLL and have to take care about that when calling DLLs.
If you are lucky there is an explicit #pragma pack() statement in the according header that you can see, but it can just as well only be specified in the project file used to compile the DLL.
A group of 8 bytes or a multiple of 8. For me it's the same. When some elements' combined size is less, there will be fill data.
What I now did was to extend the Win32 demo by some code that prints the full 1456 bytes of stDpData into the console window and saved is as a binary file. From the structure starting with:
typedef struct {
unsigned char DPV1_Supported; /* (1 byte) set on startup: enable DPV1 support, */
unsigned char Max_Channel_Data_Length; /* (2 bytes)set on startup: max DPV1 channel length (4..244) */
unsigned char Extra_Alarm_SAP; /* (3 bytes)set on startup: Extra DPV1 Alarm SAP */
unsigned int C1_Response_Timeout; /* (5 bytes)set on startup: C1 Response Timeout */
unsigned char NormParameters [7]; /* (12 bytes)set on startup: norm parameter. Ident number is read from slave */
unsigned char UserParamLength; /* (13 bytes)set on startup: user parameter length */
unsigned char UserParameters [248]; /* (261 bytes)set on startup: user parameter */
the NormParameters would start at offset 5, but here start at 8, so there are 3 filled/aligned bytes.
The rest is filled at the end. So the solution is to stretch the struct by 3 bytes. And indeed, it worked!
Thanks for your help.
Nope!
typedef struct { offset size
unsigned char DPV1_Supported; 0 1
unsigned char Max_Channel_Data_Length; 1 1
unsigned char Extra_Alarm_SAP; 2 1
//unsigned char filler1; 3 1
unsigned int C1_Response_Timeout; 4 4
unsigned char NormParameters [7]; 8 7
unsigned char UserParamLength; 15 1
unsigned char UserParameters [248]; 16 248
} Struct; total size 264
C1_Response_Timeout is an int and as such only uses 4 byte (on every current platform with the exception of some 8 bit embedded CPUs). Because of that it is aligned on a 4 byte boundary even if the default alignment is set to 8 byte!
