“Fragile” code is code that breaks in one place because of changes you make in some other place. It’s most aggravating when you’re due to ship a new version tomorrow and you need to make one last tweak at 11:30 PM, or your client is looking over your shoulder and this little “harmless” change shows up as a smoldering heap during the demo.

In this case, “break” doesn’t ONLY mean “broken arrow” , or uncompilable code (at least you can chase those down easily enough). Here, “break” also means “operates incorrectly” or “completely wrecks itself like it never did before” or somewhere in between.

These sorts of breaks come from unrecognized dependencies, and they’re all too easy to make: the header size has been 3 for months and months now, so when you add a new function that needs it, it’s easy to stick in a constant 3 and be done with it.

DON’T DO IT.

If you’re an old-hand bit-banging cycle counter like me, it’s easy to think of saving a few cycles and adding up the bytes in this cluster, and using a constant of 53 when you need the size of it.

DON’T DO IT.

The problem is, or course, then when (not if, but when) these things change, then you will have to track down ALL the instances where you use this number and change them.  Not a good plan.  The compiler won’t complain – the code is still valid.  But reading thee bytes when you should be reading four will not get you where you want to go.

One tip to solving this is to reduce the number of places that you use such numbers. Focus such procedures into a single VI if you can. But the real key to solving this is to recognize these things when you originate them.

Example #1

Here we need to receive a packet header, consisting of a cluster of a U8 enum command and a U16 integer.  It’s easy enough to count up to three bytes, and it would be easy to plop down a 3 constant.  However, it is safer to use a constant of the header’s typedef and calculate its size in code.  This might go against your instincts (it does mine), but in fact the extra time taken (to flatten into string and get string length) is trivial (measure it yourself if you have doubts). On top of a TCP READ operation, this burden is truly insignificant.

And the benefit is that when the integer needs to become an U32 or the command must become a U16, here’s one less thing YOU have to worry about.  Since the constant here is a TYPEDEF, and since you’re calculating the size every time, then it will keep on working.

Example #2

This example is similar – sending a packet header plus a payload thru a connection. Even if your payload is always the same size, it’s better to calculate it than to use a constant.  With any luck at all, the STRING LENGTH operation will get the same answer every time. and if you do change it at some point, then this code won’t break.

Some development environments have a concept called “watching”, where you choose a variable to watch and you see a continuous display of that variable in some window.  This is very useful during debugging, as you can step through your program and find out where this variable is being changed.

LabVIEW has no such built-in feature, but it doesn’t really need one.  You can construct your own watch windows, have them run independently of your main code and accomplish the same thing.

Simply make a new VI with a WHILE loop and a STOP button.  Add a WAIT for 200 mSec (or something) inside it (so you don’t hog the CPU).  Each time thru the loop, grab your watch variable, process it, and display it.

The “processing” can be unbundling a single item from a complicated cluster, or picking an element out of an array, or anything you need to display the item in question.  Perhaps you need to call a VI to get it. Perhaps you need to query an I/O port, or a TCP instrument. Whatever you need to do to watch your troublesome variable.

SUGGESTION:  When you’re done with it, save it in a folder called “Miscellaneous Stuff” or something, so you can get at it easy next time.  There will be a next time.

A question came up on the LabVIEW forum the other day about multiple connections, and how hard it was to have two connections transmitting at two different rates.  This surprised me a bit, because I have been doing just that for quite a few years.  The allegation was made also that TCP requires a minimum packet size of 32 bytes. That is also a surprise since I have been doing things contrary to that “rule” for quite a few years.

So, in an attempt to clarify things above and beyond the Beginner’s Guide to TCP/IP, I present this example with a CLIENT and a SERVER.

The SERVER should be run first and listens for four connections on four consecutive ports. It has four data generators, running at different rates.  When data is available, it transmits it over the connection  if there is one, or listens for one if there’s not.

The SERVER uses a re-entrant VI so that the same code can be executing in four instances at one time.  The four instances are given four different intervals. The WAITs do not conflict because of this reentrancy.

