Aristos Queue

You want a primitive (or property node or other LV node) with different behavior than the current primitive. But you have many different configurations that you'd like the new prim to support. And you might have other modes that you might want for particular cases, so the uses are a bit open ended. And you've already written the VIs that would do exactly what you want. But Create SubVI doesn't work because that causes the data types to be fixed. May I suggest that what you really want is polymorphic tunnels on subVIs? Enhancing a single prim is fine, but this is exactly the kind of request that makes me want to find a better solution language-wise. But I'll pass your suggestion along to the folks that own these primitives.

This is a problem that can affect any library type in LabVIEW, not just .lvclass files. At a guess, I'd say that you've got cross-linking problems. Suppose the project stores the paths for VI A and VI B. Well, VI A uses VI B as a subVI, so it stores a path to VI B. If the path that VI A stores for VI B is different from the path that the project stores for VI B, there's a potential cross-link problem. With LV 8.5, we massively improved the ability to detect, untangle and avoid cross-linking. The tools work really really great.... for VIs. When libraries get involved (which means .lvlib, .lvclass, .xctl, and .lvsc) the detection works well, but not so much the untangling. Normally a project loads all the libraries listed (not all the VIs in that library necessarily -- it does for some library types, but not others -- but the library file itself is always loaded). When cross-linking is detected, the project tries not to load the libraries so that the user can manually open the libraries from disk (by using File>>Open) to select the ones that he/she really wants the project to use. I'll bet that you made a copy of your project to protect your 8.2 source code when you loaded it into 8.5. And I'll bet that one of the VIs (or libraries or the project itself) in the 8.5 source code *somehow* remembers a path over to the 8.2 source code. And that is leading to the cross-link detection. This problem could also be caused if you saved *some* of the VIs in your project but not all of the VIs in your project when you opened in 8.5 -- did you remember to have all the VIs in your project in memory at the same time when you did Save As? If not, some of them may remember the old path. Back in 8.2, try building a source distribution of your project to create the copy and then open the new source distribution in 8.5. PS: I presume that the team that made everything work so well for VIs in 8.5 will be returning to further work on libraries in a future LV version, but I have no information about this.

General rule: If you have an enum or ordinal value that is set at the start of the object and is unchanged during the lifetime of the object, that should probably be a child class. I agree that your indexed image sounds best. Based solely on the information presented here it sounds like what you'd want is Image __| __+-- 24-bit image __| __+-- Indexed image ______ | ______ +-- 8 bit image ______ | ______ +-- 4 bit image ______ | ______ +-- 1 bit image Then you can avoid all the duplication of code for the 8, 4 and 1 cases by putting that functionality on the common parent, but you leave yourself room for specific behavior for the 8, 4 and 1 cases if you need it at some point in the future. I don't have any info about the future of image handling in LV. That would be a question for another developer.

Enjoy: http://www.drozmonkey.com/2007/08/14/a-thi...ght-red-handed/

QUOTE(Jim Kring @ Aug 15 2007, 02:19 PM) Several words, including the phrase "darn pushy users." No, I have no idea if this will be addressed at this time. It'll be any number of months before I get back to low level bug fixes. Right after release is when I generally wander off to the bigger projects. Otherwise I could spend lifetimes just tweaking small things, and let me tell you, that gets boring fast. The mind begins to grasp at any passing fancy that seems more exciting than endless bug fixing, and the programmer, in such deranged state, is driven to such madness as to put just-in-time advice dialogs up after every mouse click. Trust me ... it's better not to go that route.

An effective demo... get a C programmer or Java programmer to write the standard "random number strip chart" VI ... two parallel loops updating two displays. Compare the code between them. Point out to your boss that anything that C/C++/JAVA can do, LabVIEW can do as well since they're all complete programming languages. The advantage is the natural parallelism and the code readability to layity. The very fact that your boss can understand the LabVIEW code and probably not the other may go a long way to convince him that the overhead of bringing a new hire up to speed on a LabVIEW code base is generally less than the overhead of getting them to learn a C/C++ code base. That savings right there may be enough to convince.

