LAVA 1.0 Content

Good idea Zen! I would very much like to see a graphical functional programming language. There are a few things that make LabVIEW a bit like functional languages. First is that the value of wires is not changed (in most of the cases). Second is that the language is automatically concurrent. I think there are however much more differences in LabVIEW and functional programming languages and LabVIEW is not (even close to) a functional language. Let's imagine a functional programming language called "Functional G". This hypothetical language would differ from LabVIEW at least in the following properties: In functional G wires would pass expressions (the history of the wire), not only values In functional G, the VIs would always be re-entrant and stateless In functional G, shift registers would not maintain their valus (at least VIs with shift registers would not) In functional G, there would not be globals or other joint variables of if there were, these would be constant after referenced the first time In functional G, VIs could be passed to and returned from other VIs as parameters with and without parameters In functional G, sequences of code could be passed to and returned from other VIs In functional G there could be a way to do currying i.e. to define new functions based on old ones like cos(x)=sin(pi/2-x) Functional G would possibly allow lazy evaluation, i.e. a wire and it's history could be evaluated as late as possible. Functional G would allow storing "continuation" i.e. the state of the execution i.e. a VI to be called next with all of arguments to be passed to it Functional G would have a feature called "pattern matching" similar to polymorphic VIs except that a different VI would be called not based on type but value passed to the "pattern matching polymorphic VI". I think a best compromise of a new language would be a programming language that would allow pure functional programming, but would also allow many non-pure properties. This kind of language would allow building very stable and highly concurrent functional programs but also would allow accessing non-functional resources such as files and measurement devices which defenitely have a state. If you are not familiar with functional programming, see Functional Programming And The Rest of Us.

Depends on your needs. Storage VIs are very easy to use. The performance is however a bit slow and undeterministic. I use them in a few projects because Diadem can open TDM files written by storage VIs. On more demanding projects I use HDF5 1.8 library of our own which performs better and more quite a lot more flexible but also more difficult to use. Unlike in TDM there are no limits to data dimensionality or file hierarchy depth or number of attributes. Anybody interested in becoming a beta tester for HDF5 library, please contact me.

I don't think LabVIEW "G" should be made an open standard. Why? Because we already have a good implementation of a development environment. The thing is that no single development environment or programming language never can cover all the programming problems. The general purpose programming languages like C, C++ and Java are quite close to how wide an audience a single programming language can reach. What would be needed instead of open G is another open graphical language which would bring forward the graphical programming itself. I don't even mean graphical dataflow programming but graphical programming. It may be dataflow or it may not. It would depend on the desing targets that would be set to this general purpose language. Objects oriented programming language must include references to objects, which is not dataflow, but this doesn't mean that dataflow couldn't also exist for problems where it suits better. The best way to achieve this goal would be to standardize a general purpose graphical programming language. Then perhaps try to build an open source reference implementation of the core features of the language. As an open language, the language could be marketed to software companies building software development environments. If this language would succeed we would see more graphical programming languages to appear.

Exactly! LabVIEW is targeted for measurement and is not very good tool outside this field. However graphical programming is a general paradigm. You could create a high performance graphical language, a web programming graphical language and what ever. The reaseon graphical programming is not more popular is that most programmers are not aware of graphical programming. An why is that. The reason is that LabVIEW is that there is no good general purpose graphical programming language on the market.

Ok. Then I have to make an educated guess. NI turn over was 572 million bugs last year. Let's assume that about 40% of this is from LabVIEW so we get $ 286M for annual LabVIEW sales. Then let's assume that each user pays an average of $1500 per year for NI. So we end up to something like 200 000 users. So I assume the real number lies somewhere between 100 000 - 400 000 LabVIEW users around the world.

"Rohit" lists a first country of Canada. Maybe this person is indicating their home when there was Pangea

The label of a Formula Node is not associated to it's BD object. While, For, and sequence structures will reposition the label when the associated object is resized on the block diagram. The Formula Node label just 'hangs out' wherever it is placed. In certain cases, the label can even appear to be part of the formula after a resize I was documenting and refactoring some old code, and noticed that this problem exists. Minor irritation, checked and this existed in LV 7.1 as well... That's what I get for touching old code!

I would suggest using a parallel loop for the SO Write function, and passing the data from the read/calc loop to the SO Write loop through a queue. I've attached a quickly modified version of youR vi for review. If your data set is large (or continious) you should place some sort of wait next multiple in the producer (read/calc) loop so you don't eat up all your system memory by producing SO data faster than the output rate. Also, performance almost always improves when you keep the data types as integer and provide the correct type input to the primative functions. I believe you are writing doubles to the 8 bit mono input of the SO write, after adding a constant of type double to an I8. Download File:post-949-1153827402.vi

I could not recreate your problem. I made a simple vi that calls the MD5 routine twice, and also loads the md5.vi itself for calculation. I did not receive error code 8. The only thing I can think of is that some of the high level file I/O functions do not provide an error cluster, and you may be seeing a race condition; the file I/O function is still using the file when the second MD5 function is called, the file I/O function has reserved the file for read/write and the .NET MD5 call is timing out trying to get a file handle. I assume that you are creating a new file, then calculating an MD5 as a checksum. Try to use the file path out of the write characters to file as the input to the MD5 function to enforce data flow. Download File:post-949-1153825804.vi

