Fab
-
Posts
193 -
Joined
-
Last visited
-
Days Won
15
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Fab
-
-
I know it's hasn't even been a week since NI Week ended but does anyone know about the availability of presented slide material? Throughout the conference I would hear presenters say something like "All this material will be available online". So my question is will there be an aggregate place similar to this one for presentation material? And if so when can we expect to see it?
Last year they were posted at https://decibel.ni.com/content/groups/niweek-2012?view=documents
I don't see a niweek-2013 community yet, I guess we will get a notification in the next couple of weeks
-
Hello everybody,
If you downloaded the videos before today, you don't have the video of my presentation.
Mark just uploaded the video for my presentation. We removed the demo part, my customer requested to wait until they release their product. As soon as they release it, we will post the video in its entirety.
Thanks,
Fab
-
He should get a raffle ticket.
I agree, but be careful what you wish for, he might win your BBQ and you'll have to ship it to Australia
-
Staab Engineering will ship you a vacuum-sealed Texas BBQ brisket from La Barbecue.
http://www.yelp.com/biz/la-barbecue-austin
About $- value, depending on where I have to ship it. I hope crelf doesn't win!!!
Maybe you are lucky and someone in Austin wins it
-
1
-
-
Following tradition, Delacor got a signed LabVIEW book. This year is Effective LabVIEW Programming.
For a preview of the contents take a look at the book's web page, http://www.ntspress.com/publications/effective-labview-programming/
It's expected to be published by the end of July.
Rumor has it that Tom Bress will be at the LAVA BBQ, so he might be able to add a more personalized message then.
See you at the LAVA BBQ,
Fab
-
1
-
-
Is there a post to start talking about door prices? I have one for this year.
-
1
-
-
Still waiting for my goddamn tshirt...
They sent an e-mail update a couple of weeks ago that they were having problems with some people moving or changing their address. If you didn't get it, let me know and I can send you the e-mail where to ask for an update.
Sorry you haven't gotten it. I hope you get it on time for NI-Week
-
I think that maybe a tool to analyze dependency links would be helpful. Not just for this type of issue either. In a couple of our projects I end up saying "why is that class being pulled in"? Many times you end up with a "uses a" relationship with another class (static vi reference, passing a class into another class's method). If you could visually and programatically inspect your class relationship it would be great. I am wondering what Symbio tools would do with the weird setup I had going (we don't use them). A tool like that would be pretty nice for code reviews. Just a simple representation of classes, lvlibs, and xcontrols in your project and some red flags for circular references.
If I had some spare time...
I use the Symbio tool to reverse engineer some projects and discover those links. However, for large applications it does not work so well or when there are weird relationships. I don't know if it would have worked with the relationships you had.
-
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.
-
2
-
-
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
-
Well. You don't have to. But if you don't, then those with LabVIEW64 bit won't be able to use it (that's assuming you are only supporting windows ).
You are much better off leaving the LabVIEW code for LabVIEW users (and then it will work on all platforms including Linux, Mac etc) and just compile a 32 bit DLL for non-LabVIEW people and worry about the 64 bit when someone (non-labview) asks/pays for it.
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?
-
And make sure they supply you with the 32 bit & 64 bit versions. Most suppliers think that only the 32 bit is sufficient since 32 bit software can be used in windows. However. LabVIEW 64 bit cannot load 32 bit libraries!
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
-
I took my CLA-R today and have to say that it was really frustrating. Ambiguous scenarios, questions that used double-negatives in their wording, and references to materials I'm confident I never saw in my 8 hours of studying the AAL and MSEL course texts yesterday. All that aside, the very most frustrating thing was the realization that this exam did nothing to test my capability as the architect on a software development team. Rather, it tested my attention to the (often self-conflicting) details of NI's training products on (1) software project management, (2) minutia that can be figured out by clicking around for 30 seconds if you happen to run into them while coding, and (3) features of LV that 95% of its users never ever need or want.
Given the nature of this test, I honestly don't think I can use someone's CLA as evidence of their capability to help me design a complex solution to a client's problem. I'd say a CLD is a more valuable litmus test for LV developers; shame a more aggressive weeding out of those skills hasn't been codified yet.
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.
-
1
-
-
To be clear I'm not a CLA and I don't ever see myself getting sponsorship to obtain one.
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.
Before the summit started I was not the least bit interested in obtaining any certifications. It's fair to say the summit was the only reason I did pursue my CLA. (Though now that I have my own business there are other reasons to maintain it.)What kind of "sponsorship" are you referring to? If it's just someone to pay the fee, I took all of my certification exams free of charge. They were offering CLAD exams free at a local Dev Days, and my local reps comp'd me the CLD and CLA exams for doing user group presentations.
Seriously... Architectural Summit >> NI Week.
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.
Like Comic-con (nerds) without the babes in lycra
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
-
Fab,
You could just bribe yours with a Jalapena Margarita at zTajas....
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
-
BTW, I've not asked my company to send me to the CLA Summit yet, what do you think I should say to convince them to send me there?
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
-
2
-
This is great news, I am looking forward to seeing you at the CLA Summit in Paris. -
I just got my result back from my CLA-R, and I passed
, but not with 100% :-(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. -
Hello
I have just passed the architect exam, and I just wanted to say that I have learned a lot from the posts on this site. Many thanks all.
A special thanks to the lava member FAB to came over to the UK from the US to do the advanced architectures course at NI and was by far the best lecturer that I have had there.
Congratulations!!!
Thanks for the compliments, I am blushing
So, I guess I will see you at one of the CLA Summits next year?
Fab
NIWeek 2013 Videos
in NIWeek
Posted
Thanks for the link, they don't have all the presentations up yet