kawait

QUOTE (rolfk @ May 7 2008, 02:26 PM) Thanks you again Rolf!. :worship: After I have carefully checked and modified the VI and C++ code, the VI now doesn't crash even I close it after many run cycles. Then I go ahead and write a small VI to test another DLL and get a trouble! My test VI run fine but everytime I close the VI, my LabVIEW halted...I have to force it to close it using Windows Task Manager. When I examined my VI and tried to figure out the problem, I found that it is possible to raise the error checking level of each call library function node. I think it is always a good idea to have maximum error checking during development and change the level to maximum for all the node. And I got the following error every node in my VI... I went back and checked my previous VI, and I also got the same error after I set the error checking level to maximum....With default error checking, they are all run fine. The error only happens when I set the error checking level to maximum. At this point, I believe that I have made some big mistakes that I am still not aware of. The error message suggests that there is a mismatch in calling conventions, and I am using a macro for dll export like this: #ifdef A_DLL_EXPORTS #define DLL_API __declspec(dllexport) #else #define DLL_API __declspec(dllimport) #endif DLL_API int ThisIsDllFunction(); And I setup all the call library node to use stdcall calling convention. Anyone have thought about this error? QUOTE (Sebastian @ May 6 2008, 07:00 PM) I have done the same in my master thesis project and found a solution! Use a "array to cluster" and set manualy the cluster size by a right click to the function block. Than adapt the function call to "adapt to type" and pass the pointer or handle! /Sebastian Thank you for your info. I' ve never thought of it as one of the possible solutions.

QUOTE (rolfk @ May 6 2008, 04:26 PM) Thanks for your prompt reply again! Rolf :worship: In the diagram in question 3, the called DLL function will do something and pass the result as a string (which is the forth argument, defined as char* in C function prototype). The reason of initializing an 100-element empty array and passing it as a pointer to the call library function node is that I want to allocate enough space for the string output and tell the node "Hey, I have prepared this chunk of memory space for the string output". I used unsigned int8 just because it can be directly casted to a char array. What I am not sure is if LabVIEW handles that automatically for me so that I can only just wire the output and as long as LabVIEW see the output is wired, it will allocate enough memory so I dont need to pass the empty array as the input. BTW, after I made my post here, I seemed to find out some big mistake. The explicitly call the cleanup function in my VI seemed the one which causes trouble. After I have removed the explicit call to the cleanup function my VI doesn't crash at all after almost 10 run cycles (I cant say that it wont crach though). I know it is just because I have done the cleanup of some resource too early in my DLL cleanup function and I will take further look to that. QUOTE (Sebastian @ May 6 2008, 07:00 PM) I have done the same in my master thesis project and found a solution! Use a "array to cluster" and set manualy the cluster size by a right click to the function block. Than adapt the function call to "adapt to type" and pass the pointer or handle! /Sebastian Thanks for you idea! it seems useful if I want to pass clusters to DLL functions which take structs as arguments.

