Using the DLL files of an application compiled with C# with labview

alvise · May 31, 2022

2 hours ago, dadreamer said:

I see two main issues here.

Too many events coming - your program just can't handle them all at once (you were already warned about that). How can you deal with it? You decide. I often use a boolean variable switch for that. You may consider something else.

You want to have UninstallStandardCallback function to stop posting into LV, when the loop finishes or no matter what. Now your DLL seems to be trying to post even when the main VI finishes plus the event queue is full with unprocessed events. Try to implement that function on your own, it's not that complex.

-Boolean variable switch must be created inside the dll file and it is necessary to send a value (1-0) to it from the labview, right?

dadreamer · May 31, 2022

1 hour ago, alvise said:

-Boolean variable switch must be created inside the dll file and it is necessary to send a value (1-0) to it from the labview, right?

Yes, something like this:

extern "C" __declspec(dllexport) void __cdecl SetCbState(LVBoolean *state);
// ...
LVBoolean cbState = LVBooleanFalse;
// ...
extern "C" __declspec(dllexport) void __cdecl SetCbState(LVBoolean *state)
{
  cbState = *state;
}
// ...
extern "C" __declspec(dllexport) void __stdcall DataCallBack(LONG lRealHandle, DWORD dwDataType, BYTE *pBuffer, DWORD dwBufSize, DWORD dwUser)
{
  if (cbState==LVBooleanTrue){
    // callback code
  }
}

alvise · May 31, 2022


#include "extcode.h"
#include "hosttype.h"
#include "HCNetSDK.h"




#define LibAPI(retval)       __declspec(dllexport) EXTERNC retval __cdecl
#define Callback(retval)     __declspec(dllexport) EXTERNC retval __stdcall

// Define LabVIEW specific datatypes to pass data as event
// This assumes that the LabVIEW event datatype is a cluster containing following elements in exactly that order!!!
// cluster
//   int32       contains the current live view handle 
//   uInt32      contains the dwDataType (NET_DVR_SYSHEAD, NET_DVR_STD_VIDEODATA, NET_DVR_STD_AUDIODATA, NET_DVR_PRIVATE_DATA,
//                                        or others as documented in the NET_DVR_SetStandardDataCallBack() function
//   array of uInt8     contains the actual byte stream data
#include "lv_prolog.h"
typedef struct
{
	int32_t size;
	uint8_t elm[1];
} 
LVByteArrayRec, * LVByteArrayPtr, ** LVByteArrayHdl;// ** LVByteArrayHdl;pointer to a pointer

typedef struct
{
	LONG realHandle;
	DWORD dataType;
	LVByteArrayHdl handle;
} LVEventData;
#include "lv_epilog.h"
extern "C" __declspec(dllexport) void __cdecl SetCbState(LVBoolean * state);
// where Standard Boolean type case is set: typedef uInt8 LVBoolean
LVBoolean cbState = LVBooleanFalse;
// always set to false on startup
extern "C" __declspec(dllexport) void __cdecl SetCbState(LVBoolean * state)
{
	cbState = *state;
}
// cbstate does a state reassessment.True or False
extern "C" __declspec(dllexport) void __stdcall DataCallBack(LONG lRealHandle, DWORD dwDataType, BYTE * pBuffer, DWORD dwBufSize, DWORD dwUser)
{
	LVEventData eventData = { 0 };
	MgErr err = NumericArrayResize(uB, 1, (UHandle*)&(eventData.handle), dwBufSize);
	if (cbState == LVBooleanTrue && err)// send callback data if there is no error and the cbstatus is true.
	{

		LVUserEventRef userEvent = (LVUserEventRef)dwUser;
		MoveBlock(pBuffer, (*(eventData.handle))->elm, dwBufSize);
		(*(eventData.handle))->size = (int32_t)dwBufSize;
		eventData.realHandle = lRealHandle;
		eventData.dataType = dwDataType;
		PostLVUserEvent(userEvent, &eventData);
		DSDisposeHandle(eventData.handle);
	}
}
//If the above if condition does not occur, the LVUserEventRef here does not take a value.
typedef BOOL(__stdcall* Type_SetStandardDataCallBack)(LONG lRealHandle, void(CALLBACK* fStdDataCallBack) (LONG lRealHandle, DWORD dwDataType, BYTE* pBuffer, DWORD dwBufSize, DWORD dwUser), DWORD dwUser);
extern "C" __declspec(dllexport) BOOL __cdecl InstallStandardCallback(LONG lRealHandle, LVUserEventRef * refnum)
{
	HMODULE hDLL = LoadLibraryW(L"HCNetSDK.dll");
	if (hDLL)
	{
		Type_SetStandardDataCallBack installFunc = (Type_SetStandardDataCallBack)GetProcAddress(hDLL, "NET_DVR_SetStandardDataCallBack");
		if (installFunc)
		{
			return installFunc(lRealHandle, DataCallBack, (DWORD)(*refnum));
		}
		FreeLibrary(hDLL);
	}
	return FALSE;
}

