If you’ve developed systems that communicate over the network (for example, a remote RT system) you’ve probably run into this issue: Clients need to know the remote program’s IP address in order to connect to it.  If you have complete control over the local network, the simplest solution is to just set a static IP address on your system and call it a day.  Often times, especially in corporate environments, you don’t have this luxury.  Corporate IT is not always willing to set aside IP addresses specifically for your system.  When faced with this situation, you’ll have to keep your system in DHCP mode and it’s IP address won’t be known ahead of time.  This is where using UDP broadcast messages to make your systems “discoverable” can save the day.

The image below shows how this works.  The client that’s looking for the remote system sends out a UDP broadcast message containing it’s own IP address to all devices on the network.  Your remote system will be looking for this message, and when it sees it, it will respond directly to the client (since it now know’s the client’s IP address) with a direct UDP message containing it’s own IP address.  Once the client receives that response message, it will have the remote system’s IP and can now connect properly.  As a side effect, all of the other devices on the network will also receive the UDP broadcast message, but they will simply ignore it.

Here’s what this looks like in LabVIEW (Download Example Code):

Client:

Remote:

The remote system continuously listens for an incoming UDP packet.  Most of the time, it will timeout and return an error, but when it receives a packet it sends it’s IP address back to the client (in the “No Error” case).  The client simply sends out a broadcast message containing it’s IP address by sending out the packet to 255.255.255.255, and then listens for the response message containing the remote system’s IP address.

Making your remote systems discoverable using this technique can not only get around IT infrastructure constraints, it can also give your systems that “professional touch” that can make all the difference.  Thoughts or suggestions?  Please comment below to let me know what you think!

TCP is a great way to pass data back and forth between two networked systems.  Unfortunately, I’ve noticed that many LabVIEW developers neglect to take advantage of one of the most powerful features of TCP: That TCP servers can connect to multiple clients simultaneously.  In this example, I will show you how to accomplish this by creating a TCP Server VI which will asynchronously launch a “handler” VI each time it receives a connection.

Continue reading →

Generics are a powerful feature that advanced LabVIEW developers have been requesting for a long time.  If you don’t know what generics are, here is a description of the feature from Microsoft’s MSDN documentation:

[Generics] make it possible to design classes and methods that defer the specification of one or more types until the class or method is declared and instantiated by client code. For example, by using a generic type parameter T you can write a single class that other client code can use without incurring the cost or risk of runtime casts or boxing operations…

https://msdn.microsoft.com/en-us/library/512aeb7t.aspx

In other words, generics allow you to develop APIs that are data type agnostic.  The developer using your API gets to choose what type they wish to use with your functions.  If you haven’t dealt with generics before, this might sound a lot like LabVIEW variants, but there is an important difference between variants and generics.  Variants defer typing all the way to runtime, whereas generics require that the type be specified at compile time.  This means that the compiler can check whether or not the user of your API is being consistent with the data type they have chosen.

Continue reading →

If you’re like me, you probably call VIs asynchronously all the time.  Like me, you’ve probably also been doing it wrong for years.  If you’re doing it like this…

…stop doing that.  For some reason (which I assume is a bug deep in the guts of LabVIEW) when you use a strictly typed VI reference to call VIs asynchronously like this, LabVIEW fails to release the VI reference…sometimes.  It’s a terrible bug because 99% of the time it works just fine, but every once in a while all of your libraries will stay locked after your code is done executing and you’ll be scratching your head trying to figure out why.  Instead, do it like this:

Removing the strictly typed VI reference fixes the issue and LabVIEW always releases references correctly.  Interestingly, the Actor Framework made this exact mistake up until a recent version which removed the strictly typed VI reference, as shown here.  I suspect this is the reason why I’ve had many Actor Framework based projects inexplicably refuse to unlock libraries in the past.  A comment in the Actor Framework code suggests that the strictly typed VI reference was removed for an RT bug, but I’m certain the bug occurs on Windows as well.  Also, the Actor Framework still uses strictly typed VI references for “Time-Delayed Send Message.vi”, which is (anecdotally) where I’ve seen this issue show up most often.  Maybe there’s a good reason why the time delayed send message VI was left this way, but I don’t know what that reason might be.  If Stephen Mercer or anyone else can explain this (and happen to be reading this blog post) please comment below!

HTTP Server Example Code

The computing world is getting more and more connected every day.  With this in mind, it is important to understand the technologies used to create these connections.  Although there have been many different technologies that have played a role in the internet revolution, by far the most prevalent one is HTTP.  HTTP is the backbone of the web and is the primary protocol used to transfer information over the internet.  In this article, I’ll walk you through the absolute bare minimum LabVIEW code needed to receive and respond to an HTTP request.

Ok, disclaimer time. This is a blog post, and the code provided here is meant for demonstration and discussion purposes only. This code is by no means compliant with the six HTTP 1.1 specifications (RFC7230 – RFC7235) which total over 200 pages. This code is meant to be educational and to help you to understand how HTTP works, not to be used for real applications. If you use this as a production server, you will have a bad time. Seriously, don’t do it.

Now that that’s out of the way, let’s talk a bit about what a web server actually does.  In general, a web server listens for TCP connections, and when it finds one it reads the message, parses it, sends back the appropriate response, and finally, closes the connection.  That sounds simple enough, but how does the server know what kind of messages it will be receiving?  The client and server must agree on the formatting of the messages in order for them to be speaking the same language.  This is where HTTP comes in.  The HTTP specification describes the semantics of this language in incredible detail.  In this example, however, we will see that with a very small amount of code, you can implement a subset of the specification that is enough for our server to be able to communicate with a web browser.

Continue reading →

…that is the question.  Anyone who has used PPLs in LabVIEW has faced this dilemma at some point.  PPLs have a lot of potential benefits. Your application is split up into nicely compiled modules that you can rebuild individually without having to rebuild the whole application.  You can dynamically load them at runtime and create plug-in architectures.  Rebuilding your top-level executable is a breeze because most of your code is already compiled.  Sounds pretty great, huh?  Well unfortunately, there’s some down sides too.  Managing PPL dependencies is difficult at best and at worst, literally impossible.  When PPLs depend on other PPLs you have to start worrying about how the LabVIEW linker finds those dependencies (which, in my experience, is completely inconsistent).  The order in which you build the PPLs matters, so you have to be careful to build the low level PPLs before you build the higher level ones that call those PPLs.  And all of this is still just dealing with statically linked PPLs.  Dynamically loading PPLs introduces a whole new set of problems.  Again, you must load the dependency PPLs first, as LabVIEW is not smart enough to load them for you.  Also, loading PPLs from disk is extremely slow, so performance can become a real issue.

Continue reading →

Download Demo Code

Here’s a quick tip that I’ve found useful in the past when displaying images on the front panel at runtime.  The built in 2D Picture control is quick and easy to use for this purpose, but if you want to do anything more complex than simply displaying an image, you’ll likely find that a better solution exists.  The primary issue I’ve run into involves displaying images that are a different resolution from the 2D Picture control itself.  The 2D Picture control makes no attempts to handle this situation, it just simply displays the image pixel for pixel.  This means if the image is too big, it will get cut off, and if it is too small, it will leave whitespace.

Continue reading →