QUOTE(Ben @ Aug 14 2007, 03:12 PM) I think we'd need some more details about what exactly you think is behind us. NI just released the new Statechart Module for building really advanced state machines. I don't think that architecture is behind us. Are you simply referring to programming individual state machines should be avoided in favor of using some reusable framework? Because that I agree with.

QUOTE(shoneill @ Aug 13 2007, 08:00 AM) You're talking all data types, not just LV classes, right? The problem you're facing (I know because I tried this as one of the initial approaches to classes) is that you need a central data type repository (such as the .ctl) that knows "this VI is my 'add' function and this other VI is my 'subtract' function" etc. The ctl has to store all these relationships to these VIs. The result is something that looks a whole lot like a library, with a centralized data type, which is effectively what a LV class is. The piece that we sidestep is the map from "function XYZ" to "implementation ABC". That would be operator overloading and requires that there be a map of all possible functions to overload in LV to the particular implementor. I've played around with such concepts, and they get pretty ugly, both on the debugging side and on the UI side. Personally, I don't particularly like open-ended plugable functions (aka operator overloading). With the dynamic dispatching of classes, I can view the class hierarchy and know whether or not a given class has a given functionality. With arbitrary overloading, I become less sure at every turn whether that "add" primitive that I see on the diagram is actually an add. James Gosling, the inventor of JAVA, left operator overloading out of JAVA because he saw C++ and noticed that it was now *ANSI standard* to use the left shift operator for output to a file. I've seen C++ code where "a == b" was overloaded to not actually evaluate whether a equals b but instead was a special type of assignment (deep assignment instead of shallow assignment, for those who know pointers). That sort of horrific situation is not one that I want LV to enter into.

This is not a bug for typedefs. Typedefs are dumb. They have no memory. Other tools that index into typedefs store indicies or store names (which ever seemed most logical for that particular tool), but neither is satisfactory when the typedef gets edited. The typedef does not remember "This was 1, this was 2, and this didn't exist at all before" to allow other tools to correct themselves. The behavior you get is the behavior you get. If you want a datatype that does know where its elements go from version to version, that's LabVIEW classes. That's, obviously, no help to you who is probably trying to do some amount of UI work. But when you encounter similar problems with the default value of your block diagram constants, know that classes can help you in that case.

Some of you have already seen this in another forum, but here's my list of sessions that I would consider to be of interest to advanced users. I think there was quite a bit of advanced topics. 0) Steve Rogers' presentation of the new inplaceness structure 1) Michael's XControls presentation 2) Jim Kring's commercial software presentation 3) Jan Klasson's presentation of the beta of the new UML editor (this is SO amazingly cool it had me drooling!!!) 4) My presentation on Intro to OO Development (which included a new way to architect functional globals) 5) The OO Early Adopter Stories, tales from other advanced LV users on using the new LV classes 6) Bioacoustic Algorithm Engineering (aka using DAQ and signal processing to help with interpreting whale song) 7) One or more of the hands-on sessions had to have had something new for you 8) All three of the keynote presentations -- I can't even begin to cover all of them. But mind-controlled machines was really cool, and contemplating the possibilities of every person in your neighborhood having a personal aerial strike force has kept some of us in conversation for a full day. On the floor of the expo hall, your engineers should've been excited about 1) S.E.A.'s new LV Localization Toolkit 2) The inovations with the LEGO and NXT toolkits Further, a lot of the value of NI Week is to compare notes with other advanced LV engineers, over and beyond the sessions, and to feedback to NI on specific needs/wants. I came out of the week with multiple pages of suggested work in a much MUCH more valuable format than I get from online discussions. And you never know, you might come home with a new Wii. I did. ;-)

QUOTE(Clicker @ Aug 10 2007, 05:12 PM) Normally we mark a VI as having a change when a mutation like this is made. That's not happening in this case. But the .lvclass file itself is being marked as needing to be saved. The class saves, but it isn't bothering to update its image of the .ctl because the .ctl isn't marking itself as needing to be saved. When we load the class later, it assumes that the .ctl is the same version as itself, but actually the .ctl hasn't come up-to-date. At least as far as I can tell... Without having actually fixed the bug, there may be further complications that I discover later. But the workaround should be enough for your purposes tonight. ;-)