I guess you meant something like.By the way, it compiles without problems.

this.As far as I understand, I made comments

Edited May 31, 2022 by alvise

dadreamer · May 31, 2022

Why did you leave eventData declaration and NumericArrayResize call outside the condition? Unnecessary work for the callback to do, if the flag is False.

There's also a mistake in your code. Compare with this:

Edited May 31, 2022 by dadreamer

Rolf Kalbermatter · May 31, 2022

1 hour ago, dadreamer said:

Why did you leave eventData declaration and NumericArrayResize call outside the condition? Unnecessary work for the callback to do, if the flag is False.

The eventData declaration is harmless. This is a stack variable space and gets allocated anyhow on function entry by reserving the according stack space. In the worst case it adds a single MOV rrx, sp+x call before the condition calculation, but it might do that even if you put it inside the if statement because of C compiler optimization to prevent CPU pipeline stalling.

The call to NumericArrayResize() is a different story. This can be a potentially relatively expensive call, so should indeed only be done when necessary.

Edited May 31, 2022 by Rolf Kalbermatter

alvise · May 31, 2022

The reason I left this ''

LVEventData eventData = { 0 };
	MgErr err = NumericArrayResize(uB, 1, (UHandle*)&(eventData.handle), dwBufSize);

''out A simple mistake to define !err.Didn't realize I hadn't put the ('!'') sign.

-Do you think I should create it as follows?

#include "extcode.h"
#include "hosttype.h"
#include "HCNetSDK.h"

#define LibAPI(retval)       __declspec(dllexport) EXTERNC retval __cdecl
#define Callback(retval)     __declspec(dllexport) EXTERNC retval __stdcall

// Define LabVIEW specific datatypes to pass data as event
// This assumes that the LabVIEW event datatype is a cluster containing following elements in exactly that order!!!
// cluster
//   int32       contains the current live view handle 
//   uInt32      contains the dwDataType (NET_DVR_SYSHEAD, NET_DVR_STD_VIDEODATA, NET_DVR_STD_AUDIODATA, NET_DVR_PRIVATE_DATA,
//                                        or others as documented in the NET_DVR_SetStandardDataCallBack() function
//   array of uInt8     contains the actual byte stream data
#include "lv_prolog.h"
typedef struct
{
	int32_t size;
	uint8_t elm[1];
} 
LVByteArrayRec, * LVByteArrayPtr, ** LVByteArrayHdl;// ** LVByteArrayHdl;pointer to a pointer

typedef struct
{
	LONG realHandle;
	DWORD dataType;
	LVByteArrayHdl handle;
} LVEventData;
#include "lv_epilog.h"
extern "C" __declspec(dllexport) void __cdecl SetCbState(LVBoolean * state);
// where Standard Boolean type case is set: typedef uInt8 LVBoolean
LVBoolean cbState = LVBooleanFalse;
// always set to false on startup
extern "C" __declspec(dllexport) void __cdecl SetCbState(LVBoolean * state)
{
	cbState = *state;
}
// cbstate does a state reassessment.True or False
extern "C" __declspec(dllexport) void __stdcall DataCallBack(LONG lRealHandle, DWORD dwDataType, BYTE * pBuffer, DWORD dwBufSize, DWORD dwUser)
{
	LVEventData eventData = { 0 };
	MgErr err = NumericArrayResize(uB, 1, (UHandle*)&(eventData.handle), dwBufSize);
	if (cbState == LVBooleanTrue && !err)// send callback data if there is no error and the cbstatus is true.
	{
		LVEventData eventData = { 0 };
		MgErr err = NumericArrayResize(uB, 1, (UHandle*)&(eventData.handle), dwBufSize);
		LVUserEventRef userEvent = (LVUserEventRef)dwUser;
		MoveBlock(pBuffer, (*(eventData.handle))->elm, dwBufSize);
		(*(eventData.handle))->size = (int32_t)dwBufSize;
		eventData.realHandle = lRealHandle;
		eventData.dataType = dwDataType;
		PostLVUserEvent(userEvent, &eventData);
		DSDisposeHandle(eventData.handle);
	}
}
//If the above if condition does not occur, the LVUserEventRef here does not take a value.
typedef BOOL(__stdcall* Type_SetStandardDataCallBack)(LONG lRealHandle, void(CALLBACK* fStdDataCallBack) (LONG lRealHandle, DWORD dwDataType, BYTE* pBuffer, DWORD dwBufSize, DWORD dwUser), DWORD dwUser);
extern "C" __declspec(dllexport) BOOL __cdecl InstallStandardCallback(LONG lRealHandle, LVUserEventRef * refnum)
{
	HMODULE hDLL = LoadLibraryW(L"HCNetSDK.dll");
	if (hDLL)
	{
		Type_SetStandardDataCallBack installFunc = (Type_SetStandardDataCallBack)GetProcAddress(hDLL, "NET_DVR_SetStandardDataCallBack");
		if (installFunc)
		{
			return installFunc(lRealHandle, DataCallBack, (DWORD)(*refnum));
		}
		FreeLibrary(hDLL);
	}
	return FALSE;
}

9 hours ago, dadreamer said:

You want to have UninstallStandardCallback function to stop posting into LV, when the loop finishes or no matter what. Now your DLL seems to be trying to post even when the main VI finishes plus the event queue is full with unprocessed events. Try to implement that function on your own, it's not that complex.

It is necessary to create this in the dll code again, right?

Edited May 31, 2022 by alvise

Rolf Kalbermatter · May 31, 2022

I would do it like this:

First it is important to move the NumericArrayResize() call into the same condition level as the DSDisposeHandle() call. Your code currently leaks a handle every time the callback is called while the cbState boolean is on LVBooleanFalse, which is VERY bad. The fact that it does unnecessary work is not perfect bad a very minor problem in comparison.

// cbstate does a state reassessment.True or False
extern "C" __declspec(dllexport) void __stdcall DataCallBack(LONG lRealHandle, DWORD dwDataType, BYTE * pBuffer, DWORD dwBufSize, DWORD dwUser)
{
    if (cbState == LVBooleanTrue)
    {
        LVEventData eventData = { 0 };
        MgErr err = NumericArrayResize(uB, 1, (UHandle*)&(eventData.handle), dwBufSize);
        if (!err)// send callback data if there is no error and the cbstatus is true.
        {
            LVEventData eventData = { 0 };
            MgErr err = NumericArrayResize(uB, 1, (UHandle*)&(eventData.handle), dwBufSize);
            LVUserEventRef userEvent = (LVUserEventRef)dwUser;
            MoveBlock(pBuffer, (*(eventData.handle))->elm, dwBufSize);
            (*(eventData.handle))->size = (int32_t)dwBufSize;
            eventData.realHandle = lRealHandle;
            eventData.dataType = dwDataType;
            PostLVUserEvent(userEvent, &eventData);
            DSDisposeHandle(eventData.handle);
        }
    }
}

//If the above if condition does not occur, the LVUserEventRef here does not take a value.
typedef BOOL(__stdcall* Type_SetStandardDataCallBack)(LONG lRealHandle, void(CALLBACK* fStdDataCallBack) (LONG lRealHandle, DWORD dwDataType, BYTE* pBuffer, DWORD dwBufSize, DWORD dwUser), DWORD dwUser);
extern "C" __declspec(dllexport) BOOL __cdecl InstallStandardCallback(LONG lRealHandle, LVUserEventRef * refnum)
{
    HMODULE hDLL = LoadLibraryW(L"HCNetSDK.dll");
    if (hDLL)
    {
        Type_SetStandardDataCallBack installFunc = (Type_SetStandardDataCallBack)GetProcAddress(hDLL, "NET_DVR_SetStandardDataCallBack");
        if (installFunc)
        {
            if (refnum && *refnum) 
                return installFunc(lRealHandle, DataCallBack, (DWORD)(*refnum));
            else
                return installFunc(lRealHandle, NULL, 0));
        }
        FreeLibrary(hDLL);
    }
    return FALSE;
}