The CLIENT initiates four connections to these same ports, and waits for data in four loops.  I did not use reentrant VIs here, because of the connection to the charts.  Although you could pass a reference to the chart to four reentrant subVIs, I chose not to, thinking that the speed would be better with the direct approach.

Given that this is based on the mSec Timer in LabVIEW, I wouldn’t vouch for it’s accuracy as you approach 1000 Hz. But the basic techniques are sound and will work beyond that frequency.

Click here for a downloadable example of four-channel client server communications.

Just in case you thought I was kidding in the article on en masse operations, I decided to offer some proof of the speed advantages they can give you.

I used the Timing Template vi to measure the time it takes to multiply an array of DBLs by two, both with a loop, and without.  I set up the timing VI to create an array of 1000 random numbers, and then time the multiply operation.

First, the loop method, where you auto-index every value out of the array, multiply it, and auto-index it back in:

As you can see, this took 7.47 uSec per loop.  Not all that shabby.  But just removing the loop lets the en masse operation do it:

Holy Speed Demon, Batman!  That’s 0.77 uSec or about ONE TENTH the time!

Now, I’m not guaranteeing that all such operations will save you that much time, but if you have a chance to use them, then you should!

It’s easier on you and easier on the hardware!

En masse is a French term meaning “as a whole” or “all together”; treating a group of something as a single unit.   LabVIEW has the ability to treat arrays this way, which can greatly reduce your workload. If you come to LabVIEW from a text-based language, it’s easy to miss the capabilities that are right at your fingertips.

For example, if you need to scale a series of readings into percent of the total (a procedure called normalizing),  then you tend to think:

I need to find the total:

• I need to start with a zero sum     sum = 0.0;
• I need to loop over every element  for (int i = 0; i < nElements; i++)
• I need to add this element to the sum   sum += array[i]

Now I need to divide each entry by the total, to get the fraction of the total:

• for (int i = 0; i < nElements; i++)
• array[i] /= sum;

Now I need to multiply by 100 to get percentages:

• for (int i = 0; i < nElements; i++)
• array[i] *= 100.0;

That’s all well and good, and you could translate that literally into LabVIEW and it will get you the answer you want to see.  But that’s not the LabVIEW way of thinking.

What newcomers often fail to realize is that most primitive numeric functions (the ones with yellowish icons) will accept an array of numbers directly. This goes for basic arithmetic (add,subtract, multiply, divide), comparisons (greater than, less than, MAX/MIN), and many other operations.  It will happily multiply an array of numbers by a single scaler number, to produce an array of numbers.

This has great power to reduce the work that you do as the programmer. Consider the literal translation of the above code:

If that’s as good as it gets then why should I go with LabVIEW?

Well, it does get better.  There is a function in the numeric palette called ADD ARRAY ELEMENTS.  If we replace the entire first loop with this function, then we get to this:

Now for the en masse parts: You can replace the entire second loop with a single operation as well:

Any guesses what we can do with the third loop?    Yes, that’s right:

Now you have SO much more room to add comments about what you’re doing!

Now THIS is what makes you more productive in LabVIEW than in C; your chances for error are far less when you let the en masse operators handle the details, and you don’t even have to think about the details.

But be aware of what’s going on, however; there is no magic here.  Under the hood there is still a loop somewhere.  It’s now hidden somewhat; it’s not as obvious, but the work is still being done.  Don’t let the simplicity obscure the real processing that’s going on.

Here is an example of the normalizing function in use, from the real LabVIEW example examples\general\graphs\charts.llb\Draw Stacked Graph.vi (in LabVIEW 8.6. anyway).

This amounts to the same as our last part above.  In the example, the array given contains five elements and this is executed only once, so efficiency is not a concern.

But consider if the array was 10,000 elements. Don’t forget that the first operation is doing 10,000 divide operations, and the second is doing 10,000 multiplications.  Can you improve things?

