LAVA 1.0 Content

Do a nice icon and your development team members aren't even tempted to look inside.

I guess I'll try this technique. It does provide a bit of hiding that might prevent someone from tinkering with my typdefs.

Unfortunately, most of the icons I've seen are B/W with oversized abbreviated text that means little or nothing; not to mention missing any sort of description . When I make what I consider nice icons, I get comments that I have too much time or that I'm showing off!

The Egyptians did this long before anyone else....

Might it predate NI's patents on the basic LabVIEW system? ...

Well, curious as I am, I Googled "Bob Munck Softech" I found where Bob made references to "SADT: Structured Analysis and Design Technique".

You can read more about SADT in a PDF file at the top of this page. I haven't got the time to read it thoroughly, but the date was 1977 and contained some interesting hand-made drawings...

What's weird is that I also found a Softech Alumni page that includes the name of an ADA programmer who works for my company, and he's just recently started learning LabVIEW!

I've just starting learning about Matlab, and while surfing found this blog that I now subscribe to.

I liked this entry called Why so many languages? Programming languages, Computation, and Math

The entry does not mention LabVIEW directly, but this post by Bob Munck made me smile:

Back in the late 70's, NRL hired my company (SofTech) to figure out why software for its AN/UYS-1 signal processing computer was so expensive and so bad. I was technical director of the DC office and project lead. We discovered that the acoustical engineers specified the software by drawing data flow diagrams where the nodes were mostly a standard set of operations like "FFT," "Bandpass Filter," etc. Those diagrams would be given to a roomfull of programmers who would laborously convert them into sequential SPL/1 or CMS-2 code by essentially ripping the functionality apart and re-assembling it in a "crystal clock architecture."

My big idea seems pretty obvious now, but was radical then: create an engine that will run the dataflow diagrams. We wrote a parser to convert the diagrams into an internal form and an interpreter to run it on the UYS-1. Worked like a charm; we took a diagram that (ahem) IBM had spent several tens of millions of 1970's dollars converting into code and got it running in about a month with five programmers. Believe it or don't, our implementation was slightly faster. Long story short, the Navy specified that the next generation of signal processors, the AN/UYS-2, be designed (by Bell Labs) as a dataflow engine at the hardware level. That machine and that architecture are still in use today.

So that's an example where a highly-specialized programming language was the right solution, if you're willing to call dataflow diagrams a programming language. Note, though, that we eliminated the programmers.

Calling dataflow diagrams a programming langauge? A highly-specialized programming language consisting of an engine that runs dataflow diagrams that perform FFTs and bandpass filtering? Where have I heard of this before? Oh yeah....

(Where can I find the NI blue eagle logo in the smilies list?)

Did you see the ultimate LabVIEW Geek questions for this week (6)

If you save a VI to a previous version, and then open the saved VI in that previous version, why does LabVIEW add an * next to the VI name, indicating that there are unsaved changes? (Correct answer worth: 30 points)

The new version removes the block diagram and the compiled code so the old version can rebuild it from the machine code only

The new version compiles the old version, but it can't actually save the block diagram in the correct form for the old version

The new version can write the block diagram in the correct form for the old version, but it can't actually compile the old version

Prove your geekiness NOW! :laugh:

I guess I'm bugged that there is no BD layout capability for a typdef'd control.

I use a typdef to define the data stored in a functional global. I place a constant of this on the BD of the functional global to initialize an array stored in a shift register. It just happens to be defined as strict.

If I add an element to the typedef (say a boolean), it will, as expected, appear properly on the front panels where used. OK. What's the problem? The constant on the BD of the functional global will resize and rearrange from the cosmetic rearrangement in the functional global.

It doesn't matter how I have the typedef set (plain or strict, autsizing, autoaranging, etc) the BD constant will always reset as shown

If the constant is placed inside a case and it parts arranged/scaled to fit the window, a change will make the constant exceed the case window size.

Before:

After:

I think in Michael's orignal post, he was placing the typdef'd enum in an array constant on the BD. If he added an item to the enum, his enum in the array constant (queued state machine) would resize, to some arbitrary length, making the code unreadable. It would be nice to have the ability to set the way a typdef'd control appears on a BD. Right now, LabVIEW "does what it wants". I would like the control editor to allow us to view and configure the BD appearance of a typdef'd control. Why? Because I want to...

Maybe if I had the time to learn and use GOOP, these sorts of problems would go away... Maybe I should change my signature to "almost as good as some other people" :laugh:

p.s. I looked in the Wish List, and couldn't find it.

I have a stict typdef cluster that resizes on the BD, and I don't like it either.

Doesn't it make sense that a typedef control should have a block diagram with editing limited to control's top level container (object, cluster or array)?

You wouldn't be able to wire to/from the control, but you could at least configure it's appearance when placed on a block diagram constant.

Now, how do I get this to the NI Developers Brainstorming forum for implementation in 8.???

Hi,

I'd like to document my library similar way as NI does. To do this I need an image of each connector pane control block diagram terminal. For array and cluster controls I want to fetch the subitem images again the same way as NI does. This is where I fail. I didn't find a scripting function that using which I can get the images for array and cluster subimages. Does anybody have a good idea how to do this?

-jimi-

I downloaded the NI Plug and Play driver for your instrument an looked at your updated code.

