Omar Mussa

QUOTE(B Chavez @ Aug 20 2007, 12:31 PM) I hadn't tried running with a 0 delay... When I did I found that the values are within 10^-13 of each other. Still close enough for me not to care, but you are right about the cumulative effects of add/subtract in ther pop on/off mechanism. I think that additionally, the difference between the values would increase the larger the buffer size you elected to use.

I was recently trying to compare a few ways of calculating a running average. I was surprised that the point-by-point mean was not the same as a 'traditional' mean value. The values are only off at the 10^-15 range which makes me assume that it is a floating point value problem (and makes me feel like I don't need to spend too much time working on it) but I am still surprised that there is a difference at all (especially after the first 4 iterations in my running average (which uses a 4 point buffer). Please look at my demo VI and see if there is any other explanation. (The VI is in 8.2.1). Thanks in advance!

QUOTE(Irene_he @ Aug 19 2007, 08:13 AM) What's next, having our road signs use alien markings like 'km'?

QUOTE(Aristos Queue @ Aug 17 2007, 01:29 PM) One thing I tried and quickly decided was not worthwhile was to link projects. For whatever reason, you can stick a project within a project. I thought 'this could be cool' (which I now recognize as slang for cross your fingers cause there's probably a reason this isn't being done by your peers already) -- as this could allow me to develop one project that could later be used as a 'component' of another project. For example, I could create a set of common classes could be put in a project that could be used by other project files -- code reuse at its best. Not so fast! It turns out that if you link projects (by adding a project to a project) then all of the classes/etc in the subproject become locked whether or not a single VI is open by the superparent. That means that while I'm debugging the super project, if I find a problem in a core project, I have to close the super project to make any changes (rather than closing VIs that are located in the superproject). So, in the end I had to remove the linkage between the projects as it didn't buy me anything (if I just included the classes in the super project and removed the subproject, I could edit the classes as if they were owned by only 1 project). So, in the end, a project does have a 1 to 1 relationship with a LV Application (even though it is possible to 'try' to make it 1 to many) -- a definite shortcoming of the project environment.

QUOTE(Daklu @ Aug 17 2007, 03:19 PM) If you do take such a route, make sure to use error handling and that the 'default' case is used to generate an error otherwise you will have no feedback of 'unhandled' cases that might arise in the future... This will help at run time, the problem with your design is that it is difficult to tell at edit time if you handle every case (aside from the fact that the cases cannot be named). I would avoid this route if possible.

Here's my take. I used DIAdem from version 8.0-9 and have looked at 10 but not used it on any projects. DIADem is actually pretty good for file based data analysis (TDMS or otherwise -- TDMS is really well integrated). At the worst case you can write a custom data plugin that will get you data from almost any file format into DIAdem. I found that using DIAdem with a database (like Oracle, MySQL, etc.) is more challenging and requires a lot more technical skill. The key takehome skillset is a reasonable amount of VB knowledge (or even better VBS knowledge - but VBS seems less common and is pretty easy for VB programmers to pick up). Also, something I didn't realize until later in the game was that it is possible (even if it is cumbersome) to create objects using VBS. It is also possible to do a lot of data exchange between LabVIEW and DIAdem but I found that it was generally easier to write the code as VBS scripts than to use the DIAdem VIs (and I'm a power LabVIEW programmer -- it may be easier/better now but the DIAdem-LabVIEW API was not great when I was using it). I recommend keeping code modular and keeping scripts separated by functionality (for example having a script for each class). Utilize the NI help/support system when stuck because sometimes you run into pretty challenging problems that have already been solved. Good Luck!

Is there any technical reason why you can't just create a database using an actual database program (MS Access as worst case)? XML file structure is the most flexible format if you can't do that but you will need to spend some design time figuring out how to best accomplish your goal. Even though XML is great in some respects, it can still be difficult to visualize the actual relationships of the data by looking at an XML Structure as compared to explicitly defining the relationships in a database.

It is worth mentioning that it is pretty tough to go deep into a topic in 45-60 minutes. Especially when you know that you will have a really broad spectrum of an audience. Not everyone at NI Week is a LabVIEW Architect so it is no practical to aim presentations at that level of understanding. It is really important to organize outside of the NI space -- in the Bay Area, we are lucky enough to have a Bay Area LAVA group - Michael's XControl presentation at that meeting was ~ 2 hours long and we got to see much more of the technical detail. That being said, I think that one bit of feedback I heard, which I don't mind repeating, was that overall, NI seemed to spend less time preparing for the presentations than the independent (mostly Alliance Member) presenters. Of course there are exceptions to every rule (Stephen Mercer's LVOOP presentation was standing room only for good reason :thumbup: ) -- but the quality control of other NI presentations was criticized by many people I talked to.

QUOTE(Eugen Graf @ Aug 3 2007, 06:00 AM) Dimensions don't really have names, they really only have values... you are really asking 'how do I get the data (values) from a particular dimension of 4d array?'. You need to disable indexing on the dimension you want to 'slice out' and use constants on the other dimensions to tell LV how you want to slice the data... Or alternatively you can get a subset of data using Array Subset. In your case, you probably want all data that is in the specified dimension so using the Index Array function (similar to how you showed it in your post) should work and be easier to use.

QUOTE(Eugen Graf @ Aug 3 2007, 02:15 PM) I think of the Excel model as the easiest for visualization (to an extent): 1D = row or column 2D = sheet 3D = workbook 4D = Collection of workbooks 5D = ok, really, at some point all analogies will start to break down

QUOTE(Aristos Queue @ Aug 3 2007, 02:09 PM) Bundling/Unbundling outside of a class member VI would be a violation of encapsulation... no prob there :thumbup: . As for protected/friend properties, I'll just say I'm not passionate enough about it to argue for it at this point. I, for one, will be crossing my fingers that the automation of accessor VIs will be as helpful as advertised.

QUOTE(Aristos Queue @ Aug 3 2007, 01:49 PM) This is the age of information QUOTE(Aristos Queue @ Aug 3 2007, 01:49 PM) This is known and already fixed in a future version of LabVIEW. *sigh* So did you 'fix the glitch' (ie remove it completely) or decide to make it work despite your arguments for accessors (which btw, will ultimately need to unbundle and bundle data from a class wire)?

QUOTE(Aristos Queue @ Aug 3 2007, 01:14 PM) Aside from having a really long name, I like it! The first thing I tried to do when I saw the palette was to open one of my existing class methods, right click on a class wire and select 'bundle by name' from this snazzy new context menu with a really long name... broken wire! Doh! :headbang: And then, it hit me, or rather I hit it ... on accident I right clicked a tad further to the left of a vertical class wire ... let's call it on the left side of the vertical class wire... insert bundle by name and *presto* it actually had the bundler wired correctly. Soooo close to usable. It won't work at all on a horizontal wire as far as I can tell. So, if you can ensure that you have very precise mouse skills, you can actually bundle in object properties 'by name' without having to disconnect the broken wire and then reconnect the wire to the correct terminal of the bundler.

Thanks AQ for the update. Am sure there will be a lot of LVOOP discussion this year at NI Week as (some) people have braved the waters and actually have implemented real LVOOP use cases now. QUOTE(Aristos Queue @ Aug 3 2007, 12:47 PM) I just installed LV 8.5 evaluation and it looks like you can now 'find' dynamic dispatched VIs as expected now -- both from the traditional 'Find All Instances' and the new project 'Find Callers'. :thumbup:

QUOTE(Aristos Queue @ Aug 2 2007, 05:04 PM) I use classes. I think they are useful and powerful, however in my opinion it is not just 'stability' issues that are preventing users from adopting LV classes. I think it is still difficult to actually 'use' classes from a development/developer standpoint. Here are 5 usability issues I've found that bug me a lot (in no particular order): 1) If you right click on a class wire and select insert, the context menu you see shows '[class name] Pallete' (grayed out) and 'All VIs ...' -- I expect to see the cluster pallette so I can insert a bundle or unbundle by name (assuming I'm in a class method). If I navigate to the bundle/unbundle by name function, LabVIEW miswires the inputs and I have to manually reconnect them. This is really a bad behavior from a class developer perspective. 2) Class inheritance data is not exposed properly to child classes -- there is no protected data. I want to unbundle protected class data -- I should be able to unbundle/bundle (i.e. access) protected properties of a parent class from a child class. 3) You can't 'find' dynamic dispatched VIs using a standard LabVIEW search. This means you also can't 'Find All Instances' of your dynamic dispatch VIs. This makes debugging applications a real pain and means you have to be very selective of which VIs you want to make dynamically dispatched. 4) (This issue was raised earlier by Jim Kring but I reiterate its usability issue for me) -- you can't drag a class onto a Filepath control. This annoys me a lot -- I really hate having to do this from Windows Explorer. 5) The object primatives are not easy to find... there should be a LVOOP pallette. Its really annoying to have to navigate to the 'App Control' pallette to access functions like 'To More Specific Class' and even worse 'Call Parent Method' -- LabVIEW treats objects as second class citizens -- which then translates to the development community treating them as such as well. These issues seem painfully obvious to me as someone who uses LabVIEW a lot. I think as these issues are handled better, adoption will increase. I look forward to the next round of fixes.

