PaulL

I don't think you will encounter any issues using a subVI. Have you experienced any issues after deploying the application and monitoring the PC's memory usage?

Klompmans, Can you clarify the requirement for the application to run stand-alone? Is the requirement just to be able to run the code without the LabVIEW development environment (such that deploying built LabVIEW executables is fine) or that third party tools must be able to communicate with the LabVIEW code? Paul

We have been applying the convert-object-to-XML functionality quite successfully. This allows us to: 1) send LabVIEW objects over the network. (This requires that the class definitions are accessible in the applications on the communicating computers. One can accomplish this by putting the class definitions in a networked code repository, for example.) (Note that we can also use Flatten To String and Unflatten To String instead of XML just to send the object data. In either case no parser is necessary, just a type-cast! Quite clean and easy to maintain!) 2) have LabVIEW object data in a format (XML) such that we should be able to convert LabVIEW objects to and from objects in another development environment. (Note that we haven't implemented such an XML-based language converter yet, but I expect it should be fairly straightforward to do. Suggestions on this are most welcome!) Note that there is a minor bug in 8.6 such that Enums in LabVIEW classes sometimes result in errors with the XML conversions. I reported this to NI and I'm confident that NI will fix it promptly.

You might want to check out a wiki New-Software-Engineering-And-LabVIEW-Wiki topic I started. This already has information specific to setting up Subversion to work with LabVIEW. The TortoiseSVN manual itself is quite good.

The O/S timing resolution is certainly a problem for submillisecond timing. As far as not polling goes, I actually have done this using shared variable events. I execute a timer method in its own thread (and this in turn calls the Elapsed Time express VI), passing it the urls of shared variables (timeHasElapsed, timeTarget, stopTimer) for the particular timed process. I register for events on the timeHasElapsed shared variable to trigger responses in the application. I previously talked about this here: Newbie-needs-help-with-timer-control.

When autopopulating folders came out I experimented with them and found the same problem described by AQ. I promptly returned to using virtual folders and am glad I did, of course, for many other reasons as well. I still encounter some mild frustration with projects in 8.6 with respect to saving projects. For instance, with my current project (virtual folders only!) I can save everything, close it, then reopen it only to find an asterisk on the project and a prompt to save it again if I try to close it. Showing the changes only results in the unhelpful message, "An attribute of the project has changed." This has been only a minor annoyance, though, since so far saving the project a second time has resolved the problem. Clearly there is some work for NI to do here. I submitted a request to NI on this. Paul

QUOTE (Nate @ Dec 18 2008, 12:11 PM) All attributes in LVOOP classes are private. See http://zone.ni.com/devzone/cda/tut/p/id/3574' target="_blank">LabVIEW Object-Oriented Programming: The Decisions Behind the Design.

QUOTE (Thang Nguyen @ Nov 6 2008, 03:14 PM) The essence of the State Pattern is this: State Pattern Diagram. (The best reference is GoF Patterns Book, and another user-friendly guide is Head First Design Patterns.) I should write a good example I can post on this forum sometime, but in words: We have a Context, maybe a device, that has certain states. It responds to external signals according to the current state, and may change states as a result. Create a class for the Context. Then create a State class and then child classes representing the individual possible states. Each state inherits from the State class. (A hierarchy of states is possible so you can have superstates and inherit behavior.) Now set up a way to respond to external signals (e.g., an Event Structure). When an event occurs, call a corresponding method on State (e.g., turnOnDevice) that is implemented in the child classes (you can have default behavior in State). This is a dynamic call that depends on the which descendant of State is on the wire. The methods always output the state (same or different) for the next iteration. Hmm.... I can see an example would be helpful. Unfortunately, I can't make one today, but I should take some time to do this soon....

Hmm.... Well, I think in most cases the event structure is the way to go. I think it's worth learning to use it well before pursuing other approaches. Maybe it would be more beneficial for us to help you with your implementation of the event structure. I'm sure there are other opinions, though.

Michael, You might try something like adding the identifier as an input to the VI that accesses the network variables, perhaps even incorporating this into the SV data. That may be somewhat similar to what you are trying. In some implementations of the OOP Command Pattern, for instance, the Command object includes an object that identifies the intended recipient of the command as well as the command content itself.

Why would you not want to use the event structure?

For the record, you can also use the File...Print menu on the VI and print to an html report, which generates .png files.

Thang, In OOP terms I use and like the State Pattern, which works quite well. As far as timing my controller does what it does and just changes state in response to triggers. The controller is ready for a new command at pretty much any time, since the operations it takes directly in response to state changes can execute quite quickly. Paul

I don't know about TortoiseCVS, but I use TortoiseSVN. It has its own diff utility, but I associate my LabVIEW files with lvdiff to do graphical differencing.

Perhaps you will want to take a look at the (object-oriented) Observer pattern. There is an STM example that does pretty much the same thing. Networked shared variables also do this--now with a TCP layer.

QUOTE (tmunsell @ Oct 28 2008, 05:52 PM) What is happening is that the code is attempting to replace an array element (right after where the comment is "If I only had a DAQ"), but the replacement array element (from the section where the comment is "If I only had a DAQ") differs in type from the element it is replacing (and the array element type for that array). Specifically, the replacement element type is a cluster of two doubles, but the array element type is a cluster of two arrays of doubles. The simplest thing to do is to put each of the doubles in the array element into arrays. So insert a build array on each of the wires before the Bundle function in the "If I only had a DAQ" section.

QUOTE (Thang Nguyen @ Oct 28 2008, 10:58 AM) This is quite similar to what you can do with shared variables. I think what you are doing is fine, but as I've been reading this topic I keep asking myself, "Why not used shared variables?" There are pros (networked communication with logging and alarming built in) and cons (one of which is that one needs the DSC module for full functionality) but I think a mention of this solution belongs here.

For the record, it is also possible to simulate a press of the PrintScreen key in Windows with a call to the keybd_event in the user32.dll.

There are some IEEE templates that we use as a starting point, although these are pretty generic.... Paul

QUOTE (Aristos Queue @ Oct 5 2008, 11:53 AM) LVDiff is an open-source tool. This is the home page LVDiff page but download the library-compatible form here: LVDiff with VIs in library. Paul

QUOTE (normandinf @ Oct 3 2008, 02:54 PM) Norm, Your example helped immensely. I was able to get it to work with LVDiff and everything. I'll post the result in a few minutes here.... Paul OK, I just replaced the "Open VI Reference" in "lvdiff.vi" with "obtainReference.vi" that uses Norm's method to get a reference to the .ctl for the class if the type is LabVIEW class; otherwise, it uses "Open VI Reference" as before. I set up TortoiseSVN to use lvdiff as the "Diff Viewer" if the file extension is .lvclass. Everything seems to work great. Many thanks, Norm and AQ!!! Now we need to see if we can get LVDiff updated at its source..... Paul

Sorry about the delay in replying. I wanted to try something first.... AQ's post tells me: LabVIEW's comparison VI works with .ctls :-) I need to use the ClassName.lvclass:ClassName.ctl (project path) format to access the controls (that's hugely helpful!) Now, keeping in mind that I want to work with a SCC provider... 1) What I want to do is edit lvdiff.vi so that it will compare the .ctl files if the file extension is .lvclass. Unfortunately I haven't been able to get this to work. Lvdiff.vi uses "Open VI Reference" but this doesn't work with .lvclass files (returns Error 1059: LabVIEW: Unexpected file type). (And no, simply adding :ClassName.ctl doesn't work—then I end up with Error 7: File not found.) I know I have to use the project path as AQ describes but I don't know how to open the files—in LabVIEW--in the first place. I'd like to know how to do this anyway. Any hints? 2) This way I will have a solution to do a comparison from the TortoiseSVN client to Subversion. (I just have to specify to use the modified lvdiff tool as the DiffTool for .lvclass files.) NI does not currently support TortoiseSVN as an integrated source code control provider. The next question is: can LabVIEW compare .lvclass controls in this way using an integrated SCC provider? My guess (haven't tried this) is that it doesn't so NI still needs to develop this. Maybe this would be a compare two LabVIEW classes method. (Then maybe I could use this to update lvdiff.) TortoiseSVN's own textual comparison tool or Beyond Compare or CompareIt! will all show me the differences in the XML file, but the coded information isn't directly useful. What I really want to do is compare the .ctls as AQ's example does (works quite well, by the way). That's exactly what I want to do. I just want to use it with a SCC provider. Thanks! Paul Hmmm...maybe Norm's approach will help me with getting a reference to the .lvclass.... but can I open the class this way, I wonder?

Norm, Very nice. I think what you have here is the start of a VI (maybe "CMP Compare two LVClasses.vi") that belongs perhaps in the prochmphier.llb library. Then we could write a version of LVDiff to call it when the file type is .lvclass.... So nothing like this exists with LabVIEW currently, then? If not then I will submit an enhancement request to NI, since I think this should be part of LabVIEW itself in future releases. Paul

Exactly. See the attached file for an example. Paul

Does anyone know if it is possible to compare two versions of a class in a meaningful way? For example, say I create a class (Newclass.lvclass) and save it in a repository. Subsequently I make a change to the class (e.g., I add a Boolean control to the class data definition). Now I want to compare the current version to the previous version. A .lvclass file is a text file so using TortoiseSVN's default Diff Viewer shows the textual differences between the files, but even for the simple case of adding a Boolean control described above this is not human readable. I don't see a way to access the .ctls associated with the class for comparison either. Has anyone figured out a way to do this? Paul