I opended the driver vi called tktds3k Read Waveform.vi and saw that there are two sub-vis (functions) called inside. The first is called initiate, the second is fetch. The help for the initiate indicates this should only be used once in a sequence of calls to lower level vis.

I then opened and looked at the example vi in the top pallete for the driver and saw that the Dual Channel Waveform Acquire example uses one Initiate and two fetch calls in series rather than the Read Waveform vi as in your example.

Try following the example and see if this improves the performance. :thumbup:

Even though Ethernet is a faster interface, it does not have all of the handshaking and determinism of GPIB. It may be that driver implementation is written for compatability with RS232 AND GPIB AND Ethernet more than for performance over any one of these busses.

I assume you already figured how to convert strings into LV timestamps. When you have LV timestamps, then it's quite easy to compute the timedifference in the format you wanted. See the image below.

There is also a way to find out which VIs the polymorphic VI consits of. See the picture below.

I would try reading the three channels sequentially using instrument handles and error in / error out clusters to control data flow. See if this makes any difference.

The TK Read sub-vi might be erroring out on the Ethernet side. Check the error out; it may have some information in it!

Example: I don't have the drivers for this instrument

Taking that route, why not make it simpler-

My father and uncle drove non-stop from Buffalo, NY to Miami FL in the late 1950s. To stay awake, the driver would place his fingers on the top of the window glass, then roll the window up to the top. If he started to doze off, his fingers would be pulled and wake him up. It worked back then, before they even had the PC!

Sometimes technology is not the answer...

Maybe instead of passively monitoring the state of the driver, you could create an application that would engage the driver. Failure to interact, a progressive slowing or change in response might indicate fatigue. Combine technology with psychology :question: I remember reading about an intelligence/puzzle plugin for the DS-Lite recently. Something like that?

Good on 'ya, mate!

You could also add methods to set blinking, etc... )

Well, it seems you can't set blinking . I tried placing a break on the facade vi, and used highlight execution. I learned that you can set the property of the indicator, but the blinking only applies while the XControl facade vi is executing.

This explains a strange behavior I was seeing in that sometimes the LED had a yellow color instead of the red or green that I selected. It turns out the facade vi left the control set to my blink foreground color (my setting is yellow). I changed to orange, and verified this.

Yuck.

What other properties are only applicable while the facade vi is running? What is an XControl, a run VI in subpanel with the connector pane replaced with the data type? Sort of interesting to play with, but not of much value to me at this time (LV 8.0)

It appears that LabVIEW searches are about 75% male and 25 % female according to Microsoft's adCenter Labs tool when using query.

Yet, if you use URL and enter www.ni.com, it flips to 16% male and 84% female. Either the girls just want to know what us guys are talking about, or Microsoft still has a ways to go. Maybe their adCenter folks should try Googling for the answer! :laugh:

BEER was 56% male, 44% female. Everyone is looking for beer! :beer:

Note: for you VME guys, better look at updating your skills. Only 4% female

Creating a tri-state XControl LED was fairly easy. I was able to whip something together in about 15 minutes (including the research time). If you're using LV 8.0, this seems the way to go....

Download File:post-949-1151086483.zip

(OK It's actually quad state. You could change the data 1 ctl from an enum to an integer, then use the color pallete to set the LED to any color you want. You could also add methods to set blinking, etc... )

You can change the color of a block diagram, sequence structure, case structure etc.

Some purists might complain about colors on the BD, but I do sometimes use an alternating light grey background in heavily nested for or while loops. I also sometimes use a yellow background in a loop or case to remind me of critical points in the code, or cases that should not occur.

The other thing I've started doing (artistic license only) is to label my loops, change the background and forground of the label to the dark grey of the loop, Move the label into the inside upper left and use a font that is bold and white. I just like how it looks

No one will be able to answer these questions on a public forum because of the NDA agreements they have signed. Your best bet is to come to NIWeek and talk to a developer.

You may also try to apply for a beta developer status to find out what new features there may be in LabVIEW beta. Go to http://ni.com/beta and fill in the beta tester application form . You may first call to your local NI technical contact person. His recommendation may make it easier for you to get into the beta tester program (you need his/her email address for the application).

If you get accepted to the beta program, you should email LV beta helpdesk to ask to be added to NI beta discussion forums as well. There are some interesting discussions going on.

I think if you just first open an application reference and then open a VI reference (wire the application reference as an input). Each application propably have a different TCP port on the local machine so you can access different applications if you know the TCP port. There may be an easier way I'm not aware of.

I have to try it out in one of my very performance hungry applications. Hmm.. I wonder if this works together with the new GOOP Developer...

Free?!?

As in :beer: :thumbup:

I managed to come by a free admission pass at the Developer Education Day in Boston. It doesn't cover airfare or lodging, but that's OK. Now if I can just find someone to give me a ride to the airport.... Doh!

Thank you Michael for getting me hooked on the Dilbert Blog.

I was reading this, and couldn't resist customizing the comic just a bit!

Google is your friend - "OBDII LabVIEW"

OBD-II or OBDII is how it is normally written, not OBD2. This should help you on your way....

Mmmm, good coffee today...

It has not yet been released, but it is already up on amazon and should be out soon.

I hope it's released before NIWeek, I'd like to have something to read on the flight