QUOTE(Paul_at_Lowell @ Jul 17 2007, 09:54 AM) Search 1D Array will not work unless the object (including the object data) is an exact match (someone else can let me know if I'm wrong but I believe that is correct). It looks like you are actually searching for an object of a particular type... so why not try type casting the object until you don't get an error (use 'to more specific class' from the application control palette).

QUOTE(LV Punk @ Jun 26 2007, 04:44 PM) I think that the key to taking the tests is going in with a plan -- basically a template in your head for a generic solution that you can apply to any problem. The better your template solution is, the better you will score (it is worthwhile to try to implement this solution before you are taking the test). Also, a really good starting point for testing your approach is to look at the three example CLD exams on NIs CLD website. That said, I was really relieved to have passed!

If you use LabVIEW to build an installer (using the .lvproj 'Build Specifications') for your LabVIEW EXE and you check the box 'Run executable after installation' on the Advanced tab, there is no way to uncheck the box (well, you can uncheck the box but LabVIEW will not remove the setting from your build specification). I'm not sure whether you need to press 'OK' and save the build rules for this option or just press 'OK' when adding the EXE. If you want to uncheck the box once you get into this mode, you will need to start your build specification over (yet another reason to use a source code control system). http://forums.lavag.org/index.php?act=attach&type=post&id=6227 The CAR for this bug is: 4AP75269.

I'm not sure if this is a LabVIEW 8.2 bug or a more general bug for all versions since 7.0... If you check the box on the LabVIEW options-->Environment page labeled: 'Enable Windows Explorer for LLB files' and restart windows+LabVIEW, you will be able to view the contents of LabVIEW in Windows Explorer. http://forums.lavag.org/index.php?act=attach&type=post&id=6220 That's great. But if you decide you don't like the feature, you need to make sure that the option is unchecked in every version of LabVIEW you have installed starting at 7.0 or the option will stay 'enabled'. Its a strange behavior, and (I believe) mostly an artifact of NI not having true 'Environment' settings that are stored outside the LabVIEW.ini file and therefore are persitent across multiple installations of LabVIEW.

I just passed my CLA, too (but for the first time)! I was definitely on the edge of my seat waiting for the results!

QUOTE(Gary Rubin @ Jun 4 2007, 07:44 AM) (I believe) It is correct that operating on arrays is faster than operating on each element inside a for loop - its just that your test methodology was faulty.

QUOTE(Gary Rubin @ Jun 4 2007, 06:11 AM) That's not necessarily a valid comparison -- the 25x faster is misleading. The reason replacing the constant with a random number generator is not a valid performance test is because in the FOR LOOP version, you actually are generating N random numbers while in the primitive version you generate 1 random number.

It cannot be done. See this thread.

QUOTE(mballa @ Apr 25 2007, 07:27 PM) I had to use most of my objects ByRef and that was obviously a challenge - got help from others on doing that but there are several ways (so far, no really great solution exists but I'm positive that at least one will emerge soon). To pass object event data between loops, I generated dynamic user events. QUOTE(mballa @ Apr 25 2007, 07:27 PM) One of the biggest drawbacks that I find with OOP is the difficulty of testing public Vis. Because the object data is not visible or settable it becomes difficult to inject data and see the results. Were you able to come up with an alternative way to test Publics. I'm not currently unit testing my Publics. I didn't really come up with any great ways to do that. I did find it difficult to test Publics on other grounds though... If you set dynamically dispatched VIs to 'suspend when called' you will never see them suspend (because they are never 'called' - they are run dynamically). I ended up sticking breakpoints and temporarily saving them inside calls that were over-ride functions so that I could test the code (one more reason to avoid making everything dynamically dispatched - its a great feature but it creates a set of limitations that make it unwise to use it by default within classes). Object data visibility on the other hand is not impossible to workaround. One workaround is to create a Public and Private cluster with the attributes organized appropriately and to stick those clusters in your class data. Then you can view your attribute data easily by creating a couple of private functions for getting the data (or setting it) and using that to help debug your class. Plus you get the benefit of having your code structures looking more similar to UML documentation that you may/should have made - which is good for other reasons

QUOTE(Tomi Maila @ Apr 25 2007, 05:45 AM) I agree with Tomi. You'll have to checkin more code more often. I've found that the biggest cross-your-fingers action you can make is to change the class data, especially if you have a type-definition within the class data and you've modified it. There is a cascade of changes that LabVIEW makes when you save the class that is very 'sensitive' and often you end up with crashing LabVIEW completely (especially in 8.20, still not sure about 8.2.1). I've found that the two things I have to do to help mitigate this problem is 1) ALWAYS use the 'Apply Changes' menu option before closing a type def you've changed and 2) checking in the code often so that you won't have too much pain if you have to go backwards. I've noticed that a lot of issues come up when you try to save-all on the project, I think the save-all has some order of operation issues - for example I think it tries to save the class members first, then the class, then the project (which is good) - however I don't think it always starts with the right class (am sketchy about this myself) - and this results in the class that is being saved to crash during the save operation (because it refers to data in a class that has not been saved). This results in a crash and when you re-open the project, VIs will be missing (from both classes and the project itself) and your classes might not recompile. The best way to get around this problem is to open a VI Tree containing your class VIs outside of the project environment and then save-all. Then open the class and save it. Then close the class and open the project. Whew! If that kind of pain intimidates you, you might want to avoid LVOOP for now