Jim Kring

A VISA resource will coerce to string. See the following illustration:

They're so tricky. Here is the new link:

http://labview8.ni.com/evaluation/labview/pc/labview_80.exe

• LabVIEW 8.0 Evaluation
  
• LabVIEW 8.2 Evaluation
  

Can be activated after the expiry to a full version upon purchase.

• Complete list of LabVIEW Evaluation Software.
  

Have fun

Thanks,i have read it. I can use the "typedescriptor" to judge what data type the variant contains. but , how about cluster?? we can see the types contained in a cluster,but we can't create a cluster by the types,at least i can't. because the parameter "type" of "Variant to Data" need a real cluster not a typedescriptor.

Thanks,your vi is nice.i can analyse the types contained by a variant. But how to use the type descriptor to create real controls??

You need to parse and construct data strings and type descriptors. This is not trivial. You might as well use the OpenG tools -- why do you think that you shouldn't use them?

Thank you,but i don't wanna use OpenG in my program, is there another method?

Yes, you can read "<LabVIEW>\manuals\datastrg.pdf" and write your own tools.

Hi,

I wrote a sub VI whose parameter is variant. and i must convert this parameter to normal by "Variant to Data" function. How can i know which type this variant will be?? As the following figure shows,the variant may contain totally different types ,how to set the "type" of "Variant to Data" function as what i need??

Download OpenG Commander and install the lvdata package. This has tools for variant introspection and manipulation.

The new license (NISLA - July 2005) is now available on the NATIONAL INSTRUMENTS SOFTWARE LICENSE AGREEMENT page on NI's website. I am happy to say that the non-compete verbiage has been removed.

You can read more of my thoughts on the matter here, on my blog.

Here is a programming challenge: Make the traversal routine generic, such that it accepts a callback (plug-in) VI reference, which is passed each object reference during the traversal. Let the plug-in VI decide what to do with the object reference -- in this case, it will determine if the object is a CBR node, and add it to a list.

Hello Justin,

You could use an ActiveX Screen capture tool. For example: My Screen Capture ActiveX 1.20. Here is a quick and dirty example (attached). I wasn't able to do a direct memory transfer of the image, but I was able to transfer via disk (BMP file). If you need this to go faster, you could create a RAM disk.

Download File:post-17-1129047931.vi

Easy enough to find them:

This routine will only work for CBR nodes that are directly on the block diagram. If they are located inside of other structures (like Case or Loop Structures), then they will not show up in the AllObjs[] list. You will need to recursively traverse the hierarchy of objects on the diagram, in order to make sure that you have looked in every location for the CBR functions. I don't have time to create an example; but I'll try to later, unless someone beats me to the punch.

Does somebody that beta tested know what the new icon on the block diagram icon bar is (and what it does)? I believe it's between the lightbulb and the debug-start arrow... it's in some of the Flash presentations on ni.com.

Retain Wire Values causes wires to remember the last value that flowed through them. This allows you to probe them and see the value, after the VI has finished running.

I use LVDiff -- it only facilitates in comparing the two VIs by highlighting the differences. We cannot merge changes from one VI into another, like we can with text files (C/C++, for instance). Merging VIs automatically would be quite involved.

Yes, sorry if I overstated things... but, LVDiff really helps you find the difference points and merge manually.

I like the check-in/check-out paradigm because my team mate then knows I am working on it. And he can either wait for me, or come talk to me. In update/commit, I am guessing we would end up manually merging changes from one into another.

I guess it all boils down to personal preference.. and/or company policy.

If you have a chance, I recommend taking Subversion for a test drive -- I gaurantee that you will like TortoiseSNV (if you are a Windows user). You can quickly test it out, using a local repository (doesn't use a server, but rather, a location on your hard drive as the repository). Regarding company policy... well, I can't help you there However, you could use another SCM system for your day-to-day work, and then push your code to the official corporate repository once you have achieved milestones.

Don't be such a snob.

I didn't intend to imply that anyone wasn't a professional, if they didn't have the LabVIEW Professional Development System. I only meant to highlight that "Professional" is a distinct version of LabVIEW -- I didn't pick the name, so don't blame me.

Speaking of snobbery, what entitles you to use LabVIEW? Why should NI price it at a point that you can afford? Do you deserve LabVIEW? If you know of a better/cheaper tool than LabVIEW, then use it. If you see a market for a better/cheaper tool, then build it.

Lvdiff requires this file in your project directory:

procmphier.llb\CMP compare two VIs.vi

Since I don't have that file, I'm guessing it's probably in the SCC toolkit or something like that and a good majority of people probably don't have it.

Sounds like you don't have the Professional version of LabVIEW.

I have built an application with the following architecture:

1. Two llb's saved for distribution. These were saved using the "save with options" method so there are a few VI.lib VI's that are in both llb's.

2. One EXE that loads VI's from each llb using the VI server.

The intent is to implement a "plug in" type of architecture. The llb's can be individually updated.

When the EXE is run, the VI search message box pops up until all VI's have been found. I would prefer that this message box is not displayed. I suspect that this is due to there being multiple copies of VI.lib VI's. Is there an INI file setting to accomplish this?

Using LabVIEW 6.1.

Thanks!

To suppress the file dialog for missing VIs, add this to your applications INI file:

suppressFileDlgForMissingVIs=TRUE

Note -- this works for the development environment (if added to LabVIEW.ini) but you usually wouldn't want to do this.

How, in your opinion, is "update/commit" better than "check-in/check-out"?

update/commit is better than check-in/check-out for many reasons:

1) update/commit requires good communication between developers, which facilitates communication between developers.

