PaulL

QUOTE (jdunham @ May 6 2009, 11:19 PM)

It's my opinion that UML doesn't add much to LabVIEW development, but maybe I haven't given it a fair shake. While I realize LabVIEW and UML have different purposes, I feel I can design well enough in LabVIEW that I don't need to waste engineering resources (i.e. my time) on a second set of graphical program expressions.

I have found UML is quite helpful when we use it appropriately. In particular, it is much quicker to make changes in a model ahead of time than to make changes in the code. Also, we have a good description of what we are trying to do that nonsoftware engineers can understand (although creating the models effectively and efficiently does require considerable practice) and review. Finally, UML is a great way to capture data structures for interfaces. (Especially for object-oriented systems I haven't found any other reasonable way to do this.)

This doesn't mean one should model every tiny piece of software, let alone in final detail. (We don't autogenerate LabVIEW code, for instance.) We do have to know when creating a model is useful and when it is more efficient to write code directly. I find the models quite often worth the effort, especially now that I can create them quickly.

Hmm... lots of good engineering process books. I think a good quick overview covering the principles is Head First Software Development.

We use Subversion here with TortoiseSVN and these tools have been even more helpful than I expected. I'm also a huge fan of Enterprise Architect (Enterprise Architect) as a modeling tool--and it can do a whole lot more. EA isn't free but it's inexpensive and I've found it to be orders of magnitude better than tools that cost ten times as much. It is immensely usable and well-designed. It works well with Subversion, too. We have also found JIRA (JIRA) to be an exceptionally useful issue tracking tool. (I wish JIRA had another layer of hierarchy but its advantages far outweigh this inconvenience.)

Paul

Shane's suggestion to use the composite relationship is a good one.

