PaulL

I think this is also important to consider: As I understand it, you can now deploy MathScript code to real-time targets. On the other hand, NI took all the MathScript functionality out of LabVIEW/Developer Suite and put it in the MathScript RT Module. So be wary that if you are developing MathScript scripts in earlier versions of LabVIEW you will need to purchase a toolkit to use them in later versions. Or am I missing something?

Classes in a project library (.lvlib) are extensible, even though the project library itself is not.

A design pattern may be appropriate here. (Keep in mind not everything warrants a design pattern.) If what you want to do is, for example, process data appropriately for each type of sensor, or graph the results, or save it, and the algorithm varies according to the type of sensor, then consider the Strategy Pattern.

Correction: I wrote above that a Java Interface supports multiple inheritance. I don't think that's correct. I think what I should have said is that an object (classifier) can implement more than one interface. I think that's correct. Maybe somebody can clarify this? Anyway, UML 2.0 in a Nutshell, Dan Pilone, 2005, p, 30, has a pretty helpful explanation of interfaces. It says, in part: "An interface is a classifier that has declarations of properties and methods but no implementations. You can use interfaces to group common elements between classifers and provide a contract a classifier that provides an implementation of the interface must obey. ... Some modern languages, such as C++, don't support the concept of interfaces; UML interfaces are typically represented as pure abstract classes." Head First Object-Oriented Analysis & Design, McLaughlin, Pollice, and West, 2006, has a good discussion on coding to an interface (how but also why).

I thought about the last statement I just made. What I mean is that when I define a software interface (generally speaking, according to your second definition) I am describing attributes, signals, method signatures the software must implement. I am very definitely not defining how to implement the required behaviors. That really is what an Interface (e.g., Java meaning) is and why the methods are abstract (pure virtual). So, if we apply this to the State Pattern or the Strategy Pattern, we realize that if we don't include behavior on the top-level class that we can always implement a new State or Strategy class beneath it without breaking existing behavior. (For instance, that behavior we thought always applied doesn't apply in some strange case). What we can do is add a superstate (as an abstract class, but not an interface) at the next level to capture all that common behavior. We ensure flexibility but add an extra class. In principle, at least, adding the extra class is a good idea. (The question is whether it hurts the application's performance, which in principle, at least, it definitely shouldn't.) Interesting indeed!

I agree in software development interface can have either meaning you mention. In UML, though, the meaning is really more specific; on the other hand, if we are generating code we can interpret this as we see fit. For instance, if we are developing a UML model using the Java template, an Interface will support multiple inheritance (while a Java class will not). (In C++ any class can support multiple inheritance. In LabVIEW nothing can.) So in these instances a UML interface has a very precise meaning. On the other hand, I create interfaces (either as abstract classes with I as the first character in the name or as true Interface types) to represent what I consider to be a software interface in LabVIEW. Moslty I just want to capture the signals and methods a given interface must implement so I can use these on an interaction diagram. In this case I choose to use this more in line with your second definition of interface, although both meanings are really pretty much the same when you think about it.

