Omar Mussa

I've been bit by this bug but wasn't sure how to reproduce it! The only 'workaround' I know of is to label each dynamic event frame (like you did in the video) so that whenever you add/remove events to the 'register for events' node you can validate that the events weren't remapped.

We use FogBugz. It is powerful and easy to use.

QUOTE (Ale914 @ Feb 9 2009, 11:05 AM) Wow, that is awesome!

QUOTE (Aristos Queue @ Feb 3 2009, 09:48 AM) Sound like you need to be involved in some more internal design reviews I don't expect these problems to be easy to solve -- if they were, none of us would be working on them! I'm glad that LAVA provides a platform for discussing them at all :thumbup:

Congrats AQ, I knew you could do it Now, time to start developing new LabVIEW features using your new 'certified' LabVIEW skills...

QUOTE (Jim Kring @ Feb 2 2009, 05:58 PM) Sort of, a lot of people are use 'Reflection' (google reflection and unit testing if you don't believe me ) to dynamically scope the private methods as public in order to test them (using other languages like java). I can imagine all kinds of s*!@ hitting the fan when doing that in LabVIEW since any class methods that happened to have the same name as the method you changed to public would be broken (due to not having dynamic dispatching enabled but being a part of the same class hierarchy). Also, so far this http://www.onjava.com/pub/a/onjava/2003/11/12/reflection.html?page=1' rel='nofollow' target="_blank">link was the easiest for me to understand regarding reflection and unit testing -- I'm not a java programmer but its fairly digestible.

QUOTE (Aristos Queue @ Feb 2 2009, 05:16 PM) I can almost never hit the run button for my class private (or public) member VIs. They often depend on data existing in the private class data -- some of that data could be queue references or other things that need to be created first. That is practically the whole point of having a unit test framework -- you can use test harnesses (setup/teardown VIs) to initialize data you want to have for each test and validate that the tests work in isolation from other tests. QUOTE (Aristos Queue @ Feb 2 2009, 05:16 PM) And if you just want to run a quick test, it should be just as easy to run the public VI that calls your private VI as it would be to run the private VI directly. I think the problem is one of practicality. Its hard to know a priori exactly which public VIs will call private VIs (especially for VIs that are utilities set to private) -- but we do have a well defined VI that is the 'private' VI -- so it seems like it is reasonable that if we want to test certain ranges that we know public API VIs will need, we should be able to test those ranges. The problem with adding to the Public API to do this is that I don't want my Public API to get harder to describe/more verbose than it has to be -- for example, I don't want a VI called 'TestPrivateMethodX' that is a public member of my class. QUOTE (Aristos Queue @ Feb 2 2009, 05:16 PM) When we start talking "test suites", I'm thinking nightly builds and automated testing on a regular basis. Those auto tests have no business, IMHO, running the private VIs because, as I said, a parameter sweep across them may result in false error reports or may put your object into an unexpected bad state that can never actually occur in real uses -- and I do mean *can* never occur not *should* never occur. That's the thing about privacy enforced by the compiler -- outsiders *cannot* call that VI with arbitrary values. Since this *cannot* happen, we don't have to worry about testing for it. Parameter sweeps across private VIs are probably not the only use case for testing private VIs. Another reason unit tests are 'useful' is for enforcing that changing your code hasn't created bugs. Since I can't unit test my private VIs properly, I can't be certain that making changes to private VIs did not create bugs in my public API (that I may not currently be testing with 100% certainty of coverage). So, IMO, these are valid requests from a unit test perspective. Otherwise, the answer is -- nothing should ever be private that you can't trust to work 100% of the time through your public API. Since I can't gaurantee I'm testing 100% of my public APIs interface with its private members, I'm basically asking for trouble. I don't like that answer from a practical perspective.

QUOTE (Aristos Queue @ Feb 2 2009, 02:54 PM) Yes, you may find legal problems as well (I know it was badly out of context and edited but I couldn't resist ) QUOTE (Daklu @ Feb 2 2009, 04:16 PM) I'll tell you why *I* write test cases for private vis, but I'll leave it to those smarter than me to debate the 'correctness' of doing it. Many of my classes are hardware dependent and I don't always have the hardware available to test the class as a whole. Testing sub vis gives me some confidence things will work when I connect to the hardware. This is actually a design issue with your application that you should address. One of the great aspects of having LVOOP with inheritance is that you can create a parent class 'Rain.Abstract' and then have two children that inherit from it called 'Rain.Hardware' and 'Rain.Simulator'. This means that you can run all of your unit tests on the simulator implementation to flush out your object API and then rerun the tests when hardware exists by using the hardware implementation. This should significantly cut your bugs down -- ideally you'll only find issues where you either didn't simulate properly or you didn't imeplement the hardware (i.e. drivers) correctly. One thing that writing unit tests does is that it forces you to 'FIX' your applications design issues so that you CAN unit test them (especially if you are doing 'Test Driven Development'). VI Tester can really help you with running tests of this nature -- For now, you can create a test object and in the setUp you can choose whether to create a hardware or simulator instance of your object to test. On the VI Tester roadmap is supporting test cases with inheritance so that you could create all of your unit tests in a 'Rain.Test' class and then have a 'Rain.Simulator.Test' class that creates a Rain.Simulator object in its setUp and would allow you to extend the Rain.Test class... We're still actively working on making this feature work well so that's as much as I can say for now.

QUOTE (crelf @ Jan 23 2009, 03:13 PM) You're lucky restart worked... Does your project have LVOOP Classes? I've noticed that occasionally I have issues where a class wasn't saved properly so it has a missing member and other kinds of issues that sometime manifest themselves as an error that is basically un-explainable from the error dialog. I don't have a specific example at the moment or a way that I produced them -- also, I tend to develop in LV 8.2 still so some of the issues may have gone away.

QUOTE (Aristos Queue @ Jan 15 2009, 10:00 AM) I now have a workflow to generate the problem in LabVIEW 8.2. Still not tested in 8.6 but I'm going to guess that it still exists if nobody reported it in 8.2. Here is the problem -- if you modify the child class documentation property for a class whose parent class is not in the same project, then the child class will lose its inheritance info. Open the attached lvproj. Open 'my method.vi' -- notice it is executable. Now change the documentation property of the class and it will break the method. Please post the CAR here so I can track it. Thanks!

QUOTE (Aristos Queue @ Jan 15 2009, 10:00 AM) I now have a workflow to generate the problem in LabVIEW 8.2. Still not tested in 8.6 but I'm going to guess that it still exists if nobody reported it in 8.2. Here is the problem -- if you modify the child class documentation property for a class whose parent class is not in the same project, then the child class will lose its inheritance info. Open the attached lvproj. Open 'my method.vi' -- notice it is executable. Now change the documentation property of the class and it will break the method. Please post the CAR here so I can track it. Thanks!

QUOTE (Aristos Queue @ Jan 14 2009, 03:21 PM) Not that I know of -- the class is fairly small. I'll try to reproduce it from another blank project.

QUOTE (Aristos Queue @ Jan 14 2009, 03:21 PM) Not that I know of -- the class is fairly small. I'll try to reproduce it from another blank project.

I'm still using LabVIEW 8.2.1 for some of my projects and I just ran into a strange LVOOP bug. If you change the class description property (right click on class-->Properties-->Documentation) and press OK to close the dialog, the class will lose its inheritance information. I haven't tried this on a more recent version of LabVIEW to see if it was fixed. Is this a known issue? Is it there in 8.6? Its annoying because it breaks a lot of class member VIs if all of a sudden they are no longer in the same class hierarchy. I'm going to avoid documenting my classes for now.

I'm still using LabVIEW 8.2.1 for some of my projects and I just ran into a strange LVOOP bug. If you change the class description property (right click on class-->Properties-->Documentation) and press OK to close the dialog, the class will lose its inheritance information. I haven't tried this on a more recent version of LabVIEW to see if it was fixed. Is this a known issue? Is it there in 8.6? Its annoying because it breaks a lot of class member VIs if all of a sudden they are no longer in the same class hierarchy. I'm going to avoid documenting my classes for now.

QUOTE (c.LEyen @ Jan 7 2009, 02:27 PM) First, I will qualify that I haven't used DIAdem 11, so I'm not sure exactly how the latest version applies to these comments but I believe they are valid (my last project was in DIAdem 9, I did take a look at DIAdem 10 but did not have any projects). I will only point out what I think are DIAdem's strengths for now since I don't really know enough about your project. Hopefully this will help, I recommend you use the demo version and see for yourself what kind of time investment it will take and whether that is worth it for you. DIAdem works well if you have a lot of different sources of data (ascii, excel, database, etc) and need to aggregate them together. DIAdem works well if you can have at least 1 person become 'the expert' on your team. There is (in my opinion) a fairly significant learning curve to become a DIAdem expert - so unless you have the resources to make someone and expert, it may not be worth the effort. The expert should have a good understanding of the data formats you want to support, VB/vbscript, LabVIEW (optional actually but can be useful), and ActiveX, esp. w.r.t. generating MS Office reports. It may be worth your while to get consulting help on setting up your initial architecture if you plan on doing complex reporting. DIAdem works great if your data is 'compatible' - meaning that the built in tools can parse your data easily -- this is not necessarily the case for complex relational databases which generally require customization on your part to get the data in how you want to see it. If your data is not 'compatible' -- for example if it is a custom binary format, you can create a 'Data Plug-in' pretty easily that makes it easy to import your binary data. DIAdem does have a lot of really cool tools for engineering data analysis. DIAdem and LabVIEW can interact - if you are comfortable in LabVIEW, I would recommend doing all of the GUIs in LabVIEW and having some kind of 'report engine' that you can call that implements any DIAdem vbs required for report generation. Good luck!

QUOTE (c.LEyen @ Jan 7 2009, 01:05 PM) What is your use case? What are you trying to achieve? DIAdem is a tool so whether to use the tool depends on what you are trying to accomplish.

QUOTE (crelf @ Jan 7 2009, 08:40 AM) I don't know why, but I REALLY want one

QUOTE (Val Brown @ Dec 18 2008, 12:25 PM) There are many examples of VIs that have been 'transitioned' into LabVIEW as a result of OpenG (fees have not been involved to my knowledge ...). So if you want to wait for NI to 'transition' VIs from OpenG, that's your choice. I, for one, am glad that I don't have to wait for NI to create every function or framework that I need or use.

QUOTE (Val Brown @ Dec 18 2008, 07:47 AM) I think that it is more like there are multiple tools (design patterns, etc) and so you can choose which tools are appropriate for the problem that you are trying to solve. I don't think this defeats any rationale for LVOOP.

QUOTE (Callista @ Dec 3 2008, 12:20 PM) This is probably the coolest LabVIEW homework problem I've seen! :thumbup: Where are you taking this class? What is the class name/instructor? Also, you might try using formula nodes instead of the math function nodes as it can become difficult to figure out what your formulas are doing when they are spread via the math primitives for complex operations. I usually avoid the primitives if I have to do more than 2 or 3 mathematical operations. You can consider using both too, formulas where appropriate and math primitives where it is easier -- the goal for yourself is readability -- can you look at the code and basically understand what is happening or do you have to sit and stare for a few minutes before everything becomes clear. Good luck with your project, you look like you are making great progress!

Yesterday I spent a few hours chasing down a memory leak in some code. It reminded me of a few things: 1) The value of reusable code (this VI should have been a reusable VI) 2) The value of unit testing (I wasn't unit testing) 3) The value of running long/overnight tests (until we ran the burn-in overnight test we didn't catch this problem). Basically, I was using a semaphore as a lock to some hardware resources. I accidentally used the wrong check for 'Not A Refnum' which results in creating a new semaphore every time the code executes. Here is the correct way that fixes the leak: Hopefully this helps someone avoid a few hours of debugging a memory leak that shouldn't exist in the first place! It would be nice if the 'Not a Refnum' primitive could do some kind of internal casting and checking so that both VIs would work -- but at least I won't be making this mistake again (and since I'm adding it to our company's reuse pool, hopefully nobody else will either!).

