TomOrr0W

Hi prabha

Loop time1 is the one i'm looking for.

many thanks.

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).

This discussion reminds me of an another Windows API I have yet to use but have wanted to. I saw that there is an API for controlling the progress of an application, through the taskbar (not sure if there is a name for it).

http://sine.ni.com/n...g/en/nid/210184

Very neat stuff, but like I said I haven't found a good place to use it yet.

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.

Thank you all for those. I'll be looking into them. Meanwhile, please help me to understand my problem because it still perplexes me. Here is a screenshot of three windows overlaying eachother. At bottom, showing through, is a tiny part of the main VI. You can see where I've put two probes, before and after my problematic cluster_to_array VI. At bottom is the probe results, showing (to my interpretation) a simple array of strings as input and the anomalous cluster of single-string arrays as output. At right is a window showing the contents of my custom VI from which the array-of-strings derives. What is going on here, please?

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.

You might see what happens if you do a variant constant wired to a To Variant wired to this invoke node. That would probably work. The invoke node probably wants to treat the incoming data as a variant wrapping the actual data type of the control. An empty variant does not wrap the variant data type, it wraps void.

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:

I swear that others were added in 8.2 (I remember it being a trivia competition question around that time) but I can't remember what was added...

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).