The use of these terms has been a matter of some confusion here as well. abstract method--fully agree with Dave's definition. This corresponds with its usage in T. Budd, An Introduction to Object-Oriented Programming, 3d ed. In C++ this is apparently a pure virtual method. (I'm basing this on Budd, p. 170. I'm not a C++ guru.) abstract class--C. Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3d ed., defines this as "A class that can be used only as a superclass of some other class; no objects of an abstract class may be created except as instances of a subclass." That is how we use the term. What this means to us is: 1) we never instantiate an abstract class (just a restatement); 2) child classes override its methods (though it is not always necessary for every child to override every method), but the method definition in the abstract class may or may not be (in C++ terms) a pure virtual method--that is, it may have some common functionality that is called in the child implementations. This differs significantly from Dave's usage. interface--Budd, p. 170, writes, "A class can have abstract (or pure virtual) methods and nonabstract methods. A class in which all methods were declared as abstract (or pure virtual) would correspond to the Java idea of an interface." This matches Dave's description of abstract class above; I prefer to reserve interface for this following Budd. (I guess this also means that all children must implement all the parent methods.) The upshot: LabVIEW doesn't explicitly support the concepts of abstract classes or interfaces. We can approximate them by creating classes that fit the above definitions. In our implementations of the State Pattern (which has the same architecture as the Strategy Pattern) we define superstates that, of course, we never instantiate. (We only instantiate leaf classes, of course.) We do, however, allow for the methods on the superstate classes to include behavior common to their substates. (This makes sense, of course, because it means we don't duplicate the code unnecessarily.) Such a solution fits with the definition of abstract class from Larman I gave above, so we consider (in LabVIEW and in UML) such superstate classes to be abstract classes. [Hmm... I see that in Head First Design Patterns the top-level State or Strategy class are interfaces, which means that the top-level class has only abstract (pure virtual) methods. We started out that way but now we allow the definition of common behavior even in the top-level method--making the top-level class, then, abstract but not an interface. I'll have to think about that. I don't think there are any downsides to adding this behavior, provided all the substates really do use that behavior.]

In 8.6 Developer Suite subscribers received quarterly updates with bug fix releases. Those were essentially the same as Service Packs except NI didn't call them that then. The main thing is now NI has stated the plan is to do a major release and a service pack each year.

Hmm... that doesn't apply in our case. We are using DSC but not the functionality that requires that checkbox to be true.

I saw the same thing a couple days ago. I'm not sure what the cause was. Here are some of the details. My colleague had installed a demo version of LabVIEW 2009 on it. I wanted to install a version 2009 executable on that some computer. So we uninstalled LabVIEW (but not quite all things NI because there was an executable installed that we didn't want to remove). Then we attempted to install the LabVIEW 2009 RTE and the 2009 DSC RTE. The former noted that some newer components were installed (so?) and then canceled the install. The latter install succeeded. If I tried to run the executable I saw the same unsupported languages messages. (We installed a 2010 version successfully on that computer.) Does this sound similar to what you saw? What did you do to resolve the issue, if you were able to resolve it?

Yes, congratulations and thanks! Here's to many more years! Paul

We do use the Read From XML File Unflatten From XML functions in RT (2009 SP1 on VxWorks for the moment) to read configuration files and these work fine. (These just support the LabVIEW XML schema.) Are you trying to use the XML Parser VIs, then?

Can you clarify what the LabVIEW software must trigger? If it just must initiate the move you might consider an off-the-shelf controller. Alternatively, you can do the motion profile or the servo control itself in LabVIEW, on an RT or FPGA platform. The cRIO is indeed a good option if it suits your needs. What are the environmental requirements?

I model messages (in our case we use Shared Variables) as Signals in UML.