QUOTE (kmc @ Nov 13 2008, 11:27 AM) I don't have them on my computer any more. You should be able to easily re-create them from the screenshots, they took < 5 min to make so I'll leave it to you to redo the work. Omar

Does anybody know how the answer to this questions is affected by a For Loop with a Conditional Terminal? My guess is that at least LabVIEW has an upper bounds to the array size prior to execution so C is probably still "correct" (assuming it is C) but I think this question becomes even more confusing when you think of the Conditional Terminal case...

QUOTE (jcarmody @ Oct 31 2008, 05:03 PM) There are two parts to this response... 1) One 'feature' of the JKI State Machine is that the empty string case ("") is also the "Idle" case. This means that whenever you finish executing a macro or a series of states, the state machine will return to "Idle" 2) Adding 'Idle' or an empty string in a 'macro', which we can define as any time that you try to queue up multiple events, can and will get you into trouble in a state machine. Here's a scenario assuming you have the states: Go, Wait, Idle, Stop Let's assume that 'Go' only happens when 'Wait' completes and that 'Stop' is only reached when the user presses a button that is handled in the 'Idle' frame. The Wait state contains the following logic: Wait until time elapses -- if time elapsed 'Go' else 'Idle + Wait' Now -- let's imagine that the 'Wait' time did not elapse (queue contains 'Idle','Wait') -- it is possible for the user to press a stop button which gets handled in the 'Idle' frame due to the event structure, and then the state machine would still proceed to 'Wait' (b/c you queued it already in the 'Idle+Wait' logic) and it is possible that the new 'Wait' state time has now elapsed so the 'GO' frame is reached. This sucks for the user -- they pressed 'Stop' but the state machine still hit a 'Go' frame... now it means you are stuck adding more logic to the 'Stop' frame to handle this scenario -- your code gets uglier, is less scalable and basically you realize that you have all kinds of potential logic problems. So avoid en queuing "Idle" -- let "Idle" come whenever your state flow ends. One way to avoid this is to have a 'flag' type of system -- Setup a Boolean called 'Waiting' and set the 'Waiting' flag whenever the user starts to Wait -- then, in the 'Idle' case, use the 'Timeout' frame of the event structure to check if you are waiting -- if you are waiting then do some work, if not, stay Idle. Here is an example of what I mean: Set the Waiting flag: Check the Waiting flag: Initializing and resetting the flag is left for the reader. One thing to consider -- since you have to reset the flag from at least 2 places (usually because the wait time has elapsed or 'Stop' button is pushed) -- it makes sense to have resetting the flag performed in a state (for example, based on your naming conventions -- 'Sequence: Stop Wait'). QUOTE (jcarmody @ Oct 31 2008, 05:03 PM) I appreciate the time you spent on your response and I'll definitely refer back to your suggestions and take the advice. Good luck in writing better code! A lot of the time, good code is the result of good design. Entropy pretty much prevents good code from just being 'realized' by accident