WORKAROUND FOUND. Load the 8.2.1 version in 8.5. Open the private data control. Edit it by resizing the VISA resource Name (actually, any edit will do). Then you can save the VI in 8.5 and it will load correctly from then on. Curiously, you probably (if I'm reading the code correctly) won't be bit by this bug if you load directly from 8.2, only if you load from 8.2.1. *sigh* This will affect any LV class that has a VISA resource string in its private data control. It is specific to the interaction of those two features. PS: Do you have a CAR number on this from when you reported it to NI? The bug report hasn't yet percolated to my desk, and I might as well jump ahead of the stream and intercept it at this point.

QUOTE(Clicker @ Aug 9 2007, 06:51 PM) Your .lvclass file is corrupt; more specifically, the .ctl file inside the .lvclass file is corrupt, but it amounts to the same thing. I don't know how it got to be corrupt (that blahblahblah.cpp message would be useful in ascertaining that). QUOTE(Clicker @ Aug 10 2007, 12:25 AM) So LabVIEW 8.5 will use my class in the original 8.2.1 format but after re-saving and then opening it again everything breaks. Perhaps something is wrong in the new file format which I find very discouraging. Far far more likely is that something is wrong with the original 8.2 file format and the now corrected 8.5 file format is having trouble interpreting it. There is one known issue along those lines (I put in special code to recognize the corrupt 8.2 files and fix them, but you may have found another form of the corruption). Or it could be as you say, a corruption of 8.5 itself. I'm playing with the files a bit to see if I can get some more info.

Here's one that was specifically requested by LAVA users: In Tools>>Options>>Front Panel, you'll now find an option for "Connector pane terminals default to Required." This makes it so that any new input connections (except the error code cluster) that you put on the conpane -- either by explicit use of the front panel wiring tool or using Create SubVI -- will default to Required instead of Recommended. The default is FALSE so as to maintain consistency with past LVs; I expect that most of you experienced users will decide to enable it.

At the LAVA BBQ on Tuesday night, I offered as one of the door prizes a copy of my deck of cards: http://forums.lavag.org/index.php?act=attach&type=post&id=6583 For those unfamiliar with tarot cards, read here. In short, a tarot deck is a deck of 88 cards that first appeared in the middle ages in Europe used in fortune telling. Each of the cards is symbolic of some aspect of life, and by random pulling of cards from the deck, so the story goes, one may intuit answers to questions. The PMTDftGP brings the power of card reading to the everyday software release manager. Not sure whether a given feature will be well received by customers? Consult the deck! Need to know when the release party should be scheduled? Consult the deck! Deciding which programmer to fire during cutbacks? Consult the deck! The deck is designed with a graphical, dataflow interface that G programmers will find immediately intuitive. The 22 cards of the Major Arcana have been redesigned to depict the phases of a programmer's enlightenment. The Minor Arcana come in four suits of 14 cards each -- Wires (R&D), Nodes (Sales&Marketing), Structures (IT&Manufacturing), and Controls (Users). Included in the deck is a nifty instruction card for doing a basic reading from the deck, though the deck is fully compatible with all known ANSI standard tarot layouts. The images for the individual cards may be downloaded here. If you would like to print your own deck, then follow these instructions: Visit www.plaincards.com and purchase 1 set of their blank tarot card pages. Download the card images formatted for printing on 8.5x11 pages from here. The cards are layed out to be printed on the cardstock purchased from plaincards.com. Print the cards using your favorite color printer, or visit Kinko's. Be aware that Kinko's will only print from .pdf formats, so you'll have to convert the .png files over (Mac computers can do this easily by opening the .png files in Preview and then saving as .pdf). Also, make sure you remind the Kinko's staff that the images are 8.5x11 and DO NOT scale the images to fit the printer margins. Failure to do this will waste the very valuable cardstock and make you want to kick a Kinko's employee in the shins. Optionally, spray the plaincards after printing with the spray laminate also available from plaincards.com to make the cards easier to handle and harder to stain. Here are three cards as a sample of the deck: http://forums.lavag.org/index.php?act=attach&type=post&id=6584http://forums.lavag.org/index.php?act=attach&type=post&id=6587http://forums.lavag.org/index.php?act=attach&type=post&id=6585

Oh, and I almost forgot the one I'm busy recommending to all LabVIEW programmers who are interested in OO: The Object-Oriented Thought Process by Matt Weisfeld

QUOTE(jzoller @ Aug 8 2007, 08:29 PM) These are arranged in the order that I recommend all software engineers read them. Especially "Close to the Machine". This excellent book teaches a programmer to be aware of the real world impacts of their software. Close to the Machine: Technophilia and Its Discontents by Ellen Ullman Goedel, Escher, Bach by Douglas R. Hofstadter The Cukoo's Egg by Cliff Stoll "Alice In Wonderland" & "Alice Through The Lookingglass" by Lewis Carroll Nexus: Small Worlds and the Groundbreaking Theory of Networks by Mark Buchanan

Earlier this year I posted stuff about the LV2OO-style global on this site. For my NI Week presentation, that demo has been substantially revised. The VIs are available here: http://forums.ni.com/ni/board/message?boar...=264064#M264064

QUOTE(Ben @ Aug 7 2007, 01:51 PM) Ah. Now I see. I focused on the logic of the "not and" because that was completely different than the gate sequence I would've chosen, so I thought the bug you were seeing was there. I didn't even check the "off by one" problem.

Ben: What am I missing? The two diagrams look functionally the same to my eye.

QUOTE(Val Brown @ Aug 7 2007, 10:25 AM) Caveat: It works great for pure VI projects. It has issues when libraries (.lvlib, .xctl, .lvclass or .lvsc) get involved. It can identify the conflicts, but the untangling is much more manual. The tools will become more robust as time goes by. PS: .lvsc is the new file extension for the LV State Charts, introduced in this morning's keynotes. Some folks would also include .xnode in the list, but I don't include imaginary files in my list. :-)

