Cat

Hmm. I got mine a few weeks ago...

This is exactly why I'm attempting to go back over 10 years of code and add comments. I'll be retiring in the not-too-distant future and there is no one in my group who can do what I do. I keep reminding Management of this, but we have a long history of letting highly skilled technical people walk out the door without first finding someone they can train up to replace them. So I've been slowly adding comments (where appropriate) to the 2500+ vis that some bright-eyed recent college graduate who did a project once in LabVIEW, and therefore must be an expert, is going to be handed some day. Hopefully it will help... If not, they can always hire me back as a part-time contractor making 3x what I'm being paid now.

Maybe the concept of self-documenting code is the Holy Grail we should all be striving to attain. However, we need to be careful about declaring our own code has reached this state. Code is only self-documenting when someone with a basic knowledge of the language/environment and the goal of the code can, having never seen it before, read it, and understand how it does what it's supposed to do. In other words, it's something the developer should not be the judge of for his/her own code (of course we all understand our own code! If we don't, no amount of commenting will help). I have been stuck on several occassions with having to wade thru someone else's "self-documenting" code and it has been anything but.

Speaking of which, just in case there are others of you out there who have 64-bit systems, and have always downloaded the LV installation packages from the web... The DVDs that NI sends out do *not* have the 64-bit IDE. If you use the DVDs, you will get a 32-bit install, even on a 64-bit system. With no apparent warnings -- other than the fact it asks if you want to install into "Program Files (x86)". Yes, I just learned this one the hard way. Go here to kudo an idea to add the 64-bit IDE to the Platform DVDs.

Darin: Thanks for the code. I unfortunately oversimplified a bit in my picture. The reason why there are separate arrays for each row is because there can be different numbers of sensors in each row. So there are several different box widths. I think this would mean I can't use the Intensity Chart. Unless I do one for each row. Hmm... Using an Intensity Chart might actually take care of a few minor issues I've had to work around with using a color ramp. Oh, and I didn't even know the PlotImage property existed. That is cool! Phillip: Thank you for the code, too. The ring method does seem to be the most straight-forward of the options. Having the colors all defined in the ring would be a Good Thing, and handy if my Demanding Users decide they want a different color for some other designation. I'd have to break it up into rows, also, but that wouldn't be a problem. Yair: Thanks for the suggestion. However, any time one describes anything in LabVIEW as "problematic in terms of memory usage," it does not give me a warm fuzzy feeling! Memory usage is one of the two problems I continuously have with LV (that and the crappy sound drivers). If I understand correctly, I'll have 1000+ rectangles that need to be redrawn and loaded into 1000+ picture controls every second. I can try it on a small scale and see what happens. Thanks again, everyone, for your help with this! I still would like to know what the purpose of "Allow Transparent" is for with the color box, when it doesn't actually make the control transparent. Maybe I'll ask over on the Dark Side...

You assume correctly. The value of the color ramp underneath the color box has to be seen. That's why the color box needs to be transparent. That's what I was originally thinking, but it didn't work out very well. There is a wide range of valid values, although 95% of the time the real data will be in a narrow subset of that. So If I use the whole possible data range, the color gradient for the color ramp is quite small. The user needs to see subtle differences in the sensor values, but also needs to see that "high" color flash on to know that some large transient has just hit the system. I thought to use the "low" color for both unused and bad channels, but the user wants to be able to differentiate between the two. Demanding user...

Wow. If you've ever entered any of those speed programming contests, you must have won! It doesn't quite apply here, but it's an interesting concept, and I might steal it for something else I'm working on. Thanks! Here's a pic of what I'm looking for. But imagine it with clusters with 20 rows and 50 columns... The sensor data on the left is a cluster of arrays of color ramps. I want to overlay it with the cluster of color box arrays on the right, to produce the cluster on the bottom. I had to use booleans to do this for the picture (obviously). I may have to do this for the real thing, I guess. I can use 20 clusters of 50 elements each (instead of arrays) so I can change the colors on individual booleans.

Yes, that's what I was attempting to say at the end of my original post. It just seems like a lot of work to replicate something there is seemingly already a control for.

I am going to set the color box programmatically depending on what type of sensor indicator (a color ramp) is underneath it. If it is a unused or bad sensor, the color box will have a mask color. If it is a good sensor, the color box will be transparent in order to see the sensor data value underneath it. The user never sets this color box. I can't hide the color boxes, because the color boxes are in a series of arrays. There are 1000+ sensors organized in 20 arrays of 50 sensors each in order to not have to deal with 1000+ individual controls.

This falls in the category of "It's the little things that sometimes make LV programming so frustrating." I need to be able to make a transparent color box. One would think that selecting the "Allow Transparent" property, and picking the transparent box on the color selector tool would make the box transparent, but no. It makes the box white with a capital T in it. My understanding of the definition of "transparent" is that if something is transparent, you can clearly see anything behind it. Not that you can see a white box with a "T" over top of it. Am I missing something? There are lots of links to cludgey work-arounds, in versions of LV before "Allow transparent" was an option (I guess). But this should be a trivial thing, considering the property is there. And any other control that is allowed to be transparent is actually transparent. (In the actual app, I've got a cluster of arrays with a total of 1000+ color ramps representing sensor channel values. I need an overlay of color boxes to mask out unused channels with one color, bad channels with another color, and transparent boxes for good channels. Except transparent color boxes aren't actually transparent... I could cludge this by using booleans or something instead, but it seems like this is what a color box should be for.)

Unfortunately, the Math Kernal Libraries *are* included. They're checked with all the other RTE stuff. But, being the mistrustful type, I explicitly reinstalled them (both 32 & 64b). I got the usual Repair, Modify, Delete options, deleted, then reinstalled. Still doesn't work. But thanks for the suggestion.

Yes, LabVIEW12.0f3

I had to do this to get an installation working. More details here. But just wanted to say thanks!

I finally convinced Bossman we should move to making 64-bit exectuables, since most of our analysts use 64-bit machines. And it's a pain developing on a 64-bit machine, porting all the code to a 32-bit machine, recompiling, rebuilding, making an installation, blah, blah, blah. So I make my first real 64-bit build, put all my exes into an installer, and... it doesn't run. Specifically anything that is calling NI_AALPro.lvlib doesn't run. It seems to be missing. When it's run from dynamic code, the code just gets the "Code error" message and doesn't run. When it's called normally, the exe throws lots of errors on startup like: "An error occurred loading NI_AALPro.lvib: Unwrap Phase.vi LabVIEW load code error 3: Could not open front panel." (not really sure why this is an error, since Unwrap Phase isn't supposed to have an open front panel) And when the front panel of the exe opens (with a broken error, of course) there's a long list of NI_AALPro.lvib vis that are missing. Ironically, the exact same build/installer parameters (as far as I can tell) work fine when done on a 32-bit machine. Sigh. mje in this thread said he had to install the runtime separately to make his installation work correctly. I tried this, and the exes are now running correctly. But this is not a good long term solution as these applications need to be installed on a few dozen computers, many of which I will not have access to until right before the next test. And Bossman isn't very happy with me... Any idea what I might be doing wrong?

I read this as: "If you have an irritable object ... you can write somewhat more tense code."

You probably just stole NI's April Fool's Day joke.

I wish that was an option. Personally, I was quite happy with 1024x768! As you note, 1920x1080 is becoming the standard. Plus, when I develop on my lower res laptop, all the front panels look tiny and the fonts are messed up on the standard monitors. I've had to become very familiar with using multiple panes around GUI elements so my users can expand and contract FPs to something easier to view on different resolution monitors.

You can go for me, next time! (The grass is always greener...)

No, it's age. I've never been very mature. I realized that the huge monitors we usually hook up to our fielded systems are actually the same resolution as my laptop. So I'm going to use one of those for development while I'm in the lab. Then I just have to squint a lot at my laptop screen when I'm scrunched up in a dark corner on some submarine trying to do code changes. It will make the experience even more wonderful.

Thank you for your answer, kind sir. I was afraid I was asking too much. Hopefully "a few years away" happens before I retire. :-)

I recently got handed a new laptop to start developing on. The problem is that it's got a much higher resolution monitor than what I've been using. 1920x1080 vs. 1280x800. In order to actually be able to read any of my code without serious squinting, I've upped the font, etc. size to 125% (this is on a Win7 box). When I did this, thankfully, lots of stuff in LabVIEW got bigger. Local/global variables, bundle by name, etc. all are much more readable. However, in the block diagram, all the LabVIEW primitives, subvi boxes, as well as controls and indicators stayed the same tiny size. Also, in Project Explorer, the descenders are cut off of any letters in a vi name. Same with the font name in the upper middle of the front panel. So the question: Is there any way to make LabVIEW itself bigger? I can only see this problem as getting worse and worse as monitor resolutions get higher and higher.

Be careful if you're filling the disk up -- it will get much slower towards the "inside". The last benchmark I did on a 1TB Seagate disk went from 85MB/s at the start to 45MB/s when the disk was full.

Did you all do this at the BBQ? The kit is currently out of stock. Probably a good thing for my budget.

I agree, I was hoping that using a waveform data type was going to magically make all that worthwhile in the long run. But since a waveform is just a cluster... Thanks for reminding me about DVRs. I looked at them briefly when I upgraded to LV11 (from 8.6.1), but it didn't help the application I was working on at that time. This app might benefit. Huh. That is a little counter-intuitive. I think I am going to stay away from waveforms, unless there is a real driving reason to use them.

Short and to the point. Thanks! No, I'm not using RT FIFOs. But this is good to know if I ever do.