Jump to content

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


Recommended Posts

All you need is to disable option "Image has Safe Exception Handlers" in Project properties -> Configuration Properties -> Linker -> Advanced tab. Why are you trying to adjust Debug config, when you're on Release one?

Link to comment
Posted (edited)

 

17 minutes ago, dadreamer said:

All you need is to disable option "Image has Safe Exception Handlers" in Project properties -> Configuration Properties -> Linker -> Advanced tab. Why are you trying to adjust Debug config, when you're on Release one?

After selecting it as a release again, I built it.
I just missed it. I fixed it.

ok. now .dll file has been created.

image.png.b536dc097802a6f2328fddc33b111391.png

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

To export functions like here, it is necessary to make changes in the code, right?

Yes. Your code does already have all that necessary stuff for export:

#define LibAPI(retval)       __declspec(dllexport) EXTERNC retval __cdecl
#define Callback(retval)     __declspec(dllexport) EXTERNC retval __stdcall
// ...
Callback(void) DataCallBack(LONG lRealHandle, DWORD dwDataType, BYTE *pBuffer, DWORD dwBufSize, DWORD dwUser)
{
// ...
}

LibAPI(BOOL) InstallStandardCallback(LONG lRealHandle, LVUserEventRef *refnum)
{
// ...
}

Hence it's rather odd that nothing is exported. As you're using __declspec(dllexport), no need to use .def file - you may disable it in the settings.

Maybe your functions are exported, but have decorated names... In this case LabVIEW won't show them. Could you check full export table with some tool like Dependency Walker or similar?

Edited by dadreamer
Link to comment

I don't see the functions prototypes declared anywhere in the source. Maybe this is the reason. Try to add them right after the last #include directive.

Callback(void) DataCallBack(LONG lRealHandle, DWORD dwDataType, BYTE *pBuffer, DWORD dwBufSize, DWORD dwUser);

And

LibAPI(BOOL) InstallStandardCallback(LONG lRealHandle, LVUserEventRef *refnum);

 

Link to comment
10 minutes ago, alvise said:

There is no problem here, is there?

There is! Alter the function declarations and add these prototypes.

extern "C" __declspec(dllexport) void __stdcall DataCallBack(LONG lRealHandle, DWORD dwDataType, BYTE *pBuffer, DWORD dwBufSize, DWORD dwUser);
extern "C" __declspec(dllexport) BOOL __cdecl InstallStandardCallback(LONG lRealHandle, LVUserEventRef *refnum);
Edited by dadreamer
Link to comment

You may trash down Release folder and rebuild the project in Release config. Or leave it as is. But when you will distribute your app onto another machines without Visual Studio installed, your library will ask for the debug version of MSVC Runtime.

Link to comment

You better rework Rolf's example a bit to not reinvent the wheel.

1. Remove this as no longer needed.

2022-05-30_17-39-26.jpg.b50b1db30f05158a0e76a0f31591136a.jpg

2. Remove this Case Structure and that VI Ref terminal. Pass NULL (0) as hPlayWnd.

2022-05-30_17-40-46.jpg.7af936e80d64a4f473dcf2aad847fe44.jpg

3. Before the While loop create User Event of cluster type, containing these three fields:

typedef struct
{
	LONG realHandle;
	DWORD dataType;
	LVByteArrayHdl handle;
} LVEventData;

You should set handle type as U32, if you're working in 32-bit LabVIEW only, or U64 in all other cases.

4. In "Start" frame of the Event Structure right after Start.vi put CLFN with InstallStandardCallback function call, set it properly and pass two parameters to it - lSession from Start.vi and your fresh UE reference.

2022-05-30_17-57-20.jpg.b21f18075f7cd71e13e31fc22f79a994.jpg

5. Activate Dynamic Events terminals on your Event Structure and set it to accept your User Event. Also here register for events and pass the event refnum to the right terminal.

6. In "Stop" frame of the Event Structure unregister for events.

7. After the loop destroy the UE.

Now after running your program and pressing "Connect" + "Start" buttons you should receive some events (if no mistakes made). Check Event Inspector window to make sure.

Edited by dadreamer
Link to comment

Don't pass Event Registration Refnum to the DLL! Pass Event Refnum.

2022-05-30_21-21-00.jpg.14123817a2e2e69c31a2c671387132ba.jpg

Also you need to pass this wire through all the frames of the structure, because when the loop will be stopped, Destroy User Event VI will be confused getting invalid refnum. Or wire it around the loop instead. Oh, first do unregister, second do destroy, in that order.

Moreover your calling convention is wrong!

Plus you didn't insert an User Event frame where you're going to catch your events.

! Reg Events, Unregister and Destroy should be either outside the loop completely or inside the "Start" (for Reg Events) and "Stop" (for Unregister and Destroy) frames ! Otherwise the UE will be created and freed on each iteration.

Edited by dadreamer
Link to comment
Posted (edited)

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?

 

 

image.png.58865ed32fd51f3384e9d5667a9ed79d.png

Preview CAM-1.vi

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

What is the reason why the Handle value is sometimes flickering on the screen?

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?

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

 

image.png.bbe34d46bba49d29906acfe3b8036908.png

image.png.a8e317ab2702b5bb536df61437563694.png

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.

image.png.1da1994c85711fa20662344768acda44.png

Link to comment

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