LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabView user-event from external dll source

Most likely you have an alignment problem. Visual C (and many other 32 Bit Compilers) use a default compiler alignment of 8 bytes. That means every element in a cluster is aligned to a multiple of the smaller of the two, the element size and the comiler alignment. For a double this means the double is therefore aligned to a multiple of 8 bytes. If this double follows the string handle, this really means that you have this layout in memory:

 

typedef struct {

   LStrHandle string;

   uInt8 filler[4];

   double num;

};

 

LabVIEW however always uses byte packed structures, without any alignment (well except in older versions on Sparc, since the Sparc CPU has a pretty bad performance for unaligned access).

 

There are two ways to change the alignment that the C compiler is using:

 

1) with a command line switch changing the default alignment of the compiler, this might be undesirable as it could give trouble with other external libraries you are linking too in your code.

2) and with a pragma in the code such as:

 

/* Set byte packing alignment */

#pragma pack(1)

typedef struct {

   LStrHandle string;

   double num;

};

/* Reset to default alignment */

#pragma pack()

 

Of course exchanging the two element in the cluster would also fix this issue, since the LStrHandle will be either aligned to 32 Bit on 32 Bit platforms or 64 Bit on 64 Bit platforms which follows in either case directly after the double.

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
0 Kudos
Message 31 of 56
(1,692 Views)

That worked great, thanks!

0 Kudos
Message 32 of 56
(1,669 Views)

Hello LV DLL Event Professionals!

 

I got exactly the same task to be solved. I have to create a CAN Message Handler, which is triggered by a windows event, when a message is received. 

I have to use the PCAN USB device with the PCANBasic.dll

 

Please forgive me. Im not really deep in using DLL with LabView and I never used the WIN API to influence my LV programms.

 

Generally I understood your explanations, but there are a couple of things which are not clear to me:

 

 

1. What is the correct way to call the kernel32.dll (I expect "Call Library Node") but which are the correct parameters to call the functions "LoadLibraryA" and "GetProcAdress"? And how can I progress with the return value

 

2. How do I correctly call the "PCANBasic.dll" with the fpointer of "generate_event"?

 

3. I dont know how the mechanism works, which triggers the event within the "PCANBasic.dll". How can I set up the connection between the "CAN.dll" and the "LabView PostEvent.dll" to be triggered exactly when a message is received?

 

 

 

I know that the topic is quite old, but the problem is still is not Smiley Wink

 

Thanks for your time and support

 

 

Andy

 

0 Kudos
Message 33 of 56
(1,162 Views)

You can not create a function in LabVIEW that can be passed to a DLL function as callback pointer!

 

You have to create an external DLL (yes in C(++)) that provides this function and then calls back into LabVIEW by calling the PostLVUserEvent() API. However when you create an external DLL anyhow you will also do the rest of the setup in that DLL, so the question of how to call LoadLibrary() and GetProcAddress() in LabVIEW is basically meaningless.

 

As to how the PCANBasic.dll would post data back to an application, I'm not sure there are several different ways the developer of that DLL could have chosen to do this and I'm not familiar with this API since when using CAN I do go with NI hardware which avoids all these hassles completely.

 

Considering that you admit to have limited C and DLL knowledge it's highly advisable to abandon this route and go with an NI hardware device too. The extra cost of an NI interface is easily offset by the installation time for the C development environment alone, let's not talk about getting familiar with C and your development system and understanding callback mechanismes in more detail, which in fact is one of the more advanced C programming exercises anyhow.

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
0 Kudos
Message 34 of 56
(1,155 Views)

Thank you for your reply.

 

Seems that I really didnt understand the thing at all Smiley Happy

 

But excuse my curiosity...

 

I supposed that there is at the end the LabView DLL which is triggered by the external DLL to fire the PostLVUserEvent() to be able to be handled by an event handler within the LabView Application. Please correct me if Im wrong.

 

I only want to understand the right meaning of the "triangle picture", which andre buurman showed on page one of this post. There is the C++ DLL, the LabView DLL and the LabView Application. It seems I do not understand the right order of execution of the three parts.

 

 

Thank you for your patience.

 

Andy

0 Kudos
Message 35 of 56
(1,145 Views)

The solution from Andre with the LabVIEW DLL is although possible, a very undisirable solution in terms of complexity, maintainability and performance. I strongly recommend to NOT use it. However if you use that solution the LVPostUserEvent() function is meaningless since your LabVIEW DLL will simply contain the LabVIEW primitive to trigger the user event instead of trying to call that C API.

 

LVPostUserEvent() is only useful for a C dll that wants to post an event to LabVIEW and the way this happens is normally that your C DLL provides a callback function that you can pass to an different API to be called an on invocation it call LVPostUserEvent() with the LabVIEW native data format of that event.

 

Another possibility is that an external component is not using a callback function but Windows messages in order to send events to another application. Here you need to intercept those messages in LabVIEW which requires also a C DLL to be written.

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
0 Kudos
Message 36 of 56
(1,122 Views)

Hello Andy,

 

The correct order is that the LV application loads the callback_functons.dll (LV build) with "LoadLibraryA" and uses "GetProcAddress" to get the function pointers to pass to the third party DLL.

 

The implementation of the callback_functions.dll doesn't support direct posting of a user event with a reference passed to it by the LV application. (although that is what I noticed when upgrading to a newer version of LV than I used in 2008). My solution was more a quick and dirty approach re-using an interface I already used in the application. I added a TCP/IP link between the callback_functions.dll and the LV application, an d had the TCP/IP end point trigger the user event.

 

The basis for this architecture was the choice to separate responsibilities, by defining an interface with the third party DLL provider that allowed the third party provider to develop without having to know the application it is used by.

Regards,
André (CLA, CLED)
0 Kudos
Message 37 of 56
(1,106 Views)

Guys,

 

I am developing an application with NI cDAQ-9188 hardware and LabView 7.1, now that I just received the hardware I realized that it doesn´t have support for my software. I am not able to upgarde my developing software right now, so I trying to use de C libraries to make the interface.

 

What I plan to do is to build a C DLL which wraps the DAQ functions and then call the DLL from LabView 7.1. I am facing the call back problem, so my approach would be PostLVUserEvent. Since I have a deadline I would like to know if I am in the correct route. I have been programming with LV for several years (but never with DLL), I know a little C and I am also a Java programmer familiar with the callback concept, do you guys think that I'll be able to implement my solution in one week?.

 

Thanks

 

Roberto. 

0 Kudos
Message 38 of 56
(1,090 Views)

One week! Just for the callback interface or the entire DAQmx C DLL? For the callback alone it should be certainly possible even with not to detailed C knowledge but if you need to write the entire DAQ code too, then I would hesitate to say that is feasable. Debugging DAQ can be a tedious process even in LabVIEW but doing it in C is quite a bit less comfortable. In addition to the issues about having to call all the DAQmx function with the exact right parameters and order, you get additional problems about having to manage every single byte of data you plan to use as well as the extra steps involved in the typical write code, compile, test, single stepping through the C code, abort and edit and do the compile, debug, abort, edit cycle over and over again. Since you have not only logical error opportunities but also memory access error opportunities, your typical debug, modify cycles are not only more time consuming but also tend to be many more times than in LabVIEW.

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
0 Kudos
Message 39 of 56
(1,082 Views)

I want to be able to perform some few I/O operations. I need to measure pressure, temperature and send 0-10 VDC signal. I'll implement just what I need. What do you think?

0 Kudos
Message 40 of 56
(1,078 Views)