LAVA 1.0 Content

Nice work :worship: Polymorphism over array dimensions (from scalars to N-dimensional arrays) combined with different data types is still on my wish list. As an example: DBL scalar, SGL scalar, Bool scalar DBL 1d, SGL 1d, Bool 1d DBL 2d, SGL 2d, Bool 2d ... DBL Nd, SGL Nd, Bool Nd If I ever have extra time, I'll modify to code or write a tool to include polymorphism over both type and dimension. Tip: Today I needed to create polymorphic dynamic LVOOP methods. This requires to create first a number of dynamic methods (one for each polymorphic type), then create for each dynamic method a static method that calls the dynamic method. In the end the static methods can be added to polymorphic VI. When the polymorphic VI is called, it first calls static VI of correct type, which then calls dynamic VI of the same type which is dynamically dispatched to the correct decendent class. Complicated but it works...

See this LAVA posting regarding LabVIEW for Everyone, Third Edition.

Some "good" date/time manipulation vis are available from the Moore Good Ideas, Inc. website.

This has occurred to me a few times. If I add an empty polymorphic VI template (.vit) to a class that belongs to a library, everything seems to be fine at first glance. Later on it may occur, that LabVIEW spontanously decides that the class is broken, because it includes a polymorphic VI (the .vit template) that is not executable due to the fact that it contains no VIs (it's empty). LabVIEW behaviour is not consistent here, since it allows adding the template without breaking the class.

Hi, I've the following problem, can does anybody know a way around. I try to programmatically add an empty folder to LabVIEW class and then fill the folder with a number of methods. I open a class by path to lvclass file using LVClass.Open method of Application class. I then try to create an empty folder to the class using LVClassLibrary.AddItem method. I wire "Folder" as a type, empty path as a path and some name as a name. Everything works fine if the class I'm operating isn't inside another library. However, if the class belongs to a containing library, then I get an error message: Error 1055 occurred at invoke node, "LabVIEW: Object reference is invalid." The error is generated by the LVClassLibrary.AddItem invoke node. What do I do wrong? p.s. Please do not move this topic to scripting, at least not before LV developers have had some time to answer...

What the F... ? How can visualization option have anything to do with how LabVIEW generates code? Is there a name collision, on bug collides with another and both desappear... :headbang: :beer:

I find myself repeatedly writing code to check the timeout of the Enqueue Element method, then placing a case statement that will Dequeue one element to make room for the new element that timed out. If LabVIEW queues are implimented as circular buffers, is there a better way to do this? How to Write to a Full Buffer LabVIEW can handle cases 1 and 4 (from link above), and sort of handles the third case by timing out with a time of zero milliseconds. I'm concerned that my implimentation of Case 2 with "Enqueue -> Timeout True? -> Dequeue Element -> Enqueue Element" will add to the CPU load when working with multiple TCP data streams. It would be nice to have an option to "Obtain Queue" for defining how a size limited queue behaves when full; and enumeration with "Ignore Oldest","Ignore Newest". A companion to this would be an additional "Late?" output on the Dequeue Element and Flush Queue functions that could be used to monitor the servicing of the queue. In timed loops, this could even be used to dynamically adjust the loop rate to tune CPU usage.

Alex did mention that he was looking for something beyond Basics I & II. The Intermediate courses were excellent, but I know I could not have afforded them on my own. The last time I looked, it was something like $2,300 for one week to take Int. I & II. There does not appear to be any self paced learning for Intermediate I would still recommend A Software Engineering Approach to LabVIEW, although it is getting a bit old at this point. I've spoken to a few people who write these kinds of books and unfortunately the effort usually outweighs the rewards. I guess the best way to learn more about LabVIEW is to become a LabVIEW Advanced Virtual Architect and ask questions here!

This may be a feature, not a bug. One may define class inside a library to be public or private. Public classes can be accessed from outside the library and private classes only from inside the library. When on defines ancestor class to be private and decendent class to be public, it's not clear if the inherited methods will be private or public. In LabVIEW 8.20 these inhereted methods are private and inaccessible outside the library. This means that even though the class is public, some of its public methods are inaccessible, since they are defined in a private class. I think that if a class is public, then all its public methods should also be public, no matter if they are defined in a private class. That is, if a public class is derived from a private class, then the private class should become public in methods but the class constant should remain private. Dynamic VIs should require a public class to be connected to dynamic dispatch input terminal. -jimi-

If you use flatten to string, then you can use anything as a key. I agree that this should be implemented as an associative array. When variants are stored to disk, the attributes are lost.

I was looking for one of the PCI-GPIB+ analyzer boards for myself on eBay for some time. Be advised that some GPIB boards are posted there as the plus models, but only because the silkscreening on the board says GPIB/GPIB+. Some versions of the GPIB and GPIB+ are the same basic board, but the plus has one extra ASIC. The real plus boards are less common, and generally sell for twice the price. Do your homework if you start shopping the auction sites

The error occurs also with '-x' so I suspect it occurs with all 'in-place' operations which do not create a new buffer but modify present buffer.

Hmm... Have you ever tried to create more than 1000 VIs and add them into a polymorphic VI manually ? And then find that you have a bug or that you want to change something and make the change to all of the VIs? :headbang: And when you place such a polymorphic VI on a block diagram, all of the VIs are read into memory... and it takes a while... and it consumes memory. But at runtime, it's fast, and thats why I use them yes. But I must say it's not fun and without scripting it would be impossible.

I've tried to dig this issue a few months ago. No, there is noway to do it, that's publicly accessible. I myself used scripting to create a few hundred VIs which I add to a polymorphic VI also using scripting. There are two non-public ways to do this: New XNodes and old xnodes. New XNodes require LabVIEW 8.0 or newer and require a license from NI which you won't get. Old xnodes work at least in LabVIEW 7.1 and LabVIEW 8.0 and don't require a license, however they are not documented in any way. It's also probable that old xnodes will be replaced by new ones and the support for the old ones will be dropped. The idea with both new XNodes and old xnodes is the following. When you connect a wire to the diagram, XNode runs some developer defined code, which generates the actual diagram of the node. This way you can catch information from the wire type connected and generate a diagram for just that wire type. You get real polymorphism, although it's quite complicated to develop. New XNodes are libraries, which can include special VIs called Abilities the same way as XControl special VIs are called Abilities. The XNode libraries are named with ".xnode" extension. You cannot write a library and make it an xnode by just changing the name, I've tried it and it didn't work. The templates for Abilities can be found from <LabVIEW>\resource\Framework\Providers\xi\xnode.llb. I don't know if it would be possible to modify one of the XNodes shipping with LabVIEW so that one replaces the Ability VIs one by one with ones created from the template. I suppose it won't work. There are programming languages like Haskell in which functions can be defined so that they accept all the types for which the subfunctions inside the function are defined. This way you get ultimate reusability. For example you can define '+' operation for some new type. Then anything you already have written that relies on existence of '+' operation would be functional to your new type. This is really cool, it's a pity that we don't have this in LabVIEW. This is real polymorphism... I'd really like to see this kind of typing system in LabVIEW. In addition I'd like to see all other features of Haskell programming language like lazy evaluation and wires that carry diagrams in LabVIEW. Haskell monads wouldn't probably be needed since in dataflow language one can define the order of operations by connecting some wire from one operation to another. The wire defines the order even when it doesn't carry data (well this is almost exactly the same thing that Haskell monads do). What you can do in LabVIEW 8.20 is to use classes and inheritance to get support for multiple types. Still you have to define what type you'd like to support.

Perhaps I'll just write later when I have more time an open GEH replacement that calls the original GEH if the error is not of class type. This in addition with the throw and catch example of mine is a great improvement for many. This can then be used by the community until NI decides to launch something. We should decide on the following issues: - What would be the error code for class type errors. I suggest we use single code for all errors thrown - Should we be able to throw also warnings, what about multiple warnings? - What should we call the top most error class that all errors are derived form - Is some kind of default error hierarchy needed? - Do we need a wizard to create new error classes?

I have a simple labview app running on a machine, and I have NI remote front panel webserver running and configured. I take a lap top connected to the internet, bring up my web browser, and type in the URL of the remote front panel file created with the web puplishing tool, everything works as intended. I take the same laptop and put it behind the firewall at work, the HTML portion of the page displays fine the remote front panel frame is displayed as usual with the "Downloading panel" context and progress bar. After several seconds the progress bar and assosiated text dissapear and an error is displayed in there place stating "fatal error occured during connection, closing connection". I am sure it has somthing to do with are firewall, I just have no idea what, therefore it would be very hard to work with the it department to resolve the issue. Any help to point me in the right direction, would be greatly appreciated.

To clarify, the context help that appears in the image is that of LabVIEW internal function Create Mask.vi whereas the context help that should appear would be that of a class method Create Mask.vi.

Local LabVIEW support told me that this is a wanted feature. Classes inside libraries can only be used if the containing library is included in the project where the class is supposed to be used. I asked them to submit the following suggestion to NI.

A student version of LabVIEW is available (with text books) for less than $100 US! The LabVIEW Student Edition Software Suite consists of the following National Instruments software on a single DVD:

These kind of bugs normally indicate that the software architecture is too complicated and not modular, and the bugs arise from the fact that new functionality is added to an environment where it doesn't fit to the architecture. :thumbdown:

I think the following workaround should do the thing: - Write an independent VI (SAVE.vi) that can handle saving of the project - Start main VI, if you want to build the project - dynamically create a copy of SAVE.vi and all the VIs that you need for saving process (easiest is to use a library and call save as method) - call the transient copy SAVE.vi with state parameter that describes in what state your progrman was prior to build, don't wait it to exit - exit everything else - SAVE.vi builds the project and re-executes the main VI - delete transient copy of SAVE.vi That's it, quite complicated compared to your previous solution, I admit.

Followed this from digg.com/programming during my lunch break. Some of these quotes are pretty good... http://www.eskimo.com/~hottub/software/pro...ing_quotes.html Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. Brian W. Kernighan Ugly programs are like ugly suspension bridges: they're much more liable to collapse than pretty ones, because the way humans (especially engineer-humans) perceive beauty is intimately related to our ability to process and understand complexity. A language that makes it hard to write elegant code makes it hard to write good code. Eric S. Raymond (When coding with wires, it's even easier to tell the ugly programs from the beautiful ones...)

I have not verified if this is only a problem with (public) classes inside a library or a more general issue.

I was wrong, you cannot I think uninitialized shift registers and all other VI properties with state cause quite a lot of trouble since they don't really fit into a pure dataflow ideology. I'd like to see a possibility to have stateless VIs which could be used to implement real recursion.