Jump to content

PaulL

Members
  • Posts

    544
  • Joined

  • Last visited

  • Days Won

    17

Everything posted by PaulL

  1. QUOTE (normandinf @ Apr 24 2009, 08:54 PM) Very nice API for some of our purposes! Thanks for alerting me to this.
  2. QUOTE (normandinf @ Apr 25 2009, 09:11 AM) 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."
  3. QUOTE (Jim Kring @ Apr 24 2009, 03:23 PM) Please see the attached image. Paul
  4. QUOTE (Jim Kring @ Apr 23 2009, 06:23 PM) Ah! Thanks, Jim! The "Flattened String To Variant" (with a "type string" = Type Descriptor input) function appears to be what I needed. Paul
  5. 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.)
  6. 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.
  7. 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....
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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?
  14. QUOTE (SaNoSuke @ Mar 24 2009, 09:43 AM) The "Read From Spreadsheet File.vi" on the File I/O palette should get you there.
  15. QUOTE (cbolin @ Mar 17 2009, 11:10 AM) Many thanks for your quick response!
  16. 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....
  17. 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
  18. QUOTE (normandinf @ Jan 30 2009, 11:06 AM) 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.
  19. 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
  20. 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
  21. 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
  22. 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?
  23. 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
  24. 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.
×
×
  • Create New...

Important Information

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