Felix, I think creating some surveys is a great idea. I did some further thinking on these topics... I think NI would really only needs to get involved seriously in UML tool development when we are talking about UML-LabVIEW integration. Levels of UML language integration: Enterprise Architect (EA), for example, provides a dialog to create data types for a language. I have done this--it's very easy!--for LabVIEW basic types (not an exhaustive list--just what we need) and I will attach the resulting file. Just import it into EA (I can provide detailed instructions if necessary) to use it. The next level is to define more complex types and their rules. For instance, a LabVIEW cluster contains attributes but no methods and does not support inheritance. (Just for modeling purposes I just use a class and give it a cluster stereotype. It doesn't mean anything special to EA but it works well enough since I don't do code generation.) One could change the metamodel, but likely one usually implements this as a profile for the particular language, as you suggested. I think this is fairly straightforward, too. (I don't know for sure whether EA uses profiles here, but they support modeling and even code generation in 10 languages already.) Lastly one needs to be able to generate code from the model and model from the code. This requires by far the most work, I think, and the most input from NI. It is where the real work is, and Symbio, for example, has done an outstanding job with this. Need for UML-LabVIEW integration: This is not obvious. Personally I have opted for a tool that offers integration with other toolsets instead of just code generation, and certainly others in this thread have expressed a lack of interest in code generation capability. On the other hand, I wonder.... First, I think Model Drive Development (MDD) in general has taken off faster than expected. I tend to think I like to write everything myself, but then I think about how I work: I model the architecture in UML first (statemachine diagrams and class diagrams, at least). I specify the classes with their attributes and methods (just the names), and the relationships between them (some of which I can't visualize in LabVIEW). It is orders of magnitude faster to create classes, give them attributes and methods, add relationships, and refactor everything in EA than in LabVIEW! (Partly this is because we don't have to deal with files at this level.) When I finish the model I build the classes in LabVIEW. I do this by hand, but implementation of the model is an exact process. Each package (roughly, each diagram) in EA becomes a virtual folder in LabVIEW (and a real folder on disk). Actually, at least each package-controlled package should become a .lvlib. (We're moving to that.) Each class within a package maps to its own folder on disk, and so on. I create each class with its specified attributes and methods (VIs). As I said, I do this by hand, but there is actually no benefit to doing so and the truth is automation could save me many hours quite quickly. Then, of course, as I work I often add some detailed methods in LabVIEW I didn't think about ahead of time. Right now I have to make the changes manually in the model if I want to keep it up to date (which I do). It would be fantastic to be able to use reverse engineering here. Basically, synchronizing the model and code would mean that I would have to make a change only once. Then, of course, I spend time filling in the diagrams for each method, which is where I really want to spend my LabVIEW time. Vision Ideally I would be able to create a model in EA or a similar tool and generate the classes in LabVIEW from that tool. Then I would be able to click on a method in the project and fill in the details in LabVIEW--and then just save. Note that I would never have to open a file browser (well, OK to point to configuration files and the like maybe)! The model tree and the code generation would handle that! (EA does this very well! I check out a package, make changes as I need, and then check in the package. EA handles all the version control. It would be quite straightforward, albeit a fair amount amount of work, to extend this concept to the LabVIEW files as well.) Then I spend my LabVIEW time writing code for the methods. Moreover, I would be able to integrate LabVIEW with all the other software engineering technologies I have at my disposal. This may sound like a far-out dream, and I wouldn't dare to even think in this direction, except that basically all the required technologies already exist. In fact Symbio has gone further and added LabVIEW integration with the behavioral aspects of UML as well! That is really cool! (By the way, I am a huge admirer of what Endevo/Symbio has done--way more than I would have thought would have happened by now, and my impression is that they have done it extremely well.) Bringing technologies together My overall perspective is that we have a lot of really cool technologies (from NI, Sparx Systems, and Symbio) in particular. I think each is wonderful and powerful on its own. I think, though, that if we combined these technologies we would have a really amazing enterprise toolset. (Wasn't NI Week 2008 keynote's main message about combining technologies? One book with a similar view that impressed me was The Nature of Technology). I think we should leverage the different technologies from the different teams to create a complete toolset. I think NI must be a player in this integration, obviously, if it is going to happen. I agree NI shouldn't spend a lot of time developing the technologies (especially since the technologies exist) but they can create the right relationships to integrate them (i.e., manage the integration). I also think they are in the best position to drive it, if the folks at NI have a mind to do so. I don't think Sparx Systems or a comparable tool maker, for instance, is going to approach NI out of the blue, and I think NI can most easily coordinate the requisite business arrangements. I also think NI has much to gain by doing so. And again, many of the pieces are already complete! Anyway, this is pretty much the direction I am thinking. I would love to get NI and as well as LabVIEW enthusiasts--especially LabVIEW Advanced Virtual Architects--on board! LabVIEWTypes.xml

SysML is the "Systems Modeling Language" -- basically UML for systems engineering. It is implemented as a profile on top of UML. It uses some UML diagrams and adds others. SysML provides a way to model all aspects (e.g., mechanical, electrical, software systems) of a system in a single unified model. SysML provides capabilities to model system requirements, architecture, behavior, and parametrics. It can support simulation for trade studies and so on. You can think of it as CAD for systems engineering. --- We are especially interested in using requirements for requirements management. We are starting to use it in particular for capturing and allocating requirements because it offers the following benefits for that purpose: 1) The most important reason is because we can capture everything in a single model in a (standards-based) tool specifically designed for that purpose. This means that, for instance, if I define a set of common requirements in a package in one project file, I can retrieve the relevant package in another project file. I can add only the relevant requirements to the target diagram. (In a document-centric approach I have to decide whether to duplicate requirements or just reference an entire document. The first option creates a maintenance problem and the latter is very often problematic for the reader.) 2) Each requirement is a unique model element. I can link semantically meaningful items (e.g., <<rationale>>). (These are currently possible in requirements management database tools and you can make this work in a document.) I can create semantically meaningful links (e.g., trace, refine) between requirements. Moreover, I can create links (satisfy) to Test Cases and detail the test procedures, and I can display all of these visually on a diagram. The links help us ensure traceability across the enterprise. Ultimately, this means we have a real chance to maintain the requirements, do real traceability, make sure people actually read them, and consequently, we hope, meet them. --- OMG's page on SysML offers a start (OMG) The best book I have found on SysML (by far) is A Practical Guide to SysML. Paul

