Aristos Queue

QUOTE (tcplomp @ Apr 10 2008, 01:57 PM) IMPORTANT. Read the http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/e419aede3b053a46862573d200609d39/$FILE/Windows_Readme.html' target="_blank">readme.html about *how* to perform a mass compile. Doing a mass compile like you normally do WILL NOT suffice. The version number between 8.5 and 8.5.1 is not internally bumped, so a mass compile won't work -- LV won't see that anything needs to be recompiled. =========Quoting from the readme.html============= Recompiling VIs for Bug Fixes The following fixes in LabVIEW 8.5.1 require you to manually recompile the VIs to correct the problem. To force a recompile of a VI without recompiling its subVIs, <Ctrl>-click the Run button. To force a recompile of all VIs in memory, <Ctrl>-<Shift>-click the Run button. To force a recompile of the entire current VI hierarchy, close all VIs currently opened, open the top-level VI, and <Ctrl>-<Shift>-click the Run button. This method will not recompile any of the VIs called dynamically in the hierarchy. You also can force recompile all VIs in a specified directory using the following steps. Note that you do not need to perform these steps for VIs installed with LabVIEW 8.5.1. Use a standard text editor to open the LabVIEW.ini file located in the LabVIEW directory. Add massCompAll=True as a new line at the end of the file. Save and close the LabVIEW.ini file. Open LabVIEW. Select Tools»Advanced»Mass Compile to display the Mass Compile dialog box. Navigate to the desired directory and click the Current Folder button. Click the Mass Compile button to force recompile all VIs in that directory. Click the Done button to return to LabVIEW. Once you finish the force recompile, reopen the LabVIEW.ini file. Remove massCompAll=True from the file. Save and close the LabVIEW.ini file. ======================

Disclaimer: I know nothing about this stuff. I passed your query along to other NI R&D staff who do. This is the reply I got. If folks want to control HW in LV, they generally have 2 options: (1) have a driver for their HW. Use the driver, generally through DLL calls (2) use NI-VISA to bit bang devices from user mode Here are some webpages explaining how to use NI-VISA to control HID USB devices in LabVIEW. "USB Instrument Control Tutorial" "USB RAW Control Communication in LabVIEW" HID issue "Why Won't Windows Install The VISA Driver For My USB Device?" "Using HID Compliant Devices with VISA Driver Development Wizard" But Vista is special: "How Do I Communicate with My HID Compliant USB RAW Device in Windows Vista?" Hope it helps.

This bug is not fixed in 8.5.1. It will be fixed in the next full version of LabVIEW.

QUOTE (jdunham @ Apr 10 2008, 03:56 AM) Thank you for including this one in your test results. I've fielded your posts out to half a dozen NI engineers to evaluate the results and see if there are any obvious slowdowns that can be patched in time for the next release. We'll see what happens.

QUOTE (jdunham @ Apr 9 2008, 05:05 PM) Oh. That's exactly what is posted to ni.com/labs. It uses the XNode polymorphism to implement the associative array. :-)

8.5.1 bug fix page works now. http://zone.ni.com/devzone/cda/tut/p/id/6927

QUOTE (Yen @ Apr 8 2008, 11:45 AM) Bug fix page now works.

JD -- would you mind going to ni.com/labs and downloading the XNode Map implementation and adding it to your benchmarks? QUOTE (Norm Kirchner @ Apr 8 2008, 10:39 PM) Reading or writing an existing attribute always results in a copy. I'm not sure about adding a new attribute or deleting an attribute -- depending upon how it was implemented, if you delete an attribute, the "deleted attribute" output may be set without a copy (aka using the same top swap trick I've described elsewhere used by queues and notifiers). You could then modify the attribute and then put it back in. I don't know the implementation details. QUOTE Sorry, AQ, but I think some problems were just not meant to be solved with by-value objects Oh, I'm pretty sure this solution will beat all others someday. From the theory side, it'll blow just about everything else out of the water. We're still in unexplored territory with this, and there may very well be some stupid implementation detail that is getting in the way. In school, I was once debugging a program that should've been blazing fast, only to find that in my delirium I had written code that instead of calculating a constant and storing it was recalculating a constant every time I needed it. It wasn't even relevant to the algorithm, just happened to be a needed constant. There is almost certainly something like that somewhere in the LVClass code. I'll grant that it may take a few years to iron out, and in the meantime, enjoy the acceleration of the variants. QUOTE At the end of the day, I don't know why NI won't prioritize adding a nice associative array function to the Queue and Notifier palette. It might be because I've never heard of this idea before. What exactly would this be?