Then write an Uninstall Callback.vi that is essentially the same as the Install Callback.vi but don't pass in any user event refnum. Simply pass a NotARefnum to the second parameter of the Call Library Node.

Edited June 1, 2022 by Rolf Kalbermatter

dadreamer · May 31, 2022

1 hour ago, alvise said:

Do you think I should create it as follows?

Rolf nailed it already 🙂 So do as written above.

Rolf Kalbermatter · June 1, 2022

But you do realize that once you got the callback reliably posting binary data to your event loop, all the problems up to now are pretty much peanuts in comparison? That bytestream is compressed, with a format that depends on the parameter dwDataType and some information in the data stream, likely not in every package but at specific moments that you have to detect based on the context of earlier packages (which you hopefully haven't suppressed with your inhibit boolean).

And that compression is H264 or maybe MPEG4 or similar for the video data and G722 or such for the Audio packages, but the documentation also talks about other possible formats, most likely depending on the camera model and/or its settings. Going to decode H264 or MPEG4 in LabVIEW itself is going to be a no-no. It may technically be possible but I would not consider being able to write a video decompressor in C and even less in LabVIEW. the math and programming needed for that is simply to complicated. Which leaves only one option: finding an external DLL and interfacing to it and believe me, interfacing to a video decompressor is no easy feat. Your exercises so far would seem almost trivial in comparison, and you are already swimming with your nose barely at the surface.

Edited June 1, 2022 by Rolf Kalbermatter

alvise · June 1, 2022

I've currently compiled and run the code you suggested last time. Since the true flag is not sent in the dll file, I get the following output when run.

EventLog.txt

Why was the "Datacallback" function in the picture above created, is it necessary to get information using that function?

Now I'm trying to figure out how can I send the true-falsa flag.
If I'm not mistaken, I had to create something like below, but now the labview is crashing.

Preview CAM-2.vi

dadreamer · June 1, 2022

10 minutes ago, alvise said:

Why was the "Datacallback" function in the picture above created, is it necessary to get information using that function?

Because you exported it. Leave it as is.

11 minutes ago, alvise said:

Now I'm trying to figure out how can I send the true-falsa flag.

Take a boolean button with Switch when released mechanical action and create a new event frame "Value Change" with that button inside. Put a CLFN with SetCbState call, add one parameter in its settings with Adapt to Type -> Handles by Values data type and format. Wire your button to the CLFN. Now you're controlling the callback event flow.

Rolf Kalbermatter · June 1, 2022

27 minutes ago, alvise said:

Why was the "Datacallback" function in the picture above created, is it necessary to get information using that function?

First the DataCallback() wasn't "created" but "exported. It needs to be present in the DLL so you can pass its address to the according SDK function. But it does not need to be exported from the DLL for that. As long as the Calling convention is configured correctly it will work without exporting it.

And the thing that causes the linker to add that function to the DLL export table is your

extern "C" __declspec(dllexport)

in front of the DataCallback declaration. It is unnecessary and only helps to confuse you.

Simply defining is like this should be enough:

void CALLBACK DataCallBack(LONG lRealHandle, DWORD dwDataType, BYTE * pBuffer, DWORD dwBufSize, DWORD dwUser)
{
     ...
}

Quote

Now I'm trying to figure out how can I send the true-falsa flag.
If I'm not mistaken, I had to create something like below, but now the labview is crashing.

Your nose really is barely above the water level. Take a break, and a deep breath!

You simply need to create a VI that calls the SetCbState() function.

And ohhhhhhhhhhhh my God!!!!!! You defined the event data cluster totally wrong. That "handle" is not an integer value. It is a full and complete LabVIEW byte array!! It shouldn't cause your crash .. at least not immediately! But since you don't tell LabVIEW that it is a handle it can't manage its memory. Meaning with every message that is sent to your event loop, you simply leak that handle each time. That will drive your application into out of memory in no time, just as the incorrect handling of the cbState boolean did. You not only were leaking handles when the cbState boolean was false but with EVERY single callback!!!!!!!!

Edited June 1, 2022 by Rolf Kalbermatter

dadreamer · June 1, 2022

16 minutes ago, Rolf Kalbermatter said:

And ohhhhhhhhhhhh my God!!!!!! You defined the event data cluster totally wrong. That "handle" is not an integer value. It is a full and complete LabVIEW byte array!! It shouldn't cause your crash .. at least not immediately! But since you don't tell LabVIEW that it is a handle it can't manage its memory. Meaning with every message that is sent to your event loop, you simply leak that handle each time. That will drive your application into out of memory in no time, just as the incorrect handling of the cbState boolean did. You not only were leaking handles when the cbState boolean was false but with EVERY single callback!!!!!!!!

This explains why he was seeing unstable behaviour from run to run. This is what happens, when two advisers are trying to help simultaneously. 😃 I often prefer a slightly different way to transfer data from the callback. I post a pointer to data and in LabVIEW I read it out with MoveBlock (because I like to see a minimalistic external code and do most of the coding in LV instead).

By the way, I kind of think posting an U32/U64 number might work, if DSDisposeHandle would be moved to the LV Event frame from the callback code and in that frame MoveBlock + DSDisposeHandle would be called.

Edited June 1, 2022 by dadreamer

alvise · June 1, 2022

Right now I made a change as you said. I get the following output.

Is it normal to get an output like the one below? Because sometimes I get Realhandle data. Sometimes I don't.

I made the fix as follows.

Preview CAM-3.vi

EventLog-1.txt

Edited June 1, 2022 by alvise

Rolf Kalbermatter · June 1, 2022

21 minutes ago, dadreamer said:

This explains why he was seeing unstable behaviour from run to run. This is what happens, when two advisers are trying to help simultaneously. 😃 I often prefer a slightly different way to transfer data from the callback. I post a pointer to data and in LabVIEW I read it out with MoveBlock (because I like to see a minimalistic external code and do most of the coding in LV instead).

By the way, I kind of think posting an U32/U64 number might work, if DSDisposeHandle would be moved to the LV Event frame from the callback code and in that frame MoveBlock + DSDisposeHandle would be called.

Yes it would work, if you make sure to call the DSDisposeHandle function on EVERY event, without inhibiting its call through some intermediate error cluster handling AND without having other programming errors AND without trying to single step through the code AND, AND, AND.

I prefer to make it as stable as possible rather than as unmaintainable as possible. 😆 Your approach is fine if you get it fully debugged and then slap a password on the VI to prevent the uninhibited from peaking into your VI and mess with its inner workings. Giving the average LabVIEW user even the possibility to tinker with any pointers, is a sure way to make them create a mess.

You mean to say it is their fault if they do that? Sure it is, but many do not have the knowledge to understand that it is. 😀

And if you want to make it 32-bit and 64-bit compatible you have to choose between two uglies that way:

1) define the handle explicitly as U64 on the C side and typecast it to that to pass it to LabVIEW. And treat it as U64 on the LabVIEW side just as any pointer sized integer.

