Jump to content

Omar Mussa

  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by Omar Mussa

  1. Anyone have other ideas? Or has this one already been solved and I just wasted a half hour making pretty screen shots? smile.gif

    I have some suggestions.

    • One thing you may want to look at is Endevo's UML modeling tools. They have some interesting ways to document state machines, but this is more useful for modeling state transitions as opposed to state inputs.
    • Another thing you should consider is the design of your actual states. I may have just not looked hard enough, but it looks like you evolved into a pattern where you are passing your entire state machine data cluster in/out of each state VI. This is actually contributing significantly to the complexity of documenting your API. I would suggest that you consider changing your API to VIs within each state in some way such that you are no longer doing that.
    • You might consider moving to a different state machine template. I will make a shameless plug for our own JKI State Machine as its free and has received a lot of praise by the LabVIEW community (although it may not help you solve this particular aspect of documentation, you will find it has a lot of nice self documenting aspects related to state organization and it integrates with the Endevo UML tool as well).

  2. I discovered this when my executable wasn't working. I opened the VI and found that somehow some string constants in arrays in a cluster got wiped out (the arrays were emptied). This has happened a couple times now so I'm sure it wasn't a goofy slip on my part. There's no way I could have cleared 5 arrays without knowing it. Has anyone had something like this happen.

    It depends... Is your cluster also a type def? - if you edit the type def, you may lose the string array constant data. Even if it is not part of a type def, editing the cluster could result in your string data being lost. You may want to change the way you are initializing the data -- either loading it from a file or manually bundling in the data to prevent changes in your cluster from affecting the string array values.

  3. This sounds extremely interesting! Are you able to elborate, give a sneek peek or show us a demo vid (jing)? :worshippy:

    Unfortunately, we don't have anything to show yet because mostly we have design patterns that still need to evolve a little before they can become 'tools'. Generally, what we have done is utilized Windows API calls for keyboard and mouse emulation and used control references to validate the properties of UIs that we care about.

    • Like 1
  4. I would like to see some designs/implementations that allow for hardware simulation for automated Unit Testing.

    Part of test driven development will always come back to design. One of the key benefits of unit testing in general is that it forces you to think of your code in terms of APIs. Your unit tests are actually testing the API to your internal code. If you can't test your code without hardware, you don't have a good API to your application logic code. There are different ways to enable simulation: Adding a simulation input (or property), using LVOOP and inheritance to create a simulation implementation of an abstract class, etc. Creating unit tests forces you to think about your code's interface at an early stage (or even at a later stage when you may need to refactor code and want to validate that it isn't broken).

    One thing that I think works particularly well in VI Tester is the ability to use the test harness (VIs that are called before and after each test) to do things like set a simulation flag so that your tests run your VIs in simulated mode.

    Appart from the hardware issue, I wonder how to deal with UIs.

    At JKI, we currently are able to do UI testing using VI Tester and are running these tests to validate certain VIPM features. Adding UI testing capabilities to VI Tester is on our roadmap.

    I was experimenting with Unit Tests without any framework yet, just to understand how it works.

    I really recommend that you investigate whether VI Tester would meet your needs, trying to create unit tests without a framework is a fairly arduous task and will ultimately cost you more time than investigating tools that already exist. You may as well leverage the years of effort that have gone into the existing tools rather than start from ground zero. Besides that, VI Tester is free, so there really isn't a barrier to entry :)

    • Like 1
  5. PS - Unit Test? What's a Unit Test? We don't need no stinkin' Unit Tests! (I misread Mr. Mussa's poll as "NO Unit Test Framework" and voted for that. I've since fixed my answer.) That feels like another purchase request that would be shot down. At least there's an alternative.

    Maybe I should have had 2 options -- 'None' and 'What's a unit test?' ... polling is a tricky thing to do right I guess.

  6. Would you explain it better?

    Here's a reference on what unit testing is all about:


    My summary is this: unit testing is a software engineering process for validating that your code functions as expected. You basically write tests to validate that your code works as expected, if your tests fail then you update your tests or your code until they pass. If all of your unit tests pass, then you have a level of assurance that your code works as you expect (as defined by the unit tests).

    What is useful about unit testing is that if you need to change your code (say, to make a sequence into a state machine), and you have created unit tests, you can validate that none of your changes have caused you to 'break' your previous logic simply by re-running your unit tests.

    P.S. the really problem what I have is to extract a testing unit from a whole project for testing. I use many hardware and parallel loops with QSM, so...

    In order to make you application logic more easily testable from your hardware interfaces, you may need to consider how you will test your code when you design your code. For example, you may want to create a simulation mode or abstraction layer that lets you test your application logic with unit tests, independently from your hardware interface code.

    • Like 2
  7. There is actually a method for updating cell data for a table. Use an invoke node and you will find it. It allows you to update a single cell without updating the whole table.

  8. QUOTE (ShaunR @ May 9 2009, 03:37 PM)

    And (from what I can tell) to use the class abstraction, I need to wrap every function that is already supplied by the manufacturer just so I can use it for that project. Take the Agilent 34401 example in the examples directory for instance. If I want to use that in your Architecture, do I have to wrap every function in a class to use it rather than just plonk the pre-supplied vi's into my app which is pretty much job done?

    While you can choose to wrap every function into class methods, that is not usually an abstraction method that works well. What you should do is consider what things you tend to do over and over again and create abstractions for those items.

    For example, let's say you want to create a DMM class that supports Agilent and NI DMMs in your application. Both of these DMMs have completely different drivers required for configuring a voltage measurement, but essentially, they both perform the same operations. You can create a DMM.Configure Measurement method with an Agilent (Agilent.Configure Measurement) and NI (NI.Configure Measurement) implementation (and Simulator, and future hardware you haven't yet purchased, etc). What's nice is that you separate your application logic from your instrument specific drivers that 'implement' that logic.

    This is what object-orientation is all about -- irrespective of Daklu's 'Extraction Architecture'.

    Daklu's architecture is trying to go one step further -- so that if you have other instruments that have overlapping functionality, you can implement an interface (exterface) that both of the instrument classes would implement (feel free to correct me if I'm wrong). I'm not sure how succesful his implementation is, I briefly looked at it but did not look long enough to fully understand it.

  9. QUOTE (hooovahh @ Apr 16 2009, 05:37 AM)

    It seems that alot of the things they make are aimed at beginners and usually aren't the kinds of tools I would use. That's not saying I don't use NI toolkits, I'm just saying that I realize NI would probably rather make things that bring in new customers rather than making tools to help their existing customers.

    I'd have to say that NI has done a decent job lately (last few years) of creating tools that are aimed at their existing customers. I'm not actually using these toolkits right now, but if you look at the state-charts, execution-trace, unit-test, etc. they are not targeting any of those toolkits at "new" users of LabVIEW.

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.