Hi everyone, With the help of rolfk and others I successfully create a VI and a wrapper DLL that do what I want. But there is one problem that is annoying me: The VI CRASHES quite frequently after the first run in LabVIEW 8.5. I know the most possible cause is that there are some access violations because I am not careful in using pointers. Although I have tried my best to avoid that, I am not a very experienced programmer so I may make some mistakes that I am not even aware of. There are some questions that may help identify the problem. 1. My wrapping DLL does have a pair of functions that performs initialization and cleanup, respectively. The initialization function loads required DLLs and allocates memory for all LV data type s(string handle, int...etc) that is used in user LV event. The cleanup function does that necessary cleanup (Free DLLs, release LV data types..etc). Initially, I call the functions both explicitly in my VI, as well as in the PROCESS_ATTACH and PROCESS_DETACH section in the add_main. Is it a good way to do that? Or I should just rely either the DLL_Main or explicit call of the functions? 2. Should I write the function prototype in my DLL source code EXACTLY as displayed in the call library function node in LabVIEW? Which means using data types defined in extcode.h instead of C/C++ primitive data types (int, long, double...etc). Or it doesn't really matter as long as I know they are interchangeable? 3. For variables that are the outputs of the DLL I pass them as pointers to the wrapper DLL. In the LabVIEW VI do I have to pass something like this? In the above diagram the forth argument is the string output of a DLL (with maximum length of 100). I am not sure if I am correct if I do that. Should I pass a array control instead? Or should I not pass anything as the input and instead allocate memory for the data type using LabVIEW Memory Manager functions like DSNewPtr? 4. I found that after I build my VI as an executable and run it, it crashes MUCH LESS. (Although it still after several run cycles). Does it mean that LabVIEW 8.5 is not very stable compared to older versions of LabVIEW? (I haven't try my program in older versions of LabVIEW though) Finally, if you have any advise regarding crashes in DLL-calling VIs (pitfalls, good practices, dos and donts...etc), plz share with me. Coz your experience would probably save my life a lot Thanks in advance!

QUOTE (rolfk @ Apr 19 2008, 03:43 PM) Thanks for your info, I will spend this weekend to study the example code, If I have more questions I will post them in this board. Thanks again.

QUOTE (rolfk @ Apr 19 2008, 03:22 AM) Thank you for your detailed reply, rolf Since a guru like you have said that writing a wrapping DLL is the best solution I would definitely take the time and explore it. Even though I consider myself reasonably proficient in C/C++, I don't have much experience about Windows programming and those DLL stuff. So I need time to play around with Visual Studio and figure out how to write a DLL first (and probably get some program crashes in the process since I know that calling DLLs can be such a nasty thing ). However, because of my tight schedule I would like to know if there is any resources (from here or NI website) that can teach me how to do that quickly? Especially the techniques about translating between a callback to a LabVIEW user event (which sounds pretty cool for me :thumbup: ) I will post again in this forum if I have more question. Thanks again! kawait

Hi every LabVIEW guru, I have a bunch of DLLs that I would like to call in LabVIEW. In the quest of figuring out how to do that, I found out that I have almost all of them use function callback as a way of passing error messages. I found that there are 2 ways they do the callback: 1. There is a pair of functions called sth like RegisterCallback and UnRegisterCallback, which take a pointer to a function as an argument. I supposed these 2 functions must be called before I call any other functions in the DLL. There is the function prototypes in the header file I have. Errorcode_t mefRegisterCallback (callbackfunc_t* const func, callbackevent_t eventtype); Errorcode_t mefUnregisterCallback (callbackevent_t eventtype); 2. Another type I encounter is just functions which take a struct of pointers to functions, sth like: int __stdcall DoSomething(InputStruct *In, OutputStruct *Out, MessagesCallback *Msg) in which the MessagesCallback has the form: struct MessagesCallback { void ( *pfnErrorMessageHandler )( int, int, const char *, const char * ); void ( *pfnMessageHandler )( const char * ); char szMessage[1024]; }; I played around with LabVIEW call library function node but I think it is impossible to deal with the function callback without using some tricks. There is a post talking about similar issue and someone purposed a workaround using ActiveX server here. But since the links are no longer available I still dont know what is the workaround. I also know that you can create another DLL as a wrapper to those functions but since I dont have much experience in DLL development can someone elaborate about this? Thanks in advance.

Hi chris1983 and jhoskins, Thanks for your reply. I know I didnt tell you guys enough to figure out what happened. In my first post I just want to know if anyone had the same problem and give me some insight if someone did. Now I am going to talk more about it. Here is a screenshot of my program, take a look: There are 3 loops running in parallel, the one at the top captures mouse scroll event from WIN32 API and fires custom event. The one in the middle is just an event handler and the bottom one is a state machine. The screenshot also shows the event handler that is triggered when Tab key is pressed down. I've just tried un-checking "Lock front panel until event case for this event completes" for all events, as well as putting a wait timer (for 250 msec) in the loop around the event structure. But it turned out both didnt help solve the problem....Actually it is not a big deal as I can work around this by just placing a "dummy" control, but I still want to know what happened. I think that the top loop is the most likely to be the trouble-maker, but I can't find other ways to take advantage of mouse scrolling in LabVIEW 8. Please let me know if you know LabVIEW 8 has native support to mouse scrolling. As always, if you find something weird and awkward in my program please let me know too. I have been programming in LabVIEW for just ~7 months and I am always eager to learn from you guys out here