Well, certainly! What you have to realize is that, by the associative property of numbers, (X / sum) * 100 is equal to (100 / sum) * X.  You also have to realize that 100 / sum, in this context, is a constant, and therefore needs to be calculated only once.  In effect, you are dividing by sum and multiplying by 100, but you are doing it 10,000 times!

With any luck at all, you get the same answer every time, so you only need to do it once:

THIS is why we use LabVIEW!

NOTE:  En masse is my term for this feature, it is not an official LabVIEW term.

LabVIEW beginners often either don’t know about type definitions, or don’t appreciate their value. This article will attempt to explain their use and how they can save you boatloads of time and effort.

Suppose you have a cluster of items that’s very handy to your project. For the sake of discussion, we’ll call it a channel, and assume this is a data acquisition project. A channel might have these items:

• Channel Name
• Active switch
• Scale factor
• Units

So, suppose you have an array of these to match the channels on your MIO DAQ board.

You might develop a series of VIs that deal with channels:

• You need an editor, so the user can rename them, select which ones to use, and scale them;
• You need a VI that takes an array of channels, and configures the hardware;
• You need to print the setup, so a VI takes an array of channels and formats a page for printing;
• You need to export the data to a spreadsheet, so another VI takes the array of channels and produces a spreadsheet.

and so on. You’ve defined the cluster and all these subVIs and it all works.

Now, though, you realize that you need to add another item to the channel, namely OFFSET. You have a new 4-20mA transducer which produces a 1-5V signal when you use the right resistor. So, instead of the single SCALE FACTOR (which assumes 0.0EU at 0.0 Volts), you implement the standard linear equation Y = mX + b, where X is the measured voltage, m is the SCALE FACTOR (slope), b is the OFFSET, and Y is the resulting Engineering Units (EU). How do you go about it?

The brute force way to go about it is to open up every instance of the cluster you used, and add an OFFSET term to the cluster. OUCH! In the example, you have 4-8 instances; that’s painful enough, but imagine if you had 50!

A slightly (slightly) more civilized way is to add the OFFSET term to one cluster somewhere, then copy the cluster, and paste it over all the old instances.

One of the good things about LabVIEW is that you can follow all the broken RUN arrows and figure out the places you missed. But is this really what computers are for? After all, LabVIEW knows all these things are broken, it knows WHY they are broken, but it’s YOU that has to chase them all down. So, do this a few dozen times and you might start wishing for a better way.

A Better Way

Enter the TYPEDEF, short for Type Definition. A Typedef is a “master” control. To use it, you ask for a new custom control (File | New | Custom Control). Here’s where you define the cluster you want for a channel. The first time you would use the four items mentioned initially. You then set the control menu to STRICT TYPEDEF, and SAVE the file with a name like CHANNEL.ctl. Now, every time you want to use it, you use the SELECT A CONTROL option on the panel palette and choose that file. What you get is a cluster that looks just like the one you made originally. Place one on your VI for exporting, another on the VI for printing, etc., etc. You can copy and paste them just like anything else.

So far, there’s nothing different. Where the value come in is when you need to change it. You may notice that you can’t change the cluster on your export VI. Drag something on top of it, and the something just sits there, on top. It doesn’t get put “into” the cluster. If yuo really do want to change it, you open the CTL file. You can do this thru the FILE menu, or notice that every instance has an OPEN TYPE DEF entry in the pop-up menu now.

If you open the CTL file, you can add the OFFSET term there, and SAVE it. When you do, EVERY INSTANCE of that control/indicator updates to follow! Open any of your VIs that used it, and it will have the OFFSET term in it! You’ve just changed 4-8 (or 40-80) controls in one whack. This is convenient for this example, but on a larger program, it is absolutely essential.

Another use for them is in ENUMs. Suppose you have an ENUM for units, with the options “PSI, kPA, mmHG, InH2O”. You can create that, and copy and paste it wherever you need it, but if you have to add something to the list, you’re in the same boat as the cluster, above. The answer is the same, make it a TYPEDEF, and use the TYPEDEF wherever you need to. Then when it’s changing time, all the instances update at once.

