ned

If you turn on execution highlighting, you can see what happens here. You have an item selected in the tree control, based on typing in the combobox. Then, you click on a different item in the tree. That click enqueues two events: 1) a value change event for the combobox, and 2) a value change event for the tree. They execute in that order. The value change event for the combobox sets the selected tree item to the item that corresponds to the combobox value. Then, the tree control value change event is executed. The NewVal is the value of the tree when the event occurred (when you clicked on the tree), but the terminal value is the value set through the property node in the combobox value changed event.

In case you want it, here's that VB code translated into LabVIEW (2012) so you don't need a separate DLL: EmailFromUserName.vi

If your multiple LabVIEW projects are all within the same Perforce workspace, then I don't think it matters which project you point it at (at least, that's been my experience). There is one global source control configuration, so if you are working across multiple workspaces or projects, you might need to reconfigure the source control system each time (although I've never been able to determine why it binds to a specific project). Personally I prefer using the Perforce Command Line option. I've never found an advantage to the project-based configuration, and it used to be that doing a diff didn't work properly in the project-based configuration, although maybe that's been fixed.

No, he wants the Scan from String to fail because the string contains a non-numeric character.

According to NI's terminology (http://www.ni.com/white-paper/3159/en/), you have implicit and explicit backwards. An implicit property node is one where the reference is not explicitly wired in. You do not need to close references to controls and indicators, although there's no harm in doing so. You can search the NI forums for more details, but the short version is, a front-panel control or indicator is a static object. All references to a single front-panel item have the same value, and you can't invalidate such a reference (the reference stays valid even if you close it because the front-panel items still exists), so closing such a reference is a no-op. You DO need to close references to objects that are created dynamically (.NET and ActiveX objects, for example). Sorry I don't have an answer on your actual question about whether there's a performance difference.

For multiuser access to an RT system such as a cRIO, I've used straight TCP (no shared variables or network streams). This isn't that much extra work, and gives you full control over the communications. There are lots of possible architectures; here's a brief description of one that I've used. The communication is handled in three separate loops. The first loop, the simplest, just waits on a listener for new connections. When one arrives, it puts that new connection into a queue, and goes back to waiting. The second loop handles all the incoming data. It continually loops through all open connections, checking if there's data (a command) on any of them. If there is, it packages that data into a message and puts it into a queue for the main program logic to handle. That message also includes a reference to the TCP connection that sent the command. This loop also dequeues new incoming connections from the first loop, and adds them to the array of active connections. If a connection is closed or inactive for a specified period of time, it removes that connection from the array. The third loop sends data back to clients. It pulls command responses off a queue, and directs them to the appropriate TCP connection (because the response includes the TCP connection reference that was packaged with the command).

What is the problem? Also, if you're on Windows and you don't want to use VISA, you have other options, for example the SerialPort class from System.IO.Ports in the .NET system library.

One right way to do this is to allocate a pointer to a memory block (using DSNewPtr), pass that to the DLL, and then inside the loop call MoveBlock to copy the current data to a wire. That way no changes to the DLL are necessary, unlike SDietrich's suggestion.

A wire branch NEVER creates a copy. Copies occur only at nodes. This is apparent when you use the "Show Buffer Allocation" tool. Each function determines whether it needs to modify the value on a wire. If it does, and if it can't get exclusive access to that value, then it makes itself a local copy. If, however, the value on the incoming wire isn't needed anywhere else, then the function can do its work in-place instead of making a copy. I'm going to use the term "reader" and "writer" here to refer to functions that read a value off a wire, and that modify a value on a wire, although I'm sure those aren't the official NI terms. If you branch a wire to multiple readers, no copy should occur. If you branch to several readers and one writer, the compiler will usually arrange to do the reads first, then the writer, so no copy needs to occur. If you branch such that you need to modify the value and also keep a copy of the original value, or branch to multiple writers, then of course copies are made. In your example, I wouldn't expect the VI to make an additional copy even though there are two outputs - unless the front panel is loaded, in which case it may make copies for display.

I'm guessing you have a different decimal separator than what the VI expects, for example you're using a '.' in your file but your operating system is set to use the European ','

It looks like there are some structural issues with your code. You should not be using so many global variables nor sequence structures. Indexing a single element out of an array is a fast operation, so I doubt that's actually the problem. More likely, when you replace the index array with constants, those constants propagate further down the chain and allow LabVIEW to do some optimizations. For example, the cluster feeding CommandGraph becomes a constant, and the compiler may be smart enough to notice this. It shouldn't affect the speed at all, but you don't need separate Index Array functions, you can expand the function down to index additional elements. LabVIEW will automatically increment unwired indices (although I'm not sure exactly how that works with 2-D arrays, you may want to test). I recommend that you eliminate nearly all of your global variables, use wires to pass data between functions, and remove the unnecessary sequence structures. If your code is still problematic and you're allowed to post it, share it here (zip up the whole project with VIs) and we'll try to provide pointers.

