crelf

QUOTE (george seifert @ Jan 14 2009, 02:10 PM) Which is, essentially, a tab control

QUOTE (george seifert @ Jan 14 2009, 02:10 PM) Which is, essentially, a tab control

QUOTE (TobyD @ Jan 14 2009, 11:11 AM) Right - all UI tabs that I know of do it, and while it may be initially unintuitive, the fact that they all do it eventually makes it intuitive

QUOTE (TobyD @ Jan 14 2009, 11:11 AM) Right - all UI tabs that I know of do it, and while it may be initially unintuitive, the fact that they all do it eventually makes it intuitive

I think the issue is that your question is either vague or doesn't make sense. What do you mean by "drive" and can you eloborate on what type of pattern matching you want to do?

QUOTE (jdunham @ Jan 12 2009, 11:22 PM) That's actually what I've ended up doing QUOTE (Ton @ Jan 13 2009, 02:44 AM) ...your installer folder will be filthy after a few builds, what if your code changes and you don't need a DAQmx installer to be compiled into the installer? I think changing support component requirements is a special case, and could be handled appropriately. All of the installer builds I've done have either kept the same number of installer components, or increased them - never reduced them. QUOTE (Jim Kring @ Jan 13 2009, 08:58 AM) ...then I can't help but not make any mistakes. What, you couldn't fit another negative in there to make it more confusing? QUOTE (Jim Kring @ Jan 13 2009, 08:58 AM) As time goes by, your SOPs will become embodied in reusable code used in your build VIs -- heck, you could even package these up using VIPM, so that you don't have a custom builder for each project True - and that's what I'm thinking of doing for pre- and post-build hooks. ...but I'd still like to be able to define those in the LabVIEW builder

QUOTE (Jim Kring @ Jan 12 2009, 09:27 PM) True - thanks for reminding me of that. That said, maintaining a custom builder for something this trivial is a pain when you work on many many projects and have more than a handful of developers. I suppose I could make it a standard operating proceedure, but I'd prefer it if the LabVIEW installer builder didn't go around deleting files it doesn't own. Anyone from NI care to comment?

QUOTE (xtaldaz @ Jan 12 2009, 07:16 PM) I used to use VSS a few years ago, and it pretty-much sucked I do really like the subversion and Tortoise/SVN combo, although little things like this still bite me from time to time. That said, VSS used to leave those wee *.scc files everywhere, so I assume it would have suffered the same fate from the LabVIEW installer build process. QUOTE (Justin Goeres @ Jan 12 2009, 07:44 PM) If I need to commit something, I commit a zip file of the installer. I thought of that too. I mean, it's a built product, and there are methods of keeping a zip traceable, so maybe that's my answer. It's a pain to add that extra step though... QUOTE (Justin Goeres @ Jan 12 2009, 07:44 PM) A while back, Omar pointed me to http://sadilek.blogspot.com/2007/07/restore-svn-in-keynotepages-documents.html' rel='nofollow' target="_blank">a script that restores the missing .svn stuff that has solved that problem for me. It's an OS X(/Linux/Unix) shell script, but it could be pretty easily replicated in a Windows batch file. A custom batch file is certainly an option, but I'd need to be able to have it run automatically pre- and post-build. Anyone got any ideas on how to do that? In fact, pre- and post-build hooks would be very useful (eg: build some documentation, etc).

QUOTE (mesmith @ Jan 12 2009, 06:03 PM) Thanks for the great comments Mark. I had thought about not including installers in SCC for that very reason, but we work in regulated industries where rebuilding something (even if we can proove that nothing has changed between builds) isn't something that we can do It's good to know that I'm not the only one with this issue :thumbup:

I've been having an issue with building installers screwing with my local SVN files. Say I build an installer, and then add/commit all of the generated files to source code control. Then, the client wants a change, so I lock all my installer files, and rebuild. The LabVIEW installer *deletes* the files and folders in the target location and creates new ones. That's where the issue begins: the LabVIEw installer not only deletes all the previous built files, but also all the SCC files in their folders, so Tortoise/SVN gets awfully upset and complains about orphan locks (essentially missing local files). I assume that this is also an issue with other SCC providers that have local hidden files to keep track of things. Bug, or feature? This method of building/SCC has been around for a long time - how do you all get around it?