You could make DP & For a class that is part of the KKD class (or even make it separate, but let's keep it contained inside KKD for now). As far as I can see there is really no reason for DP & For to be a child of KKD anyway. Then KKD can just pass itself as an input (not for dynamic dispatching, but as a regular input on a separate terminal) to a DP & For method, and KKD's children can use the method, too.

If things get much more complicated you may want to take a look at the Strategy pattern.

Paul

Well, there is a thread on that error here:

How to Fix Error

QUOTE (normandinf @ Apr 24 2009, 08:54 PM)

There's an http://forums.lavag.org/LVClass-API-file152.html' target="_blank">API that you might want to look at.

Very nice API for some of our purposes! Thanks for alerting me to this.

QUOTE (normandinf @ Apr 25 2009, 09:11 AM)

You're right... It's not available in the RT engine. (I don't usually think in those terms)

Just for the record:

The context help window for "Property: VI Reference" states: "Available in the LabVIEW Run-Time Engine: No."

The detailed help has the following, however: "Note The LabVIEW Datalogging and Supervisory Control Module supports this property in the Run-Time Engine." I'm guessing this only applies to shared variable library elements? In any case, since we are using the DSC Module, I gave it a try. The application returned Error 1055: "Property Node in LVObjectParser.lvclass:determineClusterTypeString.vi->flattenObjectToStringThenVariant3.vi."

QUOTE (Jim Kring @ Apr 24 2009, 03:23 PM)

Great. BTW, how are you getting the Type Descriptor of the LVClass private data? I didn't notice the private data type descriptor in the flat data or type descriptor of the object data or type descriptor and I couldn't find any utility VIs (in vi.lib, for example) to do this either.

-Jim

Please see the attached image.

Paul

QUOTE (Jim Kring @ Apr 23 2009, 06:23 PM)

If you can get the Type Descriptor of the lvclass private data, there's an OpenG VI for returning the default data as a variant.

Ah! Thanks, Jim! The "Flattened String To Variant" (with a "type string" = Type Descriptor input) function appears to be what I needed.

Paul

OK, I've parsed a LabVIEW object from a binary string (see thread here: Flattened LVOOP Class). Is there a way I can programmatically retrieve the cluster to use as a type (not just the type descriptor as a string) so that I can create a cluster with the object data?

(This may not be necessary for what I am doing but I want to know if there is a way to do it. I haven't found a way.)

You could also serialize the cluster using XML (JKI's EasyXML does serialize clusters well), which might make deserialization on the C++ side more straightforward. This is supposedly a common application of XML.

OK, I replaced the center section with code that automatically updates the cluster elements before writing to XML. (Sorry for the wide picture. I purposely kept all the code at the top level so that reviewers could see the whole picture.)

To do this I made the assumption that the accessor methods are automatically generated by LabVIEW, which is not necessarily true. I'm hoping there is a better way.

The good news is that this method does what I intended it to do.

The next thing is to determine if a cluster element is a LabVIEW object or not....

I am attaching an image of the code to illustrate what I am trying.

Executing the code results in the following XML output [just for the relatively uninteresting TCSState object, which is just one component of TCSPublicStatus, and which has only one member, tcsState (an ENUM)]:

<TCSState.lvclass>

<tcsState>READY</tcsState>

</TCSState.lvclass>

Unfortunately this isn't quite general, since I don't have a reliable way to get the current object data and put it into the cluster. Maybe there is a way to do this?

If so, then I have to add code to check if a given element is a LabVIEW object or not, as I said. I just wanted to see if I could create meaningful XML data for an object at all. (The answer is right now a very qualified yes.)

Paul

OK, so I spent some time talking with our Java developer after trying a couple things, and here is what I am thinking (which could be wrong!):

1) We are not seeking a the transport mechanism. We already have a transport mechanism to send and receive data (in this case strings that will be XML strings). We are only interested in writing data to and reading data from XML.

2) Our XML strings are all strictly data. They are not fundamentally procedure calls (although in practice the distinction may be mostly philosophical--I'm not sure about that).

3) The basic format we need is element name with a nested element with the value. So JKI's EasyXML tool is a good example of what will work for us. In fact, I would stop here if that excellent tool supported LabVIEW objects (but it doesn't yet).

4) So that leaves us with the task of writing a framework to traverse the object data. Now each class, of course, has a control (in a .ctl file) associated with it, and that control is always a cluster. I can cast that control to a cluster and use EasyXML to turn it into XML, with a notable difficulty. (See the next item.)

5) OK, I have to handle the case in which the object itself contains other objects. In that case I have to determine if a contained element is a LabVIEW object or not. If it is, I have to determine the object type and then get the appropriate class's .ctl file (I haven't quite worked this out here), keeping in mind that it could be an abstract class.

6) The class .ctls ought to provide the appropriate clusters (barring the question of how to handle sub-objects again) that we should use to hand to the XML. I think it should be possible to write a framework to traverse the object data without writing code within each class to generate XML specifically for that class. (This is along the lines of some of the frameworks available in the Java world.)

So I think the problem in step 5 will make or break us. I'm going to see what I can do! (OK, I've only concentrated in getting data from LabVIEW to Java. I still have to be sure we can do the opposite.)

Paul

Mark,

Thanks for the hint! I am looking at the XML-RPC information now and will see if that suits our needs.

Everyone,

For the record, here is a link to the CR page: XML-RPC Server for LabVIEW and a discussion thread XML-RPC Implementation in LabVIEW.

Paul

AQ,

OK. Well, thanks for the heads-up. I thought the Java code could just ignore the version numbers but if (and I just ran a test to see this in action) LabVIEW doesn't put any values in the XML if they are default for the object (maybe I'm not stating this exactly correctly) that definitely is a problem for handing over to Java. Thanks for the heads-up.

Creating a cluster manually (by which I mean the cluster definition is determined before compiling), of course, possible, but I think it kind of defeats the purpose and it will be quite difficult to set up the hierarchy correctly.

So I will see if I can generate a cluster (based on the object data) programmatically (by iteratively traversing the hierarchy). I think this will be possible but I suspect there are a couple aspects of this that are nontrivial....