2) create conditional compile code with the event cluster definition. This would be über-ugly.

Edited June 1, 2022 by Rolf Kalbermatter

dadreamer · June 1, 2022

6 minutes ago, alvise said:

Is it normal to get an output like the one below? Because sometimes I get Realhandle data. Sometimes I don't.

Now correct the cluster contents as proposed and test again.

Rolf Kalbermatter · June 1, 2022

30 minutes ago, alvise said:

Right now I made a change as you said. I get the following output.

Is it normal to get an output like the one below? Because sometimes I get Realhandle data. Sometimes I don't.

I have no idea what you mean. It doesn't look wrong to me. The lRealHandle is always 0, which according to the SDK documentation is a valid session handle and should match the value that you pass to InstallCallback after having started the camera stream.

The dwDataType is 1 in the first package which indicates that it is a SysHead package with some initial information about the stream as documented in some of the SDK C samples. dwDataType = 2 seems not to be documented in the SKD help for the StandardDataCallback. But it is for the RealDataCallback which states that it is simply stream data, so not likely meant to be decoded yourself but simply streamed to a file as .ps file as in the SDK sample. And there we are back at the start. To get such a .ps file you could also simply have called NET_DVR_SaveRealData() and forget about all the callback hassles.

Edited June 1, 2022 by Rolf Kalbermatter