:thumbup:

What do you want from it? Are you looking to get a clock source that you can synchronize with? If so, check out NI's timing cards that can synch chassis. If you're just interested in getting some of the info from th data stream, maybe talk to NVSI - if I remember rightly, they worked on a IRIB LabVIEW toolkit a few years ago.

QUOTE (mic_k86 @ Jan 9 2009, 10:11 PM) Search the help for creating an installer. Building an application "converts" the vi to an exe, creating an installer helps you put the exe, support files and other files (like your lvm) in the right place on the target system.

QUOTE (javalite @ Jan 9 2009, 11:56 PM) Can you show us a screen shot of your functions palette?

QUOTE (hariprasad @ Jan 10 2009, 03:50 AM) I've seen some of the stuff that Apna Technologies and Solutions does - from what I've seen, they do good work. QUOTE (hariprasad @ Jan 10 2009, 03:50 AM) Even though i learnt about that in subjects, i want know thier status in the real world and i am absoultely blank about cost of the lab view software and its features... What is it that you want to know, exactly? If you're looking for some general info about what LabVIEW is and what it can do, have a look here, here and here.

QUOTE (Phillip Brooks @ Jan 9 2009, 01:42 PM) I don't think you can get the context help window contents to update without loading the VI into memory. Here's something I used once to get the info of a subVI into the context help window: http://lavag.org/old_files/monthly_01_2009/post-181-1231529544.png' target="_blank"> Then the context help window will update when the user mouse-overs the Boolean. It's kind-of a hick, but it worked for the situation I was in back then.

QUOTE (mic_k86 @ Jan 9 2009, 10:19 AM) Search the help.

QUOTE (Aaron L @ Jan 8 2009, 10:52 PM) Oh - okay. That makes it clearer. QUOTE (ned @ Jan 9 2009, 08:28 AM) What you want is something like the PCI-6601, which provides digital IO and counter/timer channels with pulse generation outputs. Yep - like others have said, you don't want to try to do the 20kHz clock in software, which is what you'd have to do with the USB DAQ modules you listed. You want to choose a device that has the clock generator as a chip on the device where you set the initial variables, start the generation, then just adjust the variable that you're interested in. Because you want to adjust it using a FP slider, then you're not trying to adjust it very quickly, so ned's right - the 6221 would work great.

QUOTE (TG @ Jan 8 2009, 12:58 PM) Go ahead - that's what LAVA's here for!

QUOTE (Aaron L @ Jan 8 2009, 07:53 PM) Buy a stepper motor controller - they're gauranteed to output what you need, they're easy to control, and they'll work out of the box - lower your engineering anxiety and get the right tool for the job.

QUOTE (hooovahh @ Jan 8 2009, 11:56 AM) Gilligan's Island was before my time

QUOTE (Yair @ Jan 7 2009, 01:48 PM) I don't know the official channels that should be used for contacting NI customer education about issues with their exams, but I usually just email David Corney directly (using the standard NI firstname.lastname@ni.com email address format). He's a great guy, and is really keen to get as much community feedback on customer education as possible. So, with that in mind, you all now have a contact so you can actually do something about it instead of just posting here. He might not be exactly the right guy to deal with issues with CLAD questions, but he'll certainly find the right person :thumbup:

Apple Introduces Revolutionary New Laptop With No Keyboard

QUOTE (ASTDan @ Jan 7 2009, 09:26 AM) IMHO the CLAD, CLD and CLA all have different purposes. If you want some familiarity with the LabVIEW development environment, go with the CLAD. If you want LabVIEW development skills, go with the CLD. If you want architectural design and implimentation, go with the CLA. Since you need to work through the certifications (you can't just go to CLA without doing CLAD and CLD first), then you could say that CLA means architectural design and implementation, development skills and familiarity with the development environment

QUOTE (BobHamburger @ Jan 6 2009, 10:29 PM) I can't disagree that some of the questions are misleading and/or poorly written (just like some of my posts here on LAVA ), but when I see those issues I contact customer education and tell them what I don't like and why. Talking about them here without contacting NI directly is like reporting a LabVIEW bug here without telling NI about it, and then getting cranky when NI doesn't fix them.