alvise

I don't experiment too much as I don't want to make mistakes. I want to run sensible tests.
I read your previous post maybe 10-20 times.
I think I need to pass a "Not a Refnum" to the installcalback function you describe here and create it in the stop event frame.

Of course I tried that, no difference.

From what I understand so far, uninstallcalback should be created in dll and use in labview with Not A refnum (no reference) to delete callback if stop button is pressed.
The dll file should understand this no-reference status and run the remove function and remove the callback.It should release the library for that.

I need to create 2 parameters in this function.1-Return 2- for ''Not A Refnum'' connection.

I'm experimenting by doing research and commenting out the existing code.
But I haven't been able to find exactly how the code needs to be able to perform the callback function.

I came to the following conclusion.I guess it should be created as follows, right?

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 unInstallStandardCallback(LONG lRealHandle, LVUserEventRef * refnum)
{
    HMODULE hDLL = LoadLibraryW(L"HCNetSDK.dll");
    if (hDLL)
    {
        Type_SetStandardDataCallBack uninstallFunc = (Type_SetStandardDataCallBack)GetProcAddress(hDLL, "NET_DVR_SetStandardDataCallBack");
        if (uninstallFunc)
        {
            FreeLibrary(hDLL);
         
        }
        
    }

}

I don't know if I have established a correct logic

Either I'm really walking towards a light or at the end of the road I will realize that that light is the light that the firefly emits to catch its prey, of course, it is too late for everything now 

5 minutes ago, Rolf Kalbermatter said:

This type of error is very quickly the difference between a crashing monster and a well behaving application. There is no LabVIEW who can save you from this. It is YOU who has to make sure that what you write in the external code, matches exactly what you tell LabVIEW to expect. It must be able to trust you blindly on this or your library is nothing more than a bunch of crashing dummies. If you can't make sure of that because you obviously don't understand the actual implications and/or easily forget about them after they have been explained to you a few posts earlier, then you are truly playing with fire in trying to create such a library. Seriously!

 

I try to be very careful. But sometimes accidents like this happen.Thanks for your warning.

7 minutes ago, Rolf Kalbermatter said:

That are the statements I love in every problem description. Very precise and to the point, NOT!

How does it look when you conclude it is not read? Does just the array get empty data? Do the other values such as lRealHandle turn to show a different value too? And which one?

Right now it is like I show you a picture of a nice car (your image shows that there is actually data) and then tell you he doesn't sometimes work. Can you help me? Who could except someone with clairvoyant abilities?

Does it start? Does it suddenly stop? Are you sure there is gas in the tank? Do any lights in the dashboard light up?  You see what I'm saying?

-For example, if I run VI (if I press each key properly), the data (numbers) in the array are constantly changing, and on this basis, I say that the data can be read.
But sometimes (perhaps after running and stopping VI a few times) the string contains data from the previous run and the data (number) remains constant in the array. I interpret this situation as no data read.

I don't know how self-explanatory it was. Referring to the car example also reminded me how dire my situation was.

-I've been reading over and over when you wrote how to create -installcallback.vi. But I didn't understand exactly what to do.

At first, U32 was a numeric number, I directly converted it to an array and set the data type to U8. Later, when the problem occurred, I tried to test it with U32 numeric again.
But when I got picture as U8 I was testing as U8
Later when making changes I forgot to change it back to U8.

I think the problem still persists. Again sometimes the data is not being read.

Preview CAM-6.vi

1 hour ago, Rolf Kalbermatter said:

Could it be that he simply did not activate the button again but left it pressed as it was? That state is only send on state change of the button, not because LabVIEW magically doesn't know that it should call that event case again to send the True state to the DLL.

I guess that's exactly why sometimes it gets the data and sometimes it doesn't, I guess what you said confirms what you said after some testing.

      a moment of distraction        

After making changes, I started to read data. Sometimes the data can be read and sometimes not.

As a precaution against forgetting the Stream button, make a change as follows.

Preview CAM-5.vi

After making changes as below, nothing changed.

Preview CAM-4.vi

After closing and reopening the project completely I am facing a situation as below.dwdatatype returns value as 0.

5 minutes ago, Rolf Kalbermatter said:

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.

What I mean here is that currently the event structure is not reading any data.

2 minutes ago, dadreamer said:

If I got it right, he says that on one run of the VI the events are being sent OK, but on another run (after he stops the VI and runs it again) no events is sent regardless of the button being pressed.

And that's exactly what I mean.

they look like below.

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

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.

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.txthas 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.

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

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

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:

 

1. 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?

#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  

2 hours ago, dadreamer said:

I see two main issues here.

1. 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.
2. 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?

10 minutes ago, dadreamer said:

Maybe because on each event a new handle is allocated?

Now you're gonna have some fun with MoveBlock thingy 😉 Does your loop manage to process events in time?

yes, I guess it allocates a new handle to each event.
I'm not playing with something dangerous, am I ?

Does your loop manage to process events in time? - I've included a few photos of the test below, although I don't quite understand what you're saying here.

I think there is an unstable situation. Sometimes when I run the VI the values refresh like crazy, Other times if I stop the VI and run it again nothing is read.

Taking your suggestions into account, I updated the VI as follows. Currently there is no problem, at least the labview does not crash and I get some values as output. Of course, I don't know if there are errors.
What is the reason why the Handle value is sometimes flickering on the screen?

Preview CAM-1.vi

According to what you said step by step, I made a fix as follows, but if I press the start button, the labview crashes.

Hikvision-labviewSDK-Test-v1.0.0.rar

Upon your suggestion, I deleted the folder named release and created it again. I can see the labview DataCallBack and InstallStandardCallback functions.

I guess this is the next step.

after editing no errors or warnings as below.

When you call the dll file from the debug file here, it has function names as follows.

While building, the output is something like this. There is no problem here, is there?