QUOTE (jpdrolet @ Apr 9 2008, 08:20 AM) Yes. But I can't remember what they are. :-) This was very seriously discussed. If you use LV 8.5, you'll notice that there's a lot more file monitoring going on when you have a project open -- we know if you change a VI listed in the project even if that VI isn't itself open. We took that route instead of locking, but I don't recall why.

QUOTE (gmart @ Apr 8 2008, 05:28 PM) Sorry... I got burned by this one recently -- took a full day to find a bug that was already fixed in 8.5.1 if only I had recompiled -- so I'm kinda pedantic about mentioning this.

QUOTE (gmart @ Apr 8 2008, 02:57 PM) Bzzzt. Almost true, but at the end you turned it into a lie. 8.5.1 will load any VI saved in 8.5. 8.5 will load any VI saved in 8.5.1. So it is completely correct to say that the two versions are compatible. HOWEVER, this does not mean you don't need to mass compile your files. Please read http://forums.lavag.org/LabVIEW-851-Released-t10528.html&view=findpost&p=43814' target="_blank">this post from LabVIEW's product support engineer.

I have seen this situation once before. I have no idea how exactly to recreate it, but it goes something like this: Assume you have the following VI hierarchy: Alpha calls subVI Beta calls subVI Gamma. Open VI Alpha. This of course loads Beta and Gamma into memory. But LabVIEW doesn't load the block diagrams for these VIs because it doesn't need them right now. So those are still on disk. Now, while you have Alpha open, copy another Beta.vi over the file on disk. Now open Gamma and change its connector pane. Because Beta calls Gamma, changing the connector pane of Gamma will force a change on Beta. So LabVIEW will now try to load Beta's block diagram. But wait! The VI on disk is not the same as the VI in memory. We *can't* load the block diagram. At this point, LV throws up a dialog that asks if you want to revert the Beta in memory to match what is on disk. If you choose "no", then you keep the version in memory -- the one that has no block diagram. Now you save Beta. Congratulations, you just saved your VI without a block diagram. I have no idea if you actually did these things, but you may have done something similar. The big no-no is changing a the file of a VI on disk while that VI is in memory. That's the only time I've heard of this situation coming up.

QUOTE (orko @ Apr 7 2008, 03:13 PM) The GSW became a VI in LV8.0. But much of the functionality was done in C code callbacks. The GSW only began using LVClasses and having its internals accessible as of LV8.5.

QUOTE (Vladimir Drzik @ Apr 7 2008, 01:30 PM) The order should be the same as the order of the original array.QUOTE 2. I think the "non-safety" of Wait on Notification should be much more stressed in the documentation. The docs have been tweaked for future versions. QUOTE 3. I vote for adding of the "safe" version of the primitive . R&D is not at democracy, but as a benevolent dictator, I will take your request under advisement. :-)

QUOTE (Aristos Queue @ Apr 5 2008, 09:31 AM) This was closed as NOT A BUG. This is correct behavior that was implemented in LV8.5. Here's the feedback I got:This behavior is expected behavior. In pre-LV 8.5, libraries were treated as containers in app builder when it came to setting properties. So you could set inclusion, destination, etc on all items under a library via the library itself. This led to confusion since the option was not clear whether you were setting the option on the file itself AND the children or what. So in 8.5, we changed the behavior (which was documented) such that operations on a library affect ONLY the library. So, the "workaround" the user listed is the appropriate thing to do. By creating virtual folders (which do apply their settings to their contained items), he gets what he wants, without ambiguity. Let me just add this: Remember that if you prefix all the items in a class, you will be changing the name of dynamic dispatch VIs, so you must give the same prefix to the entire class hierarchy so that all the dynamic dispatch VIs continue to have the same name. If you only apply the prefix to the VIs of one class and not all the VIs of all the ancestors, your dynamic dispatch subVI calls will have different functionality than you expect.