Hi, I put a tab control in my program just to hide some constants, non-GUI stuff. I have also set all the controls in the Vi to skip when tabbing because Tab key has a special function in my VI (I have written an event structure + key down event). However, when I run my VI and press a Tab key, my VI freezes and CPU utilization becomes 100%, I have tried anything I can think of (like setting timeout to the event structure, setting the tab control itself to skip tabbing...etc) but the only workaround is making a "dummy" control (i.e. A control which does nothing but doesn't skip tabbing). Another solution is just avoid using tab control altogether. I tried to reproduce the problem by making a simple VI with a tab control, an event structure with key down event handling Tab key, but it doesnt freeze at all even I have set all controls to skip tabbing. I can't figure out which part of my VI interferes the tabbing. Has anyone had similar issue before? What do you guys think about what is happening? Thanks

Sorry for my late post. Thanks Michael and crelf! your solution is a lot more elegant than mine.

yen and crelf, thanks for your response. Besides more informative and readable error messages, my motivation of doing all these is that I really want very robust error logging (although my application doesnt really need that now, I think it would be a valuable feature as my application gets more and more complicated). Some days ago I tried to write a set of VIs which work on top of standard LabVIEW error handling VIs. But as I was coding them halfway I asked myself "Why I need to do all these? Someone should have done this before, even LabVIEW may have this feature bulit-in". So here I am. Do I actually have to do it myself? If I have to, do you guys have any suggestion about the error logging?

Hi all LabVIEW gurus: I am a novice of LabVIEW (~6 months experience), I am writing an application to read trace data from a network analyzer and do some analyses (sth like time-domain transform, optimization...etc). I am thinking about enhancing my application's error reporting capability by including my own error codes and messages (since many times I found that the default LabVIEW error messages are too cryptic to understand). Is anyone here who found LabVIEW default error handling unsatisfactory and has done some tweakings on it? I want to learn some tips and tricks from you guys. Thanks,

Thanks for your reply! Yes, the disk space is not an issue at all nowadays. But I just want to know if I can strip off the part that is not needed, since the front panel does nothing other than passing variable in and out. Thanks for your info. Indeed, I didnt have any particular reason of usign LLBs. I used it just because I saw it is used extensively in LabVIEW library functions.

Hi all LabVIEW developers, I am developing a program that controls a network analyzer. The VIs that actually does instrument communication (i.e. calling VISA functions) are reside in a llb file, and each VI only perform a particular function (eg. reading the center frequency of a sweep). They are dynamically loaded by a toplevel VI as needed. By writing the program this way, I can add new functions later by just including the VIs performing the functions in the llb file. As I am working on it I found that this approach has a big problem: the size of those "instrument contol" VIs (in a llb file) could one day have grown very large. Now in the llb file I have getter/setter pair of 7 parameters (14 VIs in total) and the file size of the llb file is closed to 400kB. And I think I will add more and more complicated features so I am afraid that it would grow very large. As we know, much of the space of a VI is for the representation of front panel and block diagram. If I use the VIs just for distrubution and their panel are not shown, I think it is not necessary to keep that information in the VIs. It is possible to save the VIs in a more compact form (eg. just the code, not the graphical stuff). Since I am a LabVIEW novice (I started LabVIEW programming 3 months ago). I would also appreciate your comment about my approach. I would be glad to hear suggestions about how to make it better. Regards, Kawait.