Leaderboard

In most languages the Booleans are stored as bytes. Memory is cheap. Also, to store a single Boolean on any modern computer, it will always use a byte. It is the smallest addressable piece of data on any computer. Even for arrays it would not pay to pack the Booleans into bits. As I said, memory is cheap, and having to do arithmetic to read a single Boolean value is a bigger waste of resource than memory space is... In the end, you usually want it simple and fast. Br, Mike

Thanks to Ram Kudukoli (of NI R&D) for sharing this with us at the recent CLA Summit: If Façade is not executing fast enough to keep up with data updates, it causes the updates to queue up. The updates will happen even after the VI stops running. To reduce data updates: - Open the Xcontrol .xctl file in a text editor like Notepad. - Add the bolded line shown below: <Property Name="NI.Lib.Version" Type="Str">1.0.0.0</Property> <Property Name="NI.XClass.Flags" Type="Int">0</Property> <Property Name="NI.XCtl.OptimizeDataUpdate" Type="Bool">true</Property> <Property Name="NI.XItem.DeclaredLeakProof" Type="Bool">false</Property> - Save the .xctl file.

Under windows, the default udp datagram size is 1500 bytes (i.e the default MTU). The maximum it can be is 65535 bytes (you can set it to more than this, but it will still be limited to 65k ). This is because the UDP header field is a U16 and cannot represent more than 65k. UDP, User Datagram Protocol

It's incorrect to say that UDP is a "faster" protocol. It is more lightweight than TCP, but that doesn't inherently make it faster - especially in the use case you have, where you'll basically need to handle everything that TCP does automatically (and at a lower level). Speeds far in excess of 2Mbps are feasible using TCP, so you probably need to take a look at your implementation and maybe talk to your teacher about what you can do to optimize it.

Sorry I didn't realize this is a homework assignment. In that case, you can learn about TFTP and implement your own solution by reading RFC 783 and RFC 1350. This will also give you an understanding of what chunks are. Good Luck! ~Dan

Hi Alex, when programming LabVIEW FPGA the output is VHDL code which is compiled and optimized by the Xilinx compiler. So you cannot transfer LabVIEW memory management to FPGA. And because of that I don't think that there is any waste of memory wrt. FPGA programming.

The IEEE9001 standard requires "shall" statements to be met, and shown to be met - never violated. You just failed an audit, my friend! That's a great way to look at it - and we look at BD size, and many other metrics, with that in mind. For example, we try not to say that a VI with a high GOB count is bad - it's just a flag that it should be reviewed. There are several edge cases where high GOB count VIs make perfect sense, and the same goes for large BD VIs. Then you're doing it wrong. Maybe by CLADs, but not where I work. I often get berrated for using too much abstraction and too many subVIs. I like to think the berrators just don't understand my brilliance. Seriously though, subVIs are great, and, just like everything else, should be used when appropriate. Just to get a little BD space is not one of them IMHO - using them in that way is obsfucation - which may be appropriate, but you need to be mindful that you're doing it.

One of these days (I have said this before) I will dust off my XNode Wizard. It automates a basic set of common tasks and makes it easy to create a certain class of XNodes: Growable nodes, dropping template code and mapping the terminals from the template to the XNode, and drawing the image. My own experience is that with the limited set of features I have managed to reverse engineer, they are stable, yet you can still write a broad spectrum of useful nodes, especially since a vast majority of the time you want a subVI with something resembling the type adaptation of primitives without writing hundreds of polymorphic instances. The fact that XNodes ship with LV (ie. Match Regular expression) means that stable objects can be created. Express VIs are using very similar if not the exact same framework. I can corrupt a VI with scripting, with Write to File, or even setting the current values to default. And just because I can wreak havoc with my reciprocating saw does not change the fact it is my favorite tool in my garage. With great power comes great responsibility. I do wish that someday I could package XNodes in Packed Project Libraries, they are made for each other. A single package containing one useful top-level object and a bunch of specialized subVIs that are best kept private. In the meantime, besides the existing resources on LAVA I would check out the following: http://forums.ni.com...ode/m-p/1293680 (a cool, simple XNode example. Shows handling clicks, type adaptation, and updating the image) https://decibel.ni.c.../docs/DOC-15362 (a bit of a play, shows a few more abilities and techniques) Attachment: This is a picture constant which allows drag and drop of common image types (JPEG, PNG). You can place this constant on the BD and then drag and drop an image file to get a constant picture. When you are finished, you can right-click and replace the XNode with a simple picture constant (this avoids the need to distribute the XNode with your VI). I like it as a quick way to get a picture constant without the usual method of read file, draw to picture indicator, create constant, copy, paste. Simply extract the folder and drag the .xnode file to your BD. XNodes can be added to your palettes, just remember to choose the 'All Files' filter when browsing for the .xnode file. enjoy! PictureConstant.zip

I think the most underutilized feature in LabVIEW is the SubVI. Use more subVIs people! Sheesh.