Strict timing always requires the real-time operating system. You simply cannot guarantee timing using MS Windows or any of the desktop operating systems. You can get very close by turning off screen savers, virus checking, file caching, and a host of other aspects of the system, but you'll never get to the point of zero interrupts in your time-critical thread. You should talk to your area NI sales person to get a good handle on exactly which LV version is the one for your needs. They're the most qualified to differentiate the different tools.

QUOTE(Val Brown @ Aug 7 2007, 03:12 AM) Just to be clear to everyone... if you haven't used LV8.5, you might get the impression from this post that there's some sort of great Migration Phase to transition from 8.2 to 8.5. There isn't. But LV8.5 has strengthened the ability of the project to make sure that you're loading the VIs you intend to be loading -- an attempt to fix the ancient curse of Cross Linked VIs. It works pretty well, but when you first load your project in 8.5, if you've got lots of VIs on your disk that are the same file name and multiple of them are referenced from within your project, the project now has a series of tools, including "Resolve Conflicts dialog", to give you tight control over exactly which ones should be part of the project and associated with what caller VIs.

QUOTE(Tomi Maila @ Aug 6 2007, 03:03 PM) This is like Supreme Court Justice Stephen Bryer... in an interview, he said he had been the newest justice for 12 years, and the newest justice is the one who has to answer the door if anyone knocks while the judges are debating. 12 years of answering the door!

QUOTE(eaolson @ Aug 3 2007, 05:06 PM) There's a good reason for this but I can't remember it right now. It made sense when it was explained to me long long ago. QUOTE So just how many working branches of LabVIEW are there at NI at any one time? Or do you just occasionally spin off the "cool stuff that's working" into a new version? Spin off, fork, merge... you name it, we've probably had a reason to do it. The Mindstorms NXT was a fork of the entire source base at one point, for example. It does make versioning and VI mutation rather interesting sometimes. I honestly don't know how many forks/revisions are in development at the moment.