TomOrr0W

Does anyone have a method for preventing a class from being inherited by other classes in LVOOP? This question came up while researching Object-Oriented API Design guidelines, one I came across in text-based languages was "Design and Document for Inheritance or Else Prohibit it" (see Slide 26 of http://lcsd05.cs.tam...des/keynote.pdf; there is also a video of the presentation on YouTube). In the case of classes that are reused within a team or publicly distributed, the issues discussed there with changing implementation details in the class being distributed potentially breaking children seems to still be valid in LabVIEW.

Note that this vi will use about 100% of cpu time (it will also interfere with timing of other code if you only have one core) on one of your cores due to the lack of a wait function. Adding wait (ms) with an input of 0 ms inside the body of the loop will still use 100% of cpu time, but it will not interfere with other code as much. A 10 ms wait drops that to be close to 0% (assuming you can tolerate being up to 10 ms late).

The only reason I can think of to use that at the moment is if you want to make a VI that has a progress bar be more consistent with other Windows 7 dialogs (a minor usability feature).

If your application does end up communicating with CAN devices, note that NI's USB-8473 devices do not support NI-CAN's Channel API (you would need to use the Frame API or the Frame to Channel Conversion method, which are both somewhat more complicated -- See the LabVIEW help for NI-CAN).

I think you are not getting overflow errors because the operating system drops packets silently once the buffer is full. I have no idea why you are getting partial packets - the documentation seems to imply that LabVIEW only reads complete packets (I may be wrong on this). I think asbo's solution is probably the best approach to take with the issue of not reading fast enough.

I looked at the documentation for the UDP read VI, and I believe you are getting error 113 and no data on that first read because the one byte you attempt to read is part of a larger packet. From the documentation of the Max Size control of that VI: max size is the maximum number of bytes to read. The default is 548. (Windows) If you wire a value other than 548 to this input, Windows might return an error because the function cannot read fewer bytes than are in a packet.

So that you don't get confused the next time you use "Array to Cluster" and attempt to probe its output, the issue you were having earlier was just due to the way LabVIEW names the output of "Array to Cluster". LabVIEW takes the name of the input wire and appends [0], [1], [2], etc to it to name each item in the cluster. It also gives the cluster itself that name. Therefore, in your first probe window: Array (1-D Array of Strings) -------Array to Cluster--------> Array (Cluster of: Array[0] (String), Array[1] (String), Array[2] (String), Array[3] (String) ...) And in your second probe window: "" (1-D Array of Strings) ----------Array to Cluster-----------> "" (Cluster of: ""[0] (String), ""[1] (String), ""[2] (String), ""[3] (String)) where "" is a placeholder for an empty string (the default name of a constant).

It is the default on my work computer -- a Lenovo T61 laptop with Windows 7.

By any chance are you refering to the following question (copied from the CLAD Sample Exam 1)? 3. Which of the following apply to Property Nodes? (More than one answer may apply.) a. Property Nodes allow attributes of front panel objects to be programmatically manipulated. b. Property Nodes can be used to update the values contained in a front panel object. c. More than one Property Node can be used for a single front panel object. d. Property Nodes contained in a SubVI will always cause the front panel to be loaded in memory. 3. Correct Answer: A, B, C, D Topic: Property Nodes Justification: All of the statements are true for Property Nodes. References: Property Node

Using To Variant does prevent the error (at least in LabVIEW 8.5). The following values are what ends up in the indicators in my first post: In Variant (showing type and data): 'Value': Variant <Variant : Empty> In data (showing type and data): '': void

I don't know if it is expected or not, but the same thing happens with variant to data (in LabVIEW 8.5, at least).

If you know that there will only be one PCIe-6320, you can modify your algorithm to search by Identification.Product Type rather than Identification.Device Serial Number. Also, there is a Location.PCI.Device Number Property (corresponding to the PCI slot number) that might (I haven't tried it) work on PCIe cards (If so, you could have the user select the appropriate PCIe-6320 from a list).

In LabVIEW 2009, I found that the wire that is coerced first's data name is written to all the indicators. I was able to reproduce the 2010 behavior in 2009:

Was that trivia competition this one: LabVIEW Trivia - 20 Years of History with this question: Which HTML tag element did the LabVIEW 8.0 Context Help window add support for when used in “VI description”? (Correct answer worth: 20 points) Answer: b (B was supported in earlier versions too)

I am working to programmatically add custom tags to VI Descriptions, and I would like to have a list of formatting tags so that I can ignore them when displaying all custom tags or deleting all custom tags. I know that <b> and <B> are valid formatting tags for VI Descriptions, but I can't find any reference to whether or not there are others (I am using LabVIEW 2009).