alvise · June 1, 2022

By the way, isn't it necessary to use this function and this function? Because I'm currently using this function.

55 minutes ago, dadreamer said:

Now correct the cluster contents as proposed and test again.

Which cluster do I need to fix?
are you talking about this?

39 minutes ago, Rolf Kalbermatter said:

I have no idea what you mean. It doesn't look wrong to me. The lRealHandle is always 0, which according to the SDK documentation is a valid session handle and should match the value that you pass to InstallCallback after having started the camera stream.

The dwDataType is 1 in the first package which indicates that it is a SysHead package with some initial information about the stream as documented in some of the SDK C samples. dwDataType = 2 seems not to be documented in the SKD help for the StandardDataCallback. But it is for the RealDataCallback which states that it is simply stream data, so not likely meant to be decoded yourself but simply streamed to a file as .ps file as in the SDK sample. And there we are back and the start. To get such a .ps file you could also simply have called NET_DVR_SaveRealData() and forget about all the callback hassles.

What I don't understand is why sometimes Real Handle information is read in "Event Log" and sometimes not. I made 2 different log records below.no real handle info.txt has real handle info.txt

-As I understand "callback" is only required for "Standard Data Callback", it cannot be used to read required video data.
But I'm reviewing the function here it's talking about streaming video data.