This year LabVIEW has been around for 20 years and still is practically the only graphical programming language on the market. LabVIEW is heavily patented, but the main first patents expire in 2007 which would leave a door open for open standard for graphical programming language. I myself especially would like to see a real object oriented graphical programming language that has been designed for object oriented use right from the beginning. I think an open standard would benefit everybody, even NI. NI is a pioneer in software data aquistition. Open standard would attract more, maybe even much more, developers to graphical programming languages in general. This would defenitely benefit NI, as it has such a strong foot hold in the graphical programming. NI would propably not loose many of its current customers but would also gain new ones. Is there a project developing an open standard for graphical programming language? If not, would anybody like to start up such a project.

Hi all, Does anybody have any idea on how many LabVIEW users are there around the world? Also some geographically more restricted estimates are appreciated. -jimi-

Found an answer on the ni forum http://forums.ni.com/ni/board/message?boar...uireLogin=False

Hello, I have a string of hex data in the form of FFFFFFFF that is a hexadecimal represntation of a floating point number based on the IEEE754 standard. For example 4281C9B5 in the hex string is about 64.89 in decimal. How do I convert from the hex string to the decimal number i am lost, have read and searched but do not have an answer. Any help is apreciated

Welcome to LAVA! Your question is fair, and lucky for you one of our greatest members has helped in the most recent rewrite of one of the best books called "LabVIEW for Everyone". The original books are good, and with Jim's input on the third edition, you shouldn't be dissapointed. Another book worth reading is "A Software Egineering Approach to LabVIEW" by Conway and Watts. This book is a couple of years old, but covers software planning and design. Preview of it available via Google The authors are from Hampshire, UK their web site is http://www.ssdc.co.uk/. I took the Intermediate I & II classes, and the concepts as well as small portions of this book were referenced. You should know that there are some rendering quality problems with the illustrations in this book; not the fault of the authors. The third edition of LabVIEW for Everyone is expected to be released on August 1st. I'm not sure about ordering from the UK, but Amazon is offering a nice discount if you pre-order.

Everybody knows that it is very common that comapnies and laboratories buy too few licenses and then create unauthorized copies of the software internally. It's unfair that I have to charge the honest customers extra price to cover the unbought licenses. Every license control system can be cracked, however even the simplest license control system gives users the message that the it is not proper to create unlicensed copies of the software. There are many issues where license management scheme is a validly applied. 1) Beta testing - You may want to limit your beta testers from using beta stage software after it becomes obsolete. 2) Free download for trial versions - A limited period fully featured license for trial version 3) Alternative pricing models allow users to choose the pricing model that best suits them - Pay per user - Pay per computer - Pay per capacity - Pay per active use - Site licenses - Periodic payments - Pay per feature - Superdistribution (peer-to-peer distribution) So it is not only about copy protection. It is also about giving customers alternatives of the payment schemes. I can attract more customers if I can give light users cheaper or even free licenses at the same time I charge heavy users more. This won't be possible without some kind of license management. Of course I need to consider if it is worth it. If I am about to write a license management software toolkit, would there be interest among the LabVIEW developer community in this kind of toolkit? There is a white paper at The Register about license management issues.

Now I can actually measure the the gobs(1) of LabVIEW code I've written over the years!

Manfred, thankyou for your help, modified the VI to give the checksum as a 2 character hex. Works well, once again thanks for your help.

Hello, I have a character string to send to a device over a serial link. the string is in the following format $nnRDaaaabbbbzz The nn is a number from 0 to 99 the aaaa is a number from 0000 to 0016 the bbbb is a number from 0000 to 0016 zz is the checksum in hex, and is generated from exclusive ORing each of the preceding bytes. Any tips on how I generate this checksum ? Cheers Mat

Exchanged was the idea... My wife and I play this game to try and reduce the crying. Notice that you only get 1000 ms of rest when Happy? = True. Maybe a bit optimistic... :laugh: See what happens when you code without a software design? Then again, it only took me about 5 minutes, and you could figure it out, right? Gotta LOVE LabVIEW! Now, about 'designing' your family... (hopefully) you make a plan to have a child, (hopefully) wait 9 months for the child to arrive, then just 3 months later you wonder why things aren't working out like you planned

OK. This was posted on the 12th, then Darren says he was speaking with someone last week and learned this little nugget...

Yes, MythTv...that's what I meant.. Thanks Tom. However, I don't think that it does what I want to do. I'd like to either select programming from a local jukebox, or from Internet TV (streaming video). Having similar features to MythTv would be a longer term hobby project. JLV

Is he finally gone from Canada.. Did the secret police pick him up?? I'll have to call my Jewish friends and send them after him Shame.... My Romanian friends say they don't want him to return to Romania.. I guess Belgium should be fine. Man... When I read his posts, it's like being on a bad drug trip...l. Woow... this dude must have tojken a lot of dope as a baby.. Chill dude... chill... 97% OF THE poPyulLation is NOtw a sEcrET POLliCE,... wOOOWWW.. My eyes... I see tripple, now!!!

LOL!! Congrats Mike. I need to visit this place more often. Especially with all those Imaging experts! Ray

The only problem is how to deal with the driver glancing from side to side or any direction away from the detector... You'd get a lot of false alarms. The other problem is blinking. You'd have to sample long enough to avoid those.. JLV

Hopefully this is the right category for this question.. Has anyone used LV for receiving streaming video? The video stream is typically .wmv or .asf. I was thinking of using the IMAQ toolset to develop a webtv receiver which would have PVR functionality. PVR = Personal Video Recorder I think there was a project done in Linux that provided a means to distribute audio / video over a local network and create a "video jukebox" of some sort. JLV