Generally, you don’t do anything special in a LabVIEW program to quit; when it runs out of things to do, it terminates. (Quite clever, that). Your program has a loop waiting on the user to do something: when the QUIT button is clicked, the loop stops. If that is the last thing in your VI, then the VI terminates, and it’s left on the screen for you. Usually, that’s what you want; you quit because you’re ready to add the next feature, or because you decided that the purple font on the pink background was too gaudy, or because you need to find out why the temperature shows -1.33e+44 degrees.

But if you compile your program into an executable, the same thing happens (the main window hangs around), but that’s usually NOT what you want here.  The user pressed the QUIT button – why doesn’t it quit?  Most programs make their windows disappear when the user quits, and yours doesn’t do that.   You might understand that it really did quit and the window’s just hanging around waiting for you to close it, but unless you enjoy the tech support calls that result, you should consider doing something about it.

To get that window to close in an executable, you have to QUIT LABVIEW.  Find that function on the APPLICATION CONTROL palette and put it where it will execute when everything in your program is safely shut down.

The trouble is, it will ALSO quit LabVIEW when you’re in the development system.  That’s nice in the executable, as all your windows go away just like they’re supposed to. But in the development system, you don’t want to quit developing; you want to stop your program from running.

One easy way to satisfy both requirements is to use the ROOT FOLDER vi.  It has an output called NOT IN LIBRARY which connects to the QUIT? input on the QUIT LABVIEW function.  If you’re already using that VI to ascertain your root folder, then just remember the initial value of NOT IN LIBRARY.  Or call it again at quitting time; it’s small and fast.

That way, you close up the windows in an executable, but leave it ready in the development environment, and you don’t have to set conditionals, or remember to set a boolean flag in your code.  It works without change in either situation.

I guess this Internet thing is here to stay, huh? It can be daunting at first, what with looking at the complexities of a web page and the realization that banks use it to launch nuclear missiles and the military can conduct a million two-dollar transactions in a day (or something like that…:-). If you grew up with RS-232 and GPIB as the ways for one box to talk to another, it might seem seriously complicated, what with clients and servers and HTTP and proxies and routers and ports and …

It’s not.

It’s not even close.

The truth is, it’s a whole lot simpler than either of those technologies, at least from a software point of view. And a whole lot more versatile, as well. There’s one analogy that brought it home for me:

TCP communications is just like using a telephone.

This is true in a lot of ways:

• To make a TCP connection, you have to open a connection to a given IP address (dial a phone number).
• To answer a connection, you have to be listening for one (have your ringer turned on),
• Once the connection is established, the roles of client and server are established by convention, not by any property of the connection. Either end can send at any time (you can call the office of the U.S. President, but who is the client and who is the server is debatable).
• A port is the final destination-specifying part of an address (like an extension).
• Figuring out what you’re going to say and how you’re going to say it takes a whole lot more thought than establishing the connection itself.

How to Use TCP in Your Programs

First, decide how it is to be used. By convention, the “client” is the piece that initiates the call and requests information, and the “server” is the piece that answers the call and dispenses information. Note that this is a general guideline, not a rule: the connection works both ways. How does that relate to your situation? Which piece is going to initiate the call? Which piece will answer? Do you have control of both ends of the connection? If you don’t, you have to play by the rules already established by the other end (if you want to dial up a web server, you can; but what you get back is not under your control).

Next, establish how you’re going to obtain the server’s IP number for the client. If you have a local area network (LAN), you can just fix the address (192.168.xxx.xxx) and store a constant somewhere, or offer it as a user-configurable field. If your project is large-enough scale, you can register a domain name, and the DNS service will connect the name (www.culverson.com) to your IP number. That’s only useful if it’s supposed to be a publicly-available service though. For most small scale projects, make it a user-configurable field and be done with it.

You need to know several VIs, all in the PROTOCOLS: TCP palette:

• TCP Open Connection
• TCP Close Connection
• TCP Write
• TCP Read
• TCP Create Listener
• TCP Wait on Listener

For the client side, it’s extremely easy:

