LabVIEW charts, out of the box, don’t lend themselves to displaying the actual time of day.  By default they give you 1024 history points and a visible scale of 0-100 so what you see is in terms of sample numbers, having no relation to actual time. This is reasonable, given that the scale is adjustable in so many ways; there’s no way to guess what you want, so it’s up to you to tailor it to fit what you want.

Sometimes it’s useful to display the time of day on your charts, and keep that axis correctly updated as data flows in. For example:

As you can see, the leading edge of the plots coincides with the current time on the clock  (see here for how to do the clock indicator).   As data keeps coming in to this chart, the leading edge will reach the right side and the chart (and the X-axis scale) will scroll to the left, thus always matching the time of day.

Out of the box, a LabVIEW chart has a history of 1024 samples, and an X scale of 0-100 samples.  This scale has nothing to do with time, so if you want it to display the time, then you have to do several things to make it work.  If you have a CLEAR CHART function, triggered by a button or something, then attach this code to that action, otherwise just do it once when you start the data flowing  (Ideally, you should do this as you feed the first sample to the chart, but the few mSec difference that makes probably won’t matter).

First, you clear the history.  That makes sure the OFFSET number is operating from an empty buffer (Time 0).  If the history buffer contains data, then the OFFSET applies to the end of it, and that’s not what you want.  The constant has to be an empty array of the same type of data as you feed to the chart (cluster of two DBLs in this case).

Next you set the XSCALE.OFFSET to set the OFFSET number to the current time.

Next you set the XSCALE.MULTIPLIER to the time (in sec) between samples that you display.

Next you set the XSCALE.MAXIMUM to now + the duration (in seconds) that you want the chart to show.

Do them in that order, or it could get confusing.  You also can set the CHART HISTORY LENGTH to match the duration / the display period.  For one minute at 2 Hz, that would be 120 samples.  You only need to do that step once – it’s a property that is not programmable.

Enjoy.

]]> http://culverson.com/keeping-your-charts-up-to-date/feed/ 2 http://culverson.com/an-improved-analog-clock/ http://culverson.com/an-improved-analog-clock/#comments Wed, 19 Aug 2009 15:58:35 +0000 Steve http://jimdugan.com/culverson/?p=53 Sometimes all that digital stuff is just too bland.

A bug undocumented feature of the original analog clock was that the markers on the scale were at intervals of 1.25 seconds, a consequence of LabVIEW preferring to use 4 intervals per major tick, when we silly humans use 5.  As a result, it looked a bit odd.  As I said then, if we’re going for an analog, then let’s go for the analog.

Attempts to coerce LabVIEW into making the scale the way we wanted were not successful; it has a long habit of thinking that four is a nice number and five is just an odd number, so I could not make it work.

So how do we improve it?  Simply disregard the built-in scale and substitute a picture.  After all, we all know where the numbers are on a clock face, if we’ve lined up the 0 and the 12 on our LabVIEW scales at the top of the circle, then all else has to fall into place.

Click here to download the example LLB file, in LV 8.0 format. It has the same math VI as before (read the previous post for details), just the clock face is different.

Enjoy.

If you want to display a time-of-day clock in LabVIEW, it takes three seconds to plop down a TIMESTAMP indicator, and 10 more seconds to enter ADVANCED EDITING mode, and skip the month, day and year, and format it the way you want. Piece of cake.

And it looks just exactly like every other digital clock out there: six digits, two colons, everybody knows what it means. And that’s fine for a lot of purposes.

But sometimes you like to decorate your work a little bit. If you’ve got space on a front panel, and a few cycles of execution time in your run loop, then consider an analog clock.

The visual part of this is pretty simple: a custom control with a cluster of three gauges, all with their scales stretched to a full 360° and both ends of the scale at the top:

• A gauge indicator in the back: single dark red needle, and the scale set to 0..12.
• A gauge indicator with an INVISIBLE scale of 0..60, and a bright red needle for minutes.
• A gauge indicator with an INVISIBLE scale of 0..60, and a gray needle for seconds.

The three indicators are sized identically and lined up identically, with transparent backgrounds, so the needles show through.

An analog is an analogy

You might think it’s straightforward to use this thing – just pass a cluster of hours, minutes, and seconds to the indicator, and you’re done.

You’d be wrong.

Consider what would happen: at 9:22:10, as shown above, the hour hand would be EXACTLY on the 9, the minute hand EXACTLY on the 22. Not exactly what you would expect from an analog clock. It’s even worse 35 minutes later: the minute hand would be on the 57, but the hour hand is still EXACTLY on the 9. It looks for all the world like it’s three minutes before nine, but it’s actually 9:57. If you’re going for the analog, then you’ve got to do better than that.

The gauges accept floating point numbers, so we’re in luck. If you think of how an analog clock works, it’s not the same as a digital clock (and you can quote me on that!). The second hand may move smoothly around the dial, or it may snap from one second to the next. We choose the snap idea, as it’s easier. But the minute hand definitely does NOT snap – it moves smoothly.

So we have to incorporate the position of the SECOND hand into the position of the MINUTE hand. Namely, we add SECONDS / 60 to the MINUTES value given, so that 6:30 will be halfway between 6 and 7, and 6:57 will be just before 7. Similarly, we have to incorporate the position of the MINUTE hand into the position of the HOURS hand so that 6:30:00 puts the hour hand at 6.5, halfway between 6 and 7.

Download

Click to download the example (about 12kB ZIP), containing the typedef indicator you can put on your panel, and a VI to do the above math for it. You can display the CURRENT time by leaving the TIME input unwired, or display a specific time by supplying a timestamp.

Enjoy.

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.

When your program is large enough to have multiple folders to store files in, or read them from, then you have to know, or find, where those folders are.

Asking your users to create those folders will surely raise the ire of some, if not most of them. After all, the computer is capable of creating folders, the computer knows what folders are needed, why is this %!^#$^ box asking ME to do its job?

Complaining to the user about a folder not being found is in the same league; no matter how many times you print it in the instructions that they have to create the folders beforehand, folks will run your program and object to the complaint it gives them.

So, you put in things like CREATE FOLDER (”C:\MyWonderfulProgram\ConfigFiles”), and everything is all groovy, right?

Not exactly. Maybe I want to put this program on drive D:. Maybe I want to run it under OS X. Maybe I want to put it under C:\2009\March\Mediocre Programs. What do you do then?

One solution is to make all these folders relative to the root. And to do that, you have to find out where you are.

Download a Helper

I have used the following VI, for that purpose, since 1992.

Click to download Root Folder.vi

Basically, put it into a library (LLB). Call it early on when your main VI starts.
Call it with INIT = TRUE, once. When you INIT it, you can either pass the path of the calling VI (This VI’s Path) in the FILE palette, or leave the path input unwired. If you leave it unwired, it assumes that it’s in a library, and finds the path to the folder containing the library. If you provide a path, it assumes the path is to a VI in a library, and provides the path to the folder containing that library.
For our purposes, a library and an executable are the same thing, and this code works unmodified in either situation. Do not use it if it is not in a library.
After INITing it once, you can call it wherever you want to find out the root folder. You can then use BUILD PATH and create or open folders using the root folder and have them work anywhere.

Caution: Some operating systems (VISTA, in particular) will write-protect the APPLICATIONS directory, so that if the program tries to create a file or folder in that directory, it will be prevented from doings so, unless the app is run as an administrator. If you must run in that situation, consider a different method of locating the files you want to create / use.