Maybe you could clarify your question. You wrote that you can't read the values in the Processing Loop. I don't even see the PV: Kinect Data variable anywhere in the processing loop. As I mentioned, you only read the MV variable once. When you put a probe on these wires, is the problem that no data ever arrives at the probe, or that you see a value but it doesn't update, or something else? Also, this question has absolutely nothing to do with the original thread since it isn't at all specific to the FPGA PID function; you might want to start a new thread elsewhere.

You only read from the MV variable once, before the bottom loop starts, is that the problem? Maybe you want to read it inside the loop?

One place I've used named queues is the rare situation where you want two top-level VIs to access the same queue. For example, I once had an application that relied heavily on queues, and I wanted to do some debugging on the items that were getting put into the queue without making major changes to the main code. I simply named the queue in the main VI, then created a separate VI that obtained a reference to that same queue and ran "Get Queue Status" repeatedly so I could constantly see the contents of the queue.

How is the call library node configured in LabVIEW when you call this function? What are the inputs to it? Make sure all arrays (ASize and APoints here) are preallocated to the correct length in LabVIEW before passing them to the DLL.

Cross-post: http://forums.ni.com/t5/LabVIEW/understanding-FPGA-DID-VI/m-p/3078442

Unfortunately I think you're out of luck. This is the expected behavior - LabVIEW's TCP Write hands the data off to the operating system, and then is done with it. Depending on the network configuration, it could potentially take a very long time for the data to be delivered, and you wouldn't want your LabVIEW code blocked that whole time. There are probably situations in which you could unplug the network cable, then plug it back in again and have the data sent successfully. I haven't experimented with this but the operating system may not close all connections the moment that the network cable is disconnected - there could be some delay in case the network is restored quickly. You could try adding a TCP Read for 0 bytes immediately after the write, but I don't know if it will reliably detect if the connection is broken.

It's not quite right, but what's coming to mind is "Elevator" and "Escalator" - one transports a fixed number of items between levels at a time, the other transports items continuously. Maybe keep "Pipe," and replace "Buffer" with "Bucket" or "Bin"?

Can't help you with this one. I don't think anything changed in LabVIEW 2014, but I'm still on an older version. Can you get to the representation for a numeric constant that isn't in an array? The process is identical for a numeric inside an array. What happens when you right-click the numeric inside the array? Do you get a shortcut menu? It would make it much easier to help if you save your data to a string control, as I explained in a previous post, and you post that VI. That would make it possible for us to see exactly what you're doing. Again, I'm still on LabVIEW 2012, so you'd need to save the VI for that version in order for me to look at it. The VI needs to contain a string control containing the actual data saved as the default value (this step is critical), wired to "unflatten from string" used exactly as you have it in your VI.

Right-click the Numeric constant inside the array constant (which is wire to the Type input), choose Representation -> SGL (Single-Precision). You could also wire a numeric constant without the array, since your code sends only one value at a time. When you typed "0.00f" it gave you a double-precision value, which requires 8 bytes. Since you're sending single-precision values (4 bytes) one at a time, there weren't enough bytes to convert to a double-precision floating point, so it gave you the error 74.

The easiest way to do this is with the Timeout event in an event structure. The event structure handles the Cancel button (and whatever other buttons), and you set the Timeout for 30 seconds (30,000 msec).

The same type of the data you're sending. I would use an array of single-precision float. Given that you send each value individually you may get a bunch of single-element arrays (I don't know if LabVIEW will combine multiple packets into a single read). Make sure the Unflatten input that specifies that the string contains the array size is FALSE (the string does NOT include the array size). You might want to modify your C# code temporarily to send a known value, which will make it easier to debug. You might also want to restructure the C# code to send multiple values in a single UDP Send, to cut down on overhead versus real data.

I think that if you're sending floats, then that's the data type you should be unflattening, too. Instead you're unflattening to 16-bit integers, which, unsurprisingly, explains why all the values you see are integers. Change the numeric representation to single-precision (I believe that corresponds to a float in C#) and see if it fixes the problem. The strange strings you see when looking at the UDP data are to be expected as well - you're looking at binary data as ASCII. If you change the string representation to hex you'll see the hex representation of the binary data, which might be more useful. Either way it's the same bytes, just displayed differently.

It would be more helpful to work with your real data. What is the format of the data you're receiving? If you're receiving the same text that your C# code from the other thread would otherwise be writing to the console, then your problem isn't endianness at all - it's that you need to parse the string into values. On the other hand, if you're sending binary data, then you should be able to unflatten it. The image you posted shows you're trying to receive an array of 16-bit values. Is that actually what you're sending? It might be helpful to capture some of the strings received by UDP Read in an indicator, stop the VI, change to a control, and set the current value as the default value. Then you can upload that VI, and I (and other forum users) can see the real data you receive.

The easiest way to do this is usually "Unflatten From String" with the endianness input wired as desired. In order for this to work it needs to be possible to unflatten your data directly into a LabVIEW data type (which could be a cluster).