Paul

Alex,

I looked at a few web pages on XSLT and this solution looks quite promising (and is an incarnation of what I was looking for). We'll have to investigate further and see if works for us. Thanks much!

Paul

The solution to this may go beyond LabVIEW, but I expect this will be of general interest to many LabVIEW developers in any case.

Background:

1) As of LabVIEW 8.6 the "Flatten To XML" and "Unflatten From XML" functions support LabVIEW objects. We can use the "Flatten To XML" function to serialize LabVIEW objects to strings, send the strings over a network using, for example, a string shared variable, and then recast to the original object on the receiving computer using the "Unflatten From XML" function. (Note that the class definitions must be available to both the sending and receiving application, but this is not difficult.)

2) There are various methods to send string messages between Java and LabVIEW applications.

3) XML is well-suited to sharing data between development environments.

Problem: We have a LabVIEW object in our LabVIEW application. We use "Flatten To XML" to serialize the object to XML and send the resulting XML string to Java. Now we want to convert the XML string to a Java class. What is the best way to do this? (Of course we next will want to go the other way.)

Considerations: I kind of understand the key words (DOM, Xerces) but I don't know quite enough about XML in Java to know which direction to take. I do know that we will have to translate LabVIEW types into Java types.

Does anyone have experience with XML and would be able to point us in a good direction?

QUOTE (SaNoSuke @ Mar 24 2009, 09:43 AM)

Hi,

I'm a new user in LabView and doing a project, i would like to know how can i read from two dimensional array in excel sheet (or table) into labview?

means i can specify the column and the row from t he labview then read the value from excel ( or sometimes more than one value a time)

Regards,

M.B

The "Read From Spreadsheet File.vi" on the File I/O palette should get you there.

QUOTE (cbolin @ Mar 17 2009, 11:10 AM)

We've got a patch!

LabVIEW Development System 8.6.1f1 Patch

(http://joule.ni.com/nidu/cds/view/p/lang/en/id/1276)

Again, thanks for your patience!

Many thanks for your quick response!

Um, this seems to me to be an awfully serious bug. I installed 8.6.1 a week or two ago (it has some fixes I was eagerly awaiting) but I think I will have to revert to 8.6 if NI does not release a fix for this. I'm trying to push NI to do something immediately about this one....

This thread New Software Engineering and LabVIEW Wiki links to pages that have detailed instructions on how to set up TortoiseSVN to use lvdiff.

Paul

QUOTE (normandinf @ Jan 30 2009, 11:06 AM)

You do have a typedef with LVOOP, they're just embedded in the lvclass library and created for you automatically.

Yes, I'm pretty certain that's true, but at the API level I don't see it, or worse, need to maintain it directly. (Also, no one else can edit it except through the class design interface.)

LVOOP objects also take up only so much room on the front panels and block diagrams, too. Unless one uses tricks large typedefs take up a lot of space.

Antoine,

Well, to address the need in a different fashion you can use LabVIEW classes (LVOOP) instead of typedefs. You can protect LabVIEW classes with a password. In fact, on platforms where LVOOP is available I never create typedefs any more.

Paul

Hmm... Well, you might consider the new "Web Services" in LabVIEW 8.6 (Web Services in LabVIEW), then, but this is not really a LabVIEW to LabVIEW solution so much as a generic web solution.

Paul

OK, so you need a method of communicating between VIs, and presumably between two LabVIEW executable applications. (From what you told me the latter may not actually be necessary--you might be able to make the UI part of your application and just bring it up on demand. Would that be OK for your application?) In any case, separating your UI from the control is good design.

Well, networked shared variables are one way to do this (and would be the option I would most likely choose) in either case. See SVs and Executables, for example. Even with two built applications other options are possible, such as DataSocket (GVs and Executables). Don't use queues in that case (Queues and Executables). You might also find the following item interesting (VIServer and Executables).

Paul