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.

My assumption is that if you already have MKL Runtime installed (I see that it is so), then your PATH environment variable should contain full path to the \bin\ directory of the MKL parent directory (as stated in mklvars_intel64.bat or mklvars.bat). But I have never compiled DLLs with MKL linking, so you better to ask on some C/C++ forums or stackoverflow or experiment with it on your own.

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.

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 😉

4 hours ago, JKSH said:

Actually, your earlier screenshot shows https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html

I know. I followed this phrase.

But it no longer matters after Jim Kring's message.

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.

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

3 hours ago, Youssef Menjour said:

are there routines to integrate into my code in order to remove these objections?

In fact your app requires the libraries on the very first level shown in Dependency Walker. The others are needed too, but they are being loaded by their "parent" DLLs, so you don't need to worry about them. Could you collapse that DLL list on the left of the DW, so we could see the first level libraries except sycl.dll and kernel32.dll? Don't look at those red warnings as they are about not finding some libraries, which likely are loaded during the runtime or have delayed loading or could even be absent in the system (as some .NET assemblies) and the app is able to run fine without them. So if only sycl is necessary, then you could either provide the path to it in your PATH environment variable or try to put it near your own DLL and check, whether LabVIEW loads it all without errors.

9 hours ago, KumarB said:

Actually client need the license link to refer in their documents but www.OpenG.org website not opening.

https://www.gnu.org/licenses/gpl-3.0.en.html

There's the license information on almost every OpenG VI's front panel.

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.

Now you're about to debug this everything. It's going to be painful a lot! Because there are dozens of things, which could go wrong. First I would start with debugging the DLL by inserting a debug output (like DbgPrintf call or console cout) after each function, that is able to produce errors. But I'm afraid if we go this route, this thread is going to reach 50 pages, if not more.

10 minutes ago, alvise said:

Finally, this way everything should work properly, right?

Looks pretty much like it should. 🙂

Maybe the reason is that LabVIEW cannot find some DPC++ Runtime library during the DLL load process (sycl.dll for instance or another one). Could you check with Dependency Walker, which libraries are in dependencies of your DLL?

10 minutes ago, Youssef Menjour said:

Regarding the release build, I haven't tried it because I didn't understand the difference and how to make it work. Could you be more explicit?

Just switch to Release option on the MSVS toolbar. As to the differences, you may read about them e.g. here . To add to there, debug builds depend on the debug version of Visual Studio Runtime libraries, whereas release builds depend on common MSVCRT DLLs, that are very likely already installed in the system. Hence if you compile debug app or library and deploy it to machines without Visual Studio installed, it will ask you for the debug DLLs or even the whole Visual Studio to be installed. Release app/DLL on the other hand usually requires Visual C++ Redistributable Runtime only.

For "stop" frame: place Stop.vi between the CLFN and Unregister node. And as you are creating the event before the loop (Create User Event node), you should destroy it also after the loop.

12 minutes ago, Youssef Menjour said:

Where can i specify the calling convention !!! (really sorry for the question)

For MSVS - on the left of the function name, for LabVIEW - in the CLFN settings.

extern "C" __declspec(dllexport) int __stdcall Mult(int a)
{
  // will be exported with stdcall convention
}

Did you try Release build also? I noticed, that you're exporting Mult function without explicit specification of the calling convention. By default Visual Studio exports in cdecl convention. But in LabVIEW you set stdcall convention. Likely it's not the reason for errors though.

1 hour ago, alvise said:

Is there a problem here?

Seems more or less ok. But better to place UninstallCallback CLFN in the "stop" frame as you install the callback in the "start" frame. I also assume you're passing NotARefnum as Adapt to Type -> Handles by Values with cdecl convention.

Wait, I've just thought it would be good to have an organized dataflow in both "start" and "stop" frames. In "start" first do the event handling (registration etc.), then call Start.vi, then install the callback. In "stop" do in the opposite order. You may easily set the dataflow order with two ways: either with brown error wire or with Sequence Structure. There's a State Machine pattern as well, but I feel you're not ready to remake all the program right now.

15 minutes ago, alvise said:

- To begin with, is the following code correct?

No! You have to change this line:

{
    return installFunc(lRealHandle, DataCallBack, (DWORD)(*refnum));
}

to these lines:

{
    if (refnum && *refnum)
        return installFunc(lRealHandle, DataCallBack, (DWORD)(*refnum));
    else
        return installFunc(lRealHandle, NULL, 0));
}

And that's all! Do not touch anything else in the code. Rebuild the DLL then.

@alvise Leaving the lyrics behind, so you got the DLL compiled along with the changes proposed by Rolf? If yes, have you made UninstallCallback VI based on InstallCallback VI with minor changes, proposed by Rolf? If yes, did you put that new VI inside your program and run the test playback again?

23 minutes ago, alvise said:

No, no changes have been made here.

Why not? 🥴

1 hour ago, alvise said:

Of course I tried that, no difference.

These modifications were made as well?

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;
}

You still did not apply UninstallCallback to your VI. This may help or may not. I can't say now, what's the reason behind your problem. When you will be ready to test with UninstallCallback, restart LabVIEW completely to begin with fresh resources.

And as you already are getting stream's binary data, save a single NET_DVR_SYSHEAD (1) packet and a single NET_DVR_STREAMDATA (2) packet to two separate binary files, so we could get a chance to look at the format. Use a Case Structure to differentiate them. Save one packet only, if possible, not two going one after the other. Post them afterwards.

I assume you may easily find all these packages on SourceForge, e.g. this is a page for oglib_error-2.0-1: https://sourceforge.net/projects/opengtoolkit/files/lib_error/2.0/