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

[alvise]

OK. In order not to take too long, I did some tests myself here. Let me explain the test and the result first.
Note: I did this test with the VI that I shared last and that you said looks good.

- After pressing the "Run" button, I press the "Stream" button, the data can be read, then I press the "Stop" button and the data flow is stopped. If I press the "Start" button again without pressing the "Exit" button, the data will not be read. I press the stop button again.
When I test it by following a sequence. Mostly data is read once and not read once.
Actually, there is one more thing I suspect now.
-Why does the Session number here change between 0 and 1 every time I run and close the VI.
If I run VI, "Session" will get 1, and if I turn it off and on again, it will get 0. This is in a loop, the value of the session is changing every time I run it. It sounds like this might be causing a problem. Shouldn't this number stay the same all the time?

 

Edited June 2, 2022 by alvise

[dadreamer]

7 hours ago, alvise said:

- After pressing the "Run" button, I press the "Stream" button, the data can be read, then I press the "Stop" button and the data flow is stopped. If I press the "Start" button again without pressing the "Exit" button, the data will not be read. I press the stop button again.

Press 'Start" -> press "Stream" -> the data is being read -> un-press "Stream" -> press "Stop" -> again press "Start" -> again press "Stream" -> the data is being NOT read... Is that your order of actions?

By the way, do you know that InstallStandardCallback has return value?

You have set it to void in the CLFN settings, but it should be Numeric -> Signed 32-bit Integer. So let's check that value. Put two indicators on your FP from both InstallStandardCallback calls and watch which values they obtain in "good" and in "bad" case. According to the documentation for NET_DVR_SetStandardDataCallBack TRUE (1) means success, FALSE (0) means failure and NET_DVR_GetLastError should be called to find out the reason behind the error.

Edited June 3, 2022 by dadreamer

[alvise]

3 hours ago, dadreamer said:

Press 'Start" -> press "Stream" -> the data is being read -> un-press "Stream" -> press "Stop" -> again press "Start" -> again press "Stream" -> the data is being NOT read... Is that your order of actions?

Yes, this is it. Sometimes there is data, sometimes not.

3 hours ago, dadreamer said:

By the way, do you know that InstallStandardCallback has return value?

You have set it to void in the CLFN settings, but it should be Numeric -> Signed 32-bit Integer. So let's check that value. Put two indicators on your FP from both InstallStandardCallback calls and watch which values they obtain in "good" and in "bad" case. According to the documentation for NET_DVR_SetStandardDataCallBack TRUE (1) means success, FALSE (0) means failure and NET_DVR_GetLastError should be called to find out the reason behind the error.

When I test with the above order. The results are as follows.

By the way, I set the returns as 32 bit signed integer.

- ''Callback start return '' If it takes the value '1'. Data can be read. If it takes the value '0', the data cannot be read.

-The "SetCbState" value gets a new random value when the VI is completely shut down and restarted. For example, if VI is opened, the values will show as ''0'' and when run it will return ''324433408''.
If the VI is completely closed and reopened, it gets the value "418927872". However, in the numbers I gave above, the last value is one up and one down (418927871-418927872) in sync with the "Stream" button.

 

-"stop callback" changes from 1 to 0 each time it is turned on and off. In other words, there is no connection with whether there is data according to the value of 0 or 1. Sometimes data is read even if a value of 1 is returned, sometimes data is read even if a value of 0 is returned. Sometimes the opposite happens and the value is not read.

Edited June 3, 2022 by alvise

[Rolf Kalbermatter]

1 hour ago, alvise said:

-The "SetCbState" value gets a new random value when the VI is completely shut down and restarted. For example, if VI is opened, the values will show as ''0'' and when run it will return ''324433408''.
If the VI is completely closed and reopened, it gets the value "418927872". However, in the numbers I gave above, the last value is one up and one down (418927871-418927872) in sync with the "Stream" button.

Did you change the function to actually return a value? In the last code you posted the SetCbState() function returns void. That means you can configure the Call Library Node to return an integer value, but what it will return is random data, or more precisely whatever the function was last using the eax register for. Since it is declared to have a void return value, the compiler does not make sure to return anything meaningful in there.

I would change the actual InstallCallback function as follows:

//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) MgErr __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)
        {
            BOOL retval;
            if (refnum && *refnum)
                retval = installFunc(lRealHandle, DataCallBack, (DWORD)(*refnum));
            else
                retval = installFunc(lRealHandle, NULL, 0);
            if (retval)
                return mgNoErr;
            else
                return 5000 + NET_DVR_GetLastError();
        }
        FreeLibrary(hDLL);
    }
    return mgNotSupported;
}

 

Edited June 3, 2022 by Rolf Kalbermatter

[alvise]

I still think there is a possibility that the "session" value here is causing a problem.
I believe the number here should not change. In order for this number to be a fixed number, I made some changes as follows. But the number is still changing. Don't you think this will cause a problem?

Preview CAM-9.vi

 

7 minutes ago, Rolf Kalbermatter said:

Did you change the function to actually return a value? In the last code you posted the SetCbState() function returns void. That means you can configure the Call Library Node to return an integer value,

I tried and tested a change as you said in the attached VI.

Based on the code you shared, I will make changes to the dll code and compile and test it again.

 

[Rolf Kalbermatter]

The exact value of the session variable is not to be interpreted in any way other than what the API documentation states. And in there it says:

Quote

-1 means false, and other values could be used as the handle of functions like NET_DVR_StopRealPlay. Please call NET_DVR_GetLastError to get the error code.

It's a bit unclear thanks to the non-native people who wrote that SDK. But I interprete that as follows.

Quote

-1 means error, please call NET_DVR_GetLastError to get the error code.

any other values are a valid session handle that can be use with functions like NET_DVR_StopRealPlay.

This specifically means that a value of 0 should be also valid.

Typically these "handles" are simply an index into an API private array of structures that contain the actual data to manage the session/connection/resource.

Quote

I tried and tested a change as you said in the attached VI.

Just changing the definition of the Call Library Node is NOT sufficient. You also need to change the C code to actually return a specific value!!!!! When you define the Call Library node for SetCbState() to return a value, the implementation of that funciton in your C code must explicitly return a value or the Call Library Node will simply return a random value (more specifically: whatever the function left dangling in the eax register of the CPU).

Edited June 3, 2022 by Rolf Kalbermatter

[dadreamer]

@alvise Yes, you better to adapt your DLL code as written in order to see the error numbers according to the SDK and no more guess on coffee grounds. I see on your screenshots that "callback start return" is 0 (FALSE), but "callback stop return" is 1 (TRUE). As per the documents FALSE indicates some error and if it occurs when calling NET_DVR_SetStandardDataCallBack it would be good to know the reasons.

By the way here's HCNetSDK Error Codes list online to easily correspond error numbers with their text messages.

Edited June 3, 2022 by dadreamer

[alvise]

When I compile the code here and try to use labview, I get an error like the following, what could be the reason?
Everything is as it should be, I just compiled the code and replaced the newly created dll file with the old one.

[alvise]

I have compiled this review by adding additional addictions as in the picture below.
Probably causes this problem.

[Rolf Kalbermatter]

52 minutes ago, alvise said:

I have compiled this review by adding additional addictions as in the picture below.
Probably causes this problem.

Nope, can't be!

[alvise]

yes,After doing some testing I realized that this is not likely to cause problems.but I can't find the real problem.

Edited June 3, 2022 by alvise

[alvise]

In a way that I can't understand now, the problem was solved and I ran the example.
I get an output like below. Returns the number ''5017'' when the data is not read.

I guess 5017= NET_DVR_PARAMETER_ERROR

Edited June 3, 2022 by alvise

[Rolf Kalbermatter]

59 minutes ago, alvise said:

In a way that I can't understand now, the problem was solved and I ran the example.
I get an output like below. Returns the number ''5017'' when the data is not read.

I guess 5017= NET_DVR_PARAMETER_ERROR

And as you can see in the code, the error value is 5000 + whatever the NET_DVR_GetLastError() returned. Now you go into the SDK documentation and read what error 17 means.

So yes the function thinks that one of the parameters is not valid. The callback function pointer can't really be it, neither can it say anything about the callback data parameter, so that leaves only the session handle. I have no idea why it thinks that is invalid. 

Edited June 3, 2022 by Rolf Kalbermatter

[dadreamer]

2 hours ago, alvise said:

I guess 5017= NET_DVR_PARAMETER_ERROR

If you are using the VI posted in your last message with the attachment, then you have made a mistake there.

Why so inattentive? This trait brings nothing good to programming at all.

Edited June 3, 2022 by dadreamer

[alvise]

1 hour ago, dadreamer said:

If you are using the VI posted in your last message with the attachment, then you have made a mistake there.

Why so inattentive? This trait brings nothing good to programming at all.

I noticed the problem there and fixed it.

 

The problem here has reoccurred, even though I have made no changes, is there any point in it being this way?

[dadreamer]

29 minutes ago, alvise said:

The problem here has reoccurred, even though I have made no changes

I suppose you did something in either your Visual Studio project settings or in your DLL code... This is odd. Check the library dependencies again. Check if you are on Release build. Clean up / remove the output build folders and rebuild everything from scratch.

BTW NI recommends using Dependencies - An open-source modern Dependency Walker 😉

Edited June 3, 2022 by dadreamer

[alvise]

10 hours ago, dadreamer said:

BTW NI recommends using Dependencies - An open-source modern Dependency Walker 😉

yes, there was a problem with the dependencies, now the problem is solved. I am currently getting the following error.

NET_DVR_ORDER_ERROR

12

Call sequence error.

 

[alvise]

Problem solved. I think the problem arises when using "NET_DVR_SetRealDataCallBack" function. Using this 'NET_DVR_SetRealDataCallBack' function fixed the problem.Data can now be read without any problems.

[dadreamer]

3 hours ago, alvise said:

I think the problem arises when using "NET_DVR_SetRealDataCallBack" function. Using this 'NET_DVR_SetRealDataCallBack' function fixed the problem.

You mean using NET_DVR_SetRealDataCallBack instead of NET_DVR_SetStandardDataCallBack?

3 hours ago, alvise said:

Data can now be read without any problems.

So could you do this then? We can't go on without looking at the data as nobody except you has that hardware here. Of course, you may figure out the format of the data on your own, if you wish.

[alvise]

58 minutes ago, dadreamer said:

You mean using NET_DVR_SetRealDataCallBack instead of NET_DVR_SetStandardDataCallBack?

So could you do this then? We can't go on without looking at the data as nobody except you has that hardware here. Of course, you may figure out the format of the data on your own, if you wish.

-yes because ''NET_DVR_Set Standard Data CallBack'' causes problems.

-I changed the datatype(dwDataType) to 2.

-Is it necessary to capture the NET_DVR_SYSHEAD (1) packet?

-How do I catch a packet that I don't understand at the moment

Edited June 4, 2022 by alvise

[alvise]

I did not understand clearly how a package should be registered, but I created records as follows. I don't know, is this exactly what you want?

NET_DVR_STREAMDATA.txt NET_DVR_SYSHEAD.txt

Edited June 4, 2022 by alvise

[dadreamer]

I've thought of something like this.

The way you're showing above you catch several packets at once, because the packets arrive much faster than you do "pressing -> un-pressing" the button.

[alvise]

- I did the fix as you suggested. I can only capture the ''NET_DVR_STREAM DATA'' packet. I saved 2 different samples.
- I can't save package ''NET_DVR_SYSHEAD'' because ''dwDataType'' only returns 2 no matter what number I type.

NET_DVR_STREAMDATA(1).txt NET_DVR_STREAMDATA(2).txt

[dadreamer]

13 hours ago, alvise said:

I can only capture the ''NET_DVR_STREAM DATA'' packet.

In some of your previous tests you showed that NET_DVR_SYSHEAD arrives first and is followed by a sequence of NET_DVR_STREAM_DATA packets. I can't say now, whether we really need NET_DVR_SYSHEAD to analyse NET_DVR_STREAM_DATA, but it would be useful to have both of them.

13 hours ago, alvise said:

I saved 2 different samples.

There's something strange in those samples.

20 bytes only? Really? Well, very good compression achieved! 🙂 Could you add Array Size node to your handle wire to check its actual size at runtime?

[alvise]

6 hours ago, dadreamer said:

In some of your previous tests you showed that NET_DVR_SYSHEAD arrives first and is followed by a sequence of NET_DVR_STREAM_DATA packets. I can't say now, whether we really need NET_DVR_SYSHEAD to analyse NET_DVR_STREAM_DATA, but it would be useful to have both of them.

 

I thought NET_DVR_SYSHEAD was saved, but "dwDataType" always returns 2.- I have no idea why ''dwdataType'' is not returning 1. What could be the problem here?

-I try as follows, but the size of the array does not remain constant, it constantly changes between 0 and 4350

 

Edited June 5, 2022 by alvise