QUOTE (ned @ Apr 7 2008, 10:08 AM) DOH! Everyone on the thread just assumed that text meant C++. I didn't even really think about the syntax there -- just assumed you had some interesting macros. Important tip: When posting code from a non-LV language, make sure to tell everyone really loud which language it is you're posting! :-)

THIS IS NOT A BUG. You can read all about it here: http://forums.lavag.org/Notifier-signals-m...tml&p=17306

One item to be aware of about the GSW that Christina's blog doesn't mention... if a user has modules installed (RT, FPGA, etc) those modules will add items to the GSW and change the available space for New / Open / MRU, etc. There are three different backgrounds that the GSW can have depending upon the modules installed, which change the number of items allocated to each region. Be aware of this. If you post to Christina (use the feedback section of her blog), she can probably get you an image of the three backgrounds and describe when each one is used so you can plan accordingly.

QUOTE (Darren @ Apr 4 2008, 11:55 PM) You're free to edit the VIs that control the new banners and private data control VIs to your heart's content. <labview>\resource\plugins\lv_newclass.vi and <labview>\resource\plugins\lv_newclassctl.vi The first sets a new class' banner, and you can add your own color cycling. The second sets the initial icon of the private data control. Actually, the first one is slightly misnamed because it actually affects all library types -- .lvlib, .lvclass, .xctl, and .lvsc. I created it for classes and the other library types chimed in that they wanted the same behavior, and I didn't rename the VI.

8.5.1 went live on the web sooner than a lot of groups expected. Have a bit of patience -- everything should be linked (such as the bug page and the activation stuff) on Monday.

Reported to R&D as CAR# 101630. QUOTE (Omar Mussa @ Apr 4 2008, 04:53 PM) Probably would've been except that this is the first time I've ever heard it mentioned as an issue. :-) As it is, it is too late to make 8.5.1, and is probably too late to make the next LV release. But we'll see if it can squeeze in. No promises.

An update to this thread: A tool for doing VI preview in Flash is now available: http://forums.lavag.org/index.php?s=&s...ost&p=42092

QUOTE (ned @ Apr 3 2008, 04:36 PM) That's true only on a 32-bit system. I'm pretty certain that on a 64-bit system, the default would be int64. And that's only with the MSVC++ compiler. I'm pretty sure that the c++ standard doesn't require any particular standard when the size isn't defined, so some compilers may not conform to this. You'd need to know the compiler used to build the DLL.

QUOTE (Justin Goeres @ Apr 4 2008, 02:24 PM) If you're using the 6 default colors that LV cycles through for the banners, you're pretty much ok with regard to the guidelines if you make the wire design match the header. Someone suggested that the wire color should be set the same as the banner color by default. What would you think of that? For myself, it would bug me, if only because yellow makes a great banner color but a lousy wire color.

QUOTE (Norm Kirchner @ Apr 4 2008, 10:45 AM) We consciously didn't put out any guidelines with the first release of classes because we wanted to see what developed in the field. This was something I was going to start asking about around NI Week, but it doesn't hurt to start here.Some guidelines that have developed: 1) Do not attempt to mimic any LV native data type. 2) Try to avoid single pixel thick, single color wires -- you never know what LV will add as a native data type in the future. 3) Any class that includes a refnum in its data OR that inherits from an ancestor that includes a refnum in its data should use refnum green (RGB = 0x00c6c6), regardlesss of wire pattern. 4) Avoid using gray for the edge background color -- becomes hard to read on dynamic dispatch subVIs. 5) Do not ever use pure red (RGB = 0xFF0000) as a wire color. That color gets seen as an error condition. It screams out "fix me!!" That's it for guidelines that I would recommend, based on the VIs that I've seen. There does seem to be a great reluctance to change wire pattern -- most classes just have the chain pattern with various colors.