Jump to content

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


Recommended Posts

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.

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.

Edited by dadreamer
Link to comment
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.

Link to comment

Could it be that the callback doesn't get installed? Did you try to uninstall it after the loop ends?

21 hours ago, Rolf Kalbermatter said:

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 by dadreamer
Link to comment
21 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.

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.

Link to comment
18 minutes ago, alvise said:

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

It doesn't return "anything". That indicator only gets written to in the LV User Event case. As long as you do not see such an event in the Event Inspector Window it simply means that the LVPostUserEvent() function either was not called or not with the correct user event refnum that your user event structure is registered to.

Link to comment
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.

Link to comment
Posted (edited)

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.

image.png.4ef5d1a1cd31d4351b8cc60d7a0348cd.png

Preview CAM-6.vi

Edited by alvise
Link to comment
37 minutes ago, alvise said:

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. :)

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!

Quote

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

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?

Edited by Rolf Kalbermatter
Link to comment
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.

 

Link to comment

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.

Edited by dadreamer
Link to comment
Posted (edited)

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 :)

Edited by alvise
Link to comment
18 minutes ago, alvise said:

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 :)

Go back to this post and look at the code and the explanation I gave there!

If you want to stay with analogies, it could be also the headlights of the train that is running to roll over you. 😆

Edited by Rolf Kalbermatter
Link to comment
Posted (edited)

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.

image.png.e91de000becf0efcb0948992da13e837.png

Edited by alvise
Link to comment
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;
}

 

Link to comment
Posted (edited)

No, no changes have been made here.

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

 

Edited by alvise
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.