Edited June 1, 2022 by alvise

dadreamer · June 1, 2022

3 minutes ago, alvise said:

are you talking about this?

Yes. Make handle as U8 array instead of a numeric.

dadreamer · June 1, 2022

@alvise

Do you really need audio in your streams? Because if no, then it would be a way easier to work with pure NET_DVR_STD_VIDEODATA (4) packets.

alvise · June 1, 2022

3 minutes ago, dadreamer said:

@alvise

Do you really need audio in your streams? Because if no, then it would be a way easier to work with pure NET_DVR_STD_VIDEODATA (4) packets.

No need for audio data.

alvise · June 1, 2022

17 minutes ago, dadreamer said:

Yes. Make handle as U8 array instead of a numeric.

I made the correction as you said, and I am getting the following log records. Currently, no Realhandle data is visible.

EventLog-15.txt

Edited June 1, 2022 by alvise

dadreamer · June 1, 2022

Is your cluster elements order correct? Open Context Help window, then select Wiring Tool and hover it over the pink wire. In the Context Help you'll see order of the cluster elements.

Edited June 1, 2022 by dadreamer

alvise · June 1, 2022

they look like below.

Rolf Kalbermatter · June 1, 2022

1 hour ago, alvise said:

I made the correction as you said, and I am getting the following log records. Currently, no Realhandle data is visible.

EventLog-15.txt 35.15 kB · 1 download

I have absolutely no idea what you mean when you say that no RealHandle data is visible. As far as that log looks, no event is ever sent. This could be happening if your cbState boolean was never set to true.

Edited June 1, 2022 by Rolf Kalbermatter

Using the DLL files of an application compiled with C# with labview

Recommended Posts

Link to comment

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Popular Posts

dadreamer

alvise

Rolf Kalbermatter

Posted Images

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Join the conversation

Important Information