PaulL

I started a new Wiki page on here SoftwareEngineeringAndLabVIEW. The hope is that community members will share best practices, experiences with tools, and configuration tips that will contribute to a more optimal development experience for all. I started things by adding a few tips on how to configure TortoiseSVN to work well with LabVIEW, something I had to do last week. I'm hoping the experts will correct any mistakes I made (I just started with TortoiseSVN!) and contribute further to the pages. (For instance, the Perforce page needs information.) I plan to add some information to the pages on other software engineering areas in the near future. Paul

I started a Wiki article SoftwareEngineeringAndLabVIEW with a page on Source Code Control and then on TortoiseSVN and how to configure it to work with LabVIEW. There isn't much there now but I am hoping all the experts will contribute! Paul

QUOTE I agree. I also was thinking we should start a Wiki page on source code control. (It would be good to have key information in one place. I'd like to share what I have found and learn from others.) I hope to set up such a page next weekend (but no promises). Paul

Hmmm... I haven't looked in detail at the issue you are facing, but I did encounter some issues with using LabVIEW classes with the Flatten to XML and Unflatten from XML functions. The CAR for this is CAR# 124834. NI traced that problem, though, to the use of Enums in the class data, not just to having a class within a class (which did work in some simple tests I did). It seems you are encountering a different problem, though. By the way, I think this is the ability to translate LabVIEW class data to XML is a potentially an extremely powerful tool! For instance, we are interested in this as a way to share data with a Java application, and as a way to send data to implement the OOP command pattern (there are other ways to do this, of course). Paul

QUOTE (giopper @ Sep 2 2008, 05:34 AM) Attached. Paul

I created a simple example (see attached) of what I was describing. Paul

If you are using VI Server then you have a reference to the VI. You can connect the VI Reference to a property node. There is a property Exec.ShowFPOnCall that you can set to False. There is also a FP.Open property you can use to control visibility moment to moment. Paul

Interesting.... I was able to write to the values of your 'Global.vi' using exactly the same steps you did to write to your subVI.vi. 'Ctrl Val.Get All' with 'Global.vi' didn't work (returned an empty array--not sure why) but 'Ctrl Val.Get' with the 'Control Name' specified (the more likely use case) worked fine. I'm using LabVIEW 8.6. So I think you are just about there (if you still opt to use LabVIEW native globals). Paul

QUOTE (Aristos Queue @ Aug 1 2008, 02:20 PM) I had just navigated to LAVA to do a search on "LVOOP XML" (after reading this http://zone.ni.com/reference/en-XX/help/37.../using_classes/) when I saw your post. Awesome! Thanks!

Robst, Are you configuring shared variable events and alarms or trying to log some other kinds of events? Did you configure the shared variables themselves for alarms and logging? Paul

This topic is of considerable interest to us as well. My understanding is there can be limitations. For instance (from Calling External APIs): "Some APIs have structure and, in the case of C++, class data types. LabVIEW cannot use these data types. If you need to use a function that has a structure or class as an argument, you should write a CIN or shared library wrapper function that takes as inputs the data types that LabVIEW supports and that appropriately packages them before LabVIEW calls the desired function." See also these discussions: using dll class-based, Struct to C++ dll. We encountered issues like this when trying to call a .dll built from C++. We gave up for the moment (but we're not great experts on calling dlls, so that doesn't mean it can't be done) and did something else. We'd love to know how to do this if there is a way.... Paul

QUOTE (george seifert @ Mar 26 2008, 01:09 PM) OK, I see the problem now. Yes, I would want different behavior, too. I don't know of a solution.

QUOTE (neB @ Mar 26 2008, 12:16 PM) Not with a property nodes. Right-clicking on the graph and checking or unchecking Auto Size Plot Legend doesn't change the behavior for this particular example. Paul

George, Maybe I am missing something, but your example seems to me to do what you describe to be the desired behavior. If I delete an element of the data array, the number of rows in the legend decreases by one when I run the VI.... Isn't that what you want (good!) or do you need something else? Paul

I use UML and I like it, but I haven't done enough "production" design yet to say how useful I will find it long term. I have found it quite helpful for working out state pattern designs, conveying an understanding of system architecture, and modeling interactions, to give a few examples.

Tom, I think I encountered the very same problem recently (depended on whether RT FIFOs were enabled or disabled, if I remember correctly). (Hopefully I'm not confusing two issues. It's possible. Let us know if the solutions below work.) NI support found the problem (and workarounds): Cause: "a race condition where the variable attempts to transmit an initial value before the read subscription to the variable has been fully established. This puts the variable in a bad state and causes an invalid error condition to be set." Workarounds: "[F]orce a read of the variable before writing an initial value to the variable." "gnore this error if it is returned by the first read of the shared variable. The error condition will be cleared once the variable subscription succeeds, and variable communication should function normally from that point on."

See this link: LabVIEW MathScript Functions.

Reading and writing to networked shared variables from Linux (and Macintosh) with the DataSocket API IS supported in LabVIEW 8.5 (for the first time). See Table 1 here: http://zone.ni.com/devzone/cda/tut/p/id/4679. In my case I was typing the machine name for the computer in the url (works fine on Windows), but on Linux one has to use the IP address. D'oh! It works now! (The format is psp://computer/library/shared_variable.) Paul

I am trying to read and write network shared variables from Linux and have not had immediate success. Does anyone know the secret? We are using LabVIEW 8.5 and the DSC Module. The shared variables are (necessarily) hosted on a Windows machine. I am able to read and write to the shared variables from a second Windows machine using the psp:// protocol and DataSocket Read/Write. (Interestingly, dstp:// did not work--not a problem, I just didn't know it wouldn't. Also, I was only able to make psp:// work once I had opened the Shared Variable Monitor on the remote Windows machine--not sure if that is always true. The variables do not appear in the Shared Variable Manager on the remote Windows machine.) I am using the same psp://machine_name/library_name/variable_name string input on the Linux machine with DataSocket Read/Write, but I get error 1184 here. (The DSC Module and therefore the Shared Variable Monitor are not supported on Linux, but the DataSocket API for shared variables is....) For the record, I have temporarily disabled the firewalls on all three machines to remove that as a potential issue. Anyway, I haven't been at this long but I haven't found any solutions yet, and I was hoping that the wonderful people at LAVA would know.... Paul

For the record, the following seems to work (thanks to NI support!): Select the class in the Items tab in the project and do a Save As... Rename to put the class in the desired folder in the user.lib. Then in the Files tab select the class methods in the old location and use the Move on Disk... option. The old directory will disappear from the Files view if there are no other project files in that folder. (Be mindful that any files that may have been associated with the class but are not part of the project could still exist on disk.) This method requires a bit of care but seems to work OK and is reasonably efficient. I did encounter some issues with my project, but I think they are related to other issues with the particular project file.

QUOTE(neB @ Jan 3 2008, 01:41 PM) Well, no, although that product sounds quite interesting. We had already invested in Telelogic TAU (http://www.telelogic.com/products/tau/index.cfm). An interestingly less expensive application I have found out about more recently is Enterprise Architect (http://www.sparxsystems.com.au/). Both have modules for SysML. Endevo makes a LabVIEW-oriented UML tool (http://www.endevo.se/index.php/en/Produkte...eller-1.2.html) that uses five of the UML diagrams and works with their GOOP classes. I recall they were talking about making it work with LVOOP classes but I don't know the current status on that. The NI LabVIEW Statechart Module and Endevo's offering both allow one to generate LabVIEW code automatically (and Endevo's tool can generate a model from existing code). (The others can generate code, but not in LabVIEW.) I use UML for modeling (more or less sketching) only and find that to be helpful, for example, when I am modeling a system with many states and want to make sure I understand all the transitions. Paul

QUOTE(neB @ Jan 3 2008, 12:07 PM) If you are interested in OPM you may be interested in UML and SysML.... I do use UML to help with my object-oriented LabVIEW software designs and I do find it helpful....

I reread some topics and thought about this more last night and I think I am getting my definition of controller confused. The main difference between the simple MVC test project I created and the actual project is that the commanded device is more complex in the actual project. It has multiple states, etc. In fact, what I had labeled model controllers use a similar structure to what I used in what I was calling the view controller, but these are not the "controller" of the MVC compound pattern. They are really part of the model itself. Actually, the whole lower part of the diagram is really part of the model. So I'm really not as far from the classic MVC as I thought. This is good because now it makes sense to use the strategy pattern to select the controller and the creation of the model, controller, and view have a logical place in the MVC model. (The model passes itself to the controller and the controller instantiates the view.) This seems all very good! I still decided to have the model communicate with the view indirectly (cf. the Cocoa or Passive View models already cited)--which was the topic of the post--for a few reasons. 1) It doesn't seem to be too much of a departure from the classic MVC model. 2) The ways I can think of to make the view change its appearance as a whole when a value updates don't make sense from the standpoint of a view. (These include writing logic in the view, writing logic in each view component, or triggering a value change event when an indicator updates programmatically--the last of which fortunately does not happen in LabVIEW.) 3) OK, and I haven't yet tested binding indicators across platforms, but that isn't likely to be a serious issue. (It should be possible with DataSocket.) Thanks, all!

Thanks very much, Jim and jdunham, for your helpful responses. OK, I drew a diagram to indicate what I did do. I like it in some ways but not in others.... I was kind of hoping learning the MVC pattern properly would shine a beacon on the enlightened way.... A couple notes: The signals in my solution are shared variables. I think my solution is similar to the Mediator pattern solution in some respects but I have divided the work into several controllers rather than one. Note that I have two models. I actually think this is a good idea.... The advantages I see: Each element/controller combination is completely independent of the other element/controllers in the subsystem and is swappable (e.g., we can use an alternate view). [The classic MVC pattern neatly swaps the view/controller pairs (they are a matched set) using the Strategy pattern.] Each element/controller combination can run on a separate machine. Disadvantages: I have this set up so that the subsystem starts each element, then runs each controller, then shuts down each element. This is OK but perhaps not as neat yet as in the classic MVC pattern, where the controller is constructed with the model and the controller creates the view, so that starting and stopping them together is a little simpler. Maybe I can come up with something similar for my implementation. Right now none of the elements knows the others exist. I will likely have to add in checks where needed at some point. Also, there are three controllers instead of one. [Counterpoint to these: I created a simple classic MVC in LabVIEW for a trivial test application just fine. I had to use VI Server to do the equivalent of Java's "createView" so that the view/UI would be nonblocking. This worked fine for the simple application. In my real application I would have to use VI Server also to run the input signal model as well if I wanted to incorporate it into the same controller, and this is a bit troubling and difficult in LabVIEW currently especially if one wants to initialize the class (to set input channels, for example) first. It doesn't seem to me that we should handle the two model parts in the same controller, but I may simply be wrong about this. Comments?] It is not exactly clear to me where the best place is to put the signal creation (I am creating shared variable libraries at runtime.) It is not clear that even in a SCADA system any of a subsystem's parts need to run on a separate machine. (Remote panels can work to export the view anyway.) More a technology disadvantage than a model disadvantage: Using networked shared variables or a similar publish subscribe system means that even if all the subsystem components are on the same computer they rely on the local network to communicate. (I think this is true but I haven't checked this.) I looked at the Fowler-described patterns and am still evaluating them--it takes a while for this stuff to sink in my brain! I am wondering what the best search term to find a "motion control design pattern" (or similar pattern) is. (I tried that but haven't found much helpful yet.... I expect there is a commonly applied pattern for this somewhere....) Paul

I guess an alternative I am describing is really a version of the Mediator pattern (which I guess sometimes is seen as a variation of MVC): See Fig. 4 here: http://java.sun.com/developer/technicalArticles/javase/mvc/ and Fig. 4-5 here: http://developer.apple.com/documentation/C..._section_4.html (Also see Head First Design Patterns pp. 559 and 622-3 for a discussion of the mediator pattern.) I'm trying to figure out which is the best solution....