2) locking large portions of code causes limits access to those portions of code, even if they are not being changed. It forces synchronous access to large blocks, which slows down development.

3) locking/unlocking requires access to the repository, therefore you cannot checkout code and do development unless you have connectivity to the repository. The update/commit model only requires access to commit the changes. You do not need access at the time you decide to make changes.

We can't merge VI diagrams...

Yes you can. Take a look at lvdiff, which allows side by side comparisons of VI differences.

I just downloaded the PushOk SVN Proxy and I couldn't get it to work -- probably because it is having trouble with snv+ssh URLs (svn tunnelling through ssh, which is the access mechanism that I use for accessing my repository). Also, I am not liking the LabVIEW approach to source code control. The Source Code Control settings are a global LabVIEW setting (configured in the Tools>>Options... dialog), rather than a project setting. Since LabVIEW 8 has projects, why are Source Code Control settings global? This doesn't make sense to me.

I'm thinking that I might just ditch the idea of using LabVIEW SCC and just keep using TortoiseCVS and TortoiseSVN -- the way I've always done it. Also, since CVS and Subversion use a concurrent access model (update/commit) rather than a synchronous access model (check-out/check-in), I am not sure that I would like limiting myself to the latter by going through the SCC API.

I was reading the online tutorial Using Source Control Software with LabVIEW, which describes the SCC features in LabVIEW 8. It looks like LabVIEW will support any SCC API Plug-in (SCC API is a Micro$osft standard for source code control providers to plug-in to a development IDE). The tutorial states that the following are supported:

• Microsoft Visual SourceSafe
  
• Perforce
  
• Rational ClearCase
  
• PVCS (Serena) Version Manager
  
• MKS Source Integrity
  
• CVS with the PushOk Windows client software
  

I am pretty excited about having CVS support, since OpenG developers use CVS. But, I am also excited because there is a good chance that the PushOK SVN SCC proxy (which I discovered on the PushOk website while looking into thier CVS SCC proxy product) will also work, allowing LabVIEW's SCC to talk to Subversion! :thumbup:

Here is a direct link to the LabVIEW 8.0 Upgrade Notes.

Looks like the cat's really out of the bag, now.

http://www.ni.com/labview/

If you drop the numeric constant from the numeric palette it is automatically selected but is 'blue' because it is an I32. Type your number while it's selected but finish with a '.' and the type changes to DBL. It works for any I32 on the BD that has never had its representation changed. Once it's been changed it's broken wrt of this funtionality.

Only found this the other day after 7 years of RMB/Representation/DBL :headbang:

This is because numeric constants dropped from the palette have their representation set to "Adapt To Source". This causes numeric constant to adapt their type to whatever you type (no pun intended) into it. For example, if you enter "-1" it will become an I16. If you enter "1" it will become a U16. If you enter "1.0" it will become a DBL. If you enter "1 +2 i" it will become a CDB.

I don't know what this is but.. I gotta get me some of that!

Here's your answer.

The Retro-Encabulator is a fictional device purportedly manufactured by Rockwell Automation, according to a video that has been circulating on the Internet. The video has become popular with engineers due to its humurous use of technobabble.

So unfortunately, you won't be able to get you some of that.

Congratulations, Brian, to you and your family

So, the moral of the story is... Provide a test harness to test all VI's before release.

Actually, I doubt that many of the FlexMotion VIs would pass inspection by VI Analyzer. Good style is so important. It isn't just to help people understand your code. It actually helps you write better code with fewer bugs.

You can achieve this by adding no-op frames that are titled "------------ Section Name ------------". They are not intended to be executed, but rather serve as deviders between groupings of frames.