Well, that certainly is an important point to consider. Can you give any examples? I just went to the UML Modeller page and the only thing LabVIEW-specific I see mentioned is the icon editor, which is just a matter of how the classes are implemented (part of that IP to which I was referring). I haven't use UML Modeller so I don't know much more than what appears on the page. --- I did reflect on the general topic a little more, and I will say that the requirements for a UML tool do depend on how one uses such a tool. Our team uses the tool we selected for modeling designs and defining interfaces, but also for modeling requirements in SysML, linking these to model elements and test cases with test scenarios that we export to a test tool, generating code in Java, and providing traceability between all these. Hence we have opted for a full-featured tool even though it doesn't support UML integration. I know of at least one other developer on this site who, if I understand correctly, decided that the LabVIEW-UML integration was more important and hence chose a different tool. It sure would be great if we didn't have to choose one or the other option.

Done! http://forums.ni.com/t5/LabVIEW-Idea-Exchange/idb-p/labviewideas/tab/most-recent I do agree that there needs to be a large enough user-base to support LabVIEW-UML integration. On the other hand, I think much of the integration IP already exists since the Symbio tool exists. (I realize Symbio may own a good portion of this IP.) What remains is to make a business decision that will incorporate this IP into a more capable tool. I can speculate (and that's all this is!) that that might mean beefing up the Symbio tool or working with Symbio to sell the mutually developed IP to a vendor with a more capable tool (resulting in appropriate benefits to Symbio, of course). Really, is NI serious about LabVIEW-UML integration or not? If yes, then I think the plan needs to step up a notch. This actually is not my number one LabVIEW need, although it is high on my list. I am just not a fan of the "sort of" approach, especially when it comes to supporting standards.

Thanks for the information on AddQ. I hadn't heard of it before. I applaud the creators for making it available for free. On the other hand, I am going to state that I think think the strategy for UML-LabVIEW integration thus far is inappropriate and unsatisfactory. I think that we should only consider tools that support the current UML standard (an open standard published by OMG). That should be a minimum requirement. Neither Symbio's tool (as good as it is) nor StarUML come close to doing that. Moreover, StarUML is not an active project and hence will never see another upgrade and hence will be an even worse option long-term. (My apologies to StarUML fans, but that's just stating it the way it is.) I think that NI has already developed the IP to take this to the next step. NI needs to make a good business decision here to make an agreement with one or more appopriate tool vendors (could be existing vendors or a new vendor) that will result in a tool that fully supports the latest UML specification and will continue to support future specifications. I think NI can make such an arrangement while benefitting all parties, and I think it will make LabVIEW and NI more competitive as a consequence.

Can you do an intermediate step and convert the structs to XML, for instance?

Cool! Thanks!

Is it possibly you can clarify which CAR exactly? CAR 233951 (which is the number I have from NI) is not listed in the fixes (but it could be a duplicate?). I did a search on 'lib' in the bug fix list and the closest relevant result was: 193210 XML parser error when unflattening a LabVIEW class owned by a library, which was certainly a bug I saw (thanks for fixing it!) but I don't think it's the same issue Daklu is describing exactly.

I think it is preferable to initialize the values of the object explicitly (not technically a constructor). This is important so that someone can understand the code. (One can't tell by looking at an object constant what it's values are. OK, one can work this out if the values are the defaults, but even in this instance I don't think it's good coding practice to use object constants this way.) If the values come from a file one can change the values without changing the code (protecting for variations).

Actually, I understand what you are doing from your description. Enjoy the sunshine!

I have been pondering for some time: Should synchronous behavior be part of the messaging system or part of the behavior of the client? (I don't know. We always use asynchronous messaging. Some of our clients send a message and wait to get some data ultimately indicating that some external event took place. But the sending client's state machine implements this behavior. I suppose for some applications truly synchronous messaging might be more appropriate....) Sorry. This doesn't really answer your question!