Fab

This post is kind of old, I don't know if JGCode released his project API, so my apologies if this is already somewhere else. I just wanted to add a note here in case someone else tried to use the project API. The tags used in the build specification for the version have changed. JGCode uses inside "Executable Get Version_jgcode_lib_labview_project_api.vi" : App_fileVersion.major App_fileVersion.minor App_fileVersion.patch App_fileVersion.build at least on the version I am working on now (LabVIEW 2012) the tags are: TgtF_fileVersion.major TgtF_fileVersion.minor TgtF_fileVersion.patch TgtF_fileVersion.build Also, this is only useful in development mode, because as MJE showed in this post: http://lavag.org/topic/15473-getting-the-version-of-a-build-from-the-project/?p=93474 you can use that vi to extract the actual exe version at run time.

We were planning on wrapping the DLL with the VIs and not exposing our users to the pain... but basically what you are telling me, is that from now on, I would have to keep building a new version of the LabVIEW driver for each version of LabVIEW, because the DLL would be version specific. We will continue to develop the driver in LabVIEW and hopefully we get to work with the C developer soon who will be developing the examples. Maybe when they start working with our DLL built in LabVIEW, they decide to make his own DLL in C... I think trying to have a single source was a nice thought but it will be more pain than gain. Thanks for all your help. Fab

How can I test the DLL? We wanted to use it in our LabVIEW code so we would have a single DLL for everyone and like I said earlier, to make it easier to replace in the future if they decided to build a DLL in C. But it seems, from what I am reading, that this will be more pain than gain, right?

Wait, I am building the DLL, does this mean that I have to build two versions of the DLL, one in a LabVIEW 32 bit version and one in a LabVIEW 64 bit version?

C calling convention it is and we won't try to get fancy with memory management. Thank you guys, I think we are going to learn a lot (probably more than what we wanted/expected) about DLLs

Eventually the DLL will do serial calls, so yes we will be dealing with byte arrays that might have null in between.

Thanks Rolf for the detailed reply. I will then use the approach that has worked for us so far: Define the VI Prototype for the DLL function to use C string pointers and then on the VI wrapper VI that will call the DLL change the function call definition to use a byte array initialized to a certain size as an input and use the byte array to string from the output. Thanks again, Fab

Hello, Before, going any further let me answer the question that I know you will ask: "Why would you want to do THAT?" We are creating a LabVIEW instrument driver for a new instrument. The instrument manufacturer wants to provide also an instrument driver in the form of a dll. They are aware that if the DLL is built with LabVIEW the end users will need the LabVIEW RunTime Engine and they are OK with this. (At least for now). So, LabVIEW users will get a LabVIEW palette API installed in their palettes that will let them communicate with the instrument. Other developers would get the DLL directly. We figured that it would be best to "eat our own dog food" and use the same dll we will create for the C developers as the basis for our instrument driver. This way we can test the dll as we go and if there is push back from the instrument manufacturer's customers to move away from requiring the LabVIEW RunTime Engine, we could replace the DLL built in LabVIEW by one created in C and the rest of the LabVIEW palette API code would still be the same. Cool, now, what do you need from the great LAVA community? We have been looking for documentation on how to do this and there is not much we can use. Our main question is What's the best way to configure the function prototype for a DLL built in LabVIEW so that a string (or U8 array) output of unknown size will not require arbitrarily-sized pre-allocation by the caller? Is this even possible? The main problems we have encountered so far: 1) Getting only the first two bytes of a string output from the DLL function --> Solution: even if the DLL function call has the string inputs and outputs defined as "C String pointers", when we call it in LabVIEW we change the function node call parameters definition to expect an array of 8 bits Unsigned Integers. This lets us initialize an array of uint8 of the size we expect and then use the byte array to string from the output. However it requires that we pre allocate an array by initializing the array of uint8. Question: Would defining the string as a "Pascal String Pointer" remove the need to know in advance how large the string needs to be. We haven't been able to make this work. Is the use of Pascal String Pointer recommended? If it is, how should we handle the DLL source code and the "Call Library Function Parameters"? 3) We have found on several NI forum posts reference to LabVIEW.dll calls that could make our life easier by providing us access to the LabVIEW Memory Manager (for example DSNewPtr()). These functions are documented in some places, we even found one of them in the LabVIEW 2012 manual (http://zone.ni.com/reference/en-XX/help/371361J-01/lvexcode/aznewptr_dsnewptr/) Question: Do we need these functions? If we do, would they be used inside the DLL source code or to manage the inputs/outputs of the "Call Library Function Node". If we need them where can we find more documentation about the use of these functions? 4) We are defining the VI Prototypes for our DLL to use "C Calling Conventions" the other option is "Standard Calling Conventions". The help says: Standard Calling Conventions—Sets the function prototype to use standard calling conventions. C Calling Conventions—Sets the function prototype to use C calling conventions. This radio button is enabled by default. Question: Despite the accuracy of the help description ... well ... are we doing the right thing by using the C Calling Conventions? Any help will be appreciated. Thanks in advance for your time, Fab

It is possible to request to present the regular 4 hours CLA exam again for re certification if one doesn't like multiple choice exams. Remember that anyone who is going through the CLA-R had to do the 4 hours CLA first and even before that the 4 hours CLD test, which I agree neither of them should not be taken as the only indication of someones capacity, but it is a good filter. Personally, before hiring someone for a job I ask them to show me their code.

I know people that have paid out of their own pocket the expense of getting the certifications and even the expense to come all the way from the UK to Austin to attend the CLA Summit, because they saw it as a way to better themselves and their careers. Actually, one of the guys I have in mind was even able to find a better job thanks to these efforts. So, you could see it as an investment. And there might be other avenues to get your CLA. BTW, it was great to hear some of your discussions with other CLAs at the last summit. As one of the nerds in question I take offense and I really hope nobody follows your advice and I really don't want to see my fellow CLAs in lycra

Val, One of the advantages of being my own boss is that I already convinced her to let me go not only to one, but both! Fab

I didn't want to hijack this thread. So I started a new one: how to convince my boss to send me to the cla summit The re-certify for free won't be of much help to you, but maybe some of the other ones. Let me know if there is anything else I can do to help. It would be great to see you either at the CLA Summit in the Austin, TX the one in Paris, France or both Regards, Fab

I thought we could start listing some of the things others have used successfully to convince their bosses to send them to the CLA Summit. Here are some of the links I recommend: The official NI page: www.ni.com/cla-summit says some of the advantages are that you get the opportunity to: " Network and exchange best practices with other CLAs, NI executives, and engineers Preview and influence the LabVIEW roadmap and unreleased product features Meet one on one with NI R&D developers Recertify as a CLA for free " Also, Justin Goeres did a great blog post with the 5 reasons you shouldn't miss the CLA Summit And Chris Roebuck, Europe CLA Summit chair has his own variation of the 8 reasons you shouldn't miss the CLA Summit Any other ideas out there? I hope I get to see all of you who are already CLAs there. Regards, Fab

This is great news, I am looking forward to seeing you at the CLA Summit in Paris.

Congratulations! Since the grades are not posted anywhere and you need 70 to call yourself a CLA, I think that anything above that is cherry on top But I do agree with you I would like to know which questions I got wrong just to further my understanding of the product or so they fix the exam if the questions are bad questions.