1. Call TCP OPEN CONNECTION with the IP Number you want to connect to, the PORT number you want to connect to, and a suitable timeout. “Suitable” requires a bit of thought: if you’re dialing across the room on a clean network, 100 mSec might be adequate, but if you’re dialing across the world, then 10000 mSec might be more appropriate.
2. Call TCP WRITE, as appropriate. For TCP WRITE, you have to provide the CONNECTION ID (obtained from TCP OPEN CONNECTION ), and a string to send. It doesn’t have to be ASCII, you can flatten anything into a string and send it. That is especially useful for sending binary data.
3. Call TCP READ, as appropriate. For TCP READ, you have to provide the CONNECTION ID (obtained from TCP OPEN CONNECTION ), a MODE (more about that later), and a NUMBER OF BYTES TO READ (more about that later).
4. When you’re done, call TCP CLOSE CONNECTION.

For the server side, it’s only a tad more complicated:

1. Call TCP CREATE LISTENER. This gives you a LISTENER ID.
2. In a WHILE loop, call TCP WAIT ON LISTENER, using the LISTENER ID you just got. Usually you use a timeout of -1 (never). You’ll get out of it later. This suspends the loop until a connection comes in; for that reason you have this in a separate loop from your main code.
3. When a connection comes in, the WAIT ON LISTENER function returns to you without an error. You want to check the error code – when it returns WITH an error, you want to terminate your loop.
4. If you have no error, then the CONNECTION ID out of WAIT ON LISTENER is valid. Call TCP READ and TCP WRITE, as appropriate.
5. When you’re done with this connection, call TCP CLOSE CONNECTION on the CONNECTION ID, and repeat the loop, to wait on another connection to come in.
6. When you’re ready to quit the program, or at least quit listening, call TCP CLOSE CONNECTION, but use the LISTENER ID as an input for that. That will cause WAIT ON LISTENER to terminate with an error, and your loop to stop.

For the MODE parameter to TCP READ, there are four choices, as detailed in the HELP for that function. I almost always use BUFFERED, so that I get either nothing, or the amount of bytes I requested. When talking to an instrument that sends Carriage Returns / Line Feeds, I will use CRLF mode, so that I get things a line at a time. I have never used the other two modes. I also usually use a timeout value of zero, so that it returns immediately, with either a whole message to deal with, or a timeout error. In any case, I have better things to do that wait around for the message to come in.

So, how many bytes do you request? Good question. There are two methods in common use, each appropriate to some circumstances. The first is to design a protocol that uses a fixed length. If all messages can be sent in 13 bytes, then use 13 as a message length, and you’re done. Anything that is shorter can be padded up to 13 bytes, and it’s OK. For other situations, that is not adequate. In one project I’ve done, some messages can be a single byte, others can be several thousand. It would be very wasteful to pad every message up to 4000 bytes, so a better scheme is needed. The answer is to send a fixed-size header, and then a variable-sized data portion. The header includes a number specifying the length of the data portion. So each receive operation must actually read twice; once to read a header, and once to read the payload. LabVIEW documentation suggests that it is better(faster) to combine the header and payload and do a single TCP WRITE than to do two separate TCP WRITEs for the header and payload. That means the OS handles it as one transmission, not two, which makes sense.

So, for my case, I designed a HEADER typedef (you are using typedefs, aren’t you?), consisting of two fields: a COMMAND field (1 byte) and a PAYLOAD SIZE field, a two byte integer (U16).

The COMMAND field contains an enumerated typedef, defining what type of message this is. The SIZE field specifies the payload to follow.

The receiving end can therefore use a common procedure to receive messages. First you read 3 bytes from the connection, and unflatten it into a header. Then you use the PACKET SIZE field of that header to determine how much more to read for the payload.

That’s all there is to it! Well, except for that pesky bit about what to say. You still need to decide what the protocol is going to be. That’s just another way of defining who’s going to say what when. Does the server answer with a “Hello”, or does the server expect the client to ask the question first? If you control both ends, it’s entirely up to you.

Enjoy.