NI Week is here!

It's finally the NI Week time of year and I am excited! I drove down early this morning. I found I couldn't sleep in spite of my need to get up early and be awake for the 3 hour drive down.

I've come on an Expo pass this year so my learning opportunities will be more limited than previous years but that doesn't dampen my desires to learn, network, and generally be nerdy...one of my favorite pastimes.

I am waiting for the Keynotes to start and thinking...WHO came up with the easy-listening, AC/DC re-mix of T.N.T. along with all the other sad remixes of good music. Basically, this my first disappoint in NI-Week in the last 3 years. I have a feeling I will get over it as the day goes on.

The NI Demonstrations were good but I really enjoyed Jeff K. future state of NI speech. I'm impressed evey year by his talks.

The Expo floor, of course, is very informational, lots of good information and potential uses. The unfortunate thing is, most of the information I gather will either be to new and different to be useful or will fall on deaf ears.

I am going to document what I find out and pass it on.

Again, this year, there is only one CVI demo and they won't let it run because it's to dangerous. It's a desructive test of a CD. Basically the CD crumbles. I guess CVI programmers are braver than LabVIEW programmers. I'm proposing a CVI controlled icamera and potato gun to take out the LabVIEW demo's...I don't think they'll go for it.

TestStudio, Hmmm...

It's been a while, I've doing a lot of playing with my Genetic Algorithms program, writing a Neural Net program, and studying Chaos.

First, Congratulations to the Wendy, former Queen of CVI. She's moved on MIT, graduate school, and opportunities up there. Way to go!

Second, Welcome Adri K, the new Queen of CVI and all NI things Text. Everyone needs to go to NI Week and say hi to her or the NI CVI community.

Now to the meat of the subject. TestStudio, not TestStand but TestStudio.Teradyne's offering in the test sequencing arena. It seems to be cheap knock off of TestStand put out by Teradyne. This is the product we'll be using on our next test set. It was not my choice or the choice of anyone who will have to develop on it.

Since this choice has been made for use and I've been told to accept it, I want to write about comparisons between TestStudio and TestStand.

First comparison...none. Teradyne, who is apparently very big on keeping the purchaser of the product in the dark, will not allow us to have an evaluation copy or access the support site until they get their PO.

We are told it's great, or at least the only product that will run its proprietary switch manger. We're also told the switch manager is a .dll. .dll's will run under TestStand, so why is TestStudio the only way to run the switch manager?

I guess I'll have to wait until we actually get the software before I can compare it. Since TestStand allows a 30 day evaluation and TestStudio doesn't, plus we can't get to the support. Is Teradyne's product so bad they can't even allow people to evaluate it?

TestStand 2, TestStudio -2. Negative since I can't even get to any documentation except Propaganda sheet.

CVI Rules!

And LabVIEW Drools. It had to be said.

I finally got away from doing documentation and processes for a day, so I was able to do some fun stuff...Technical work. I'm currently working on a Test Station Self Test. Some parts of the Self Test are done in LabVIEW, partially because others did those parts with LabVIEW, partially because I broke down and wrote some LabVIEW code.

Well, I'm updating all the LabVIEW code to fit it into TestStand for the Self Test. It's frustrating, hard to find the vi's I need and it does things for me...I'm not sure what...that I don't think I want it to. For example, I opened one of the vi's to see the picture on one of the DAQmx self test vi it contained (in order to find it's equivalent for NI Sync) with out changing a thing. When I closed the vi, with no changes, it asked me if I wanted to save. I didn't change anything! What was different where it needed to change?

As I was working in LabVIEW, it took quite a while to update the code, but I was learning. I was figuring out what the microscopic pictures were on the vi's, although I still have no idea why they chose the pictures they did for some of them. Things were moving along smoothly with only a low constant pain in my wrist. I was finally done with the LabVIEW part.

Then I needed to develop some CVI instrument wrappers. And BAM! They were done! The text based code just flowed from my finger tips. I plugged it into TestStand and BAM BAM! It worked...first try! And I wasn't even entirely sure how the RF Signal Generator worked. Compared to the struggle I had getting the LabVIEW stuff out, it was a breeze. It was like night and day! It was slicker than deer guts on a door knob! (A good old southern saying)

All I could say was CVI Rules! and LabVIEW drools!

LabVIEWism

-ism: Docturine; Theory; System of principles; Distinctive or Character trait.

I've noticed some traits of LabVIEW programmers and the word "LabVIEWism" came to mind. Sort of like Hinduism or materialism. It seems to be more than just a programming language, it's seems to be a way of life...programming life that is. Similar to Protestantism is to Protestants or Communism is to Communist. (No association with LabVIEW implied)

To me, it seems that LabVIEW is ingrained in the LabVIEWist being, it flows in their blood. You cut them and they bleed hemoglobin vi's. (I'm sure the icons are red)

LabVIEWism has a lot of followers that are dedicated to the LabVIEW way of programming, focused on converting us lowly CVI programmers. NI Week is a tribute to LabVIEWism, they inundate everyone with LabVIEW with only a token acknowledgment to CVI.

I don't bleed vi's, or dream graphical code. I still dream in C and preach the virtues the code editor and the power of the command line. LabVIEWism may take over our companies test group, but there will always be holdouts.

LabVIEW...

I have been making a concerted effort to use LabVIEW lately, trying to learn the "Graphical" way of programing. Due to Carpel Tunnel Syndrome I use my left hand to mouse a lot. I've tried the, so called, "Keyboard" shortcuts ("Keyboard" as defined by NI), but since they still involve the mouse, they aren't as helpful as I need them to be.

But continuing to work with the pain, my left hand is just not as dexterous as my right. It's hard to hit the small wire Connections. It's annoying trying to figure out which vi to use for what functions.

Some of the features that would be VERY helpful to get us LabVIEW handicapped people working in LabVIEW is:
- a zoom feature. I could make a vi bigger and actually hit the terminal.
- Or have it where, when I miss hitting a terminal, I can use tab or shift tab to move the connection from the current terminal to the next or previous terminal.
- Have LabVIEW be able to select the end of a wire and then drag it around using the arrow keys instead of the mouse.
- Have the pallet navigable with the arrow and tab keys. Make it where you can select the pallet, then with the arrow and tab keys move about in the pallets to the vi you want. From there, be able to select it and drag and drop with the arrow keys.

Have the LabVIEW developers ever heard about Test Driven Development (TDD) or automated Builds? Here's some more features.
- For automatic builds, have VI's able to be Compiled (or whatever happens to them) from the command line and verified none of them are broken (with the broken arrow for the run button)
- For Test Driven Development, have an automated test frame work. Frame works similar to the NUnit test development suite.

One more suggestion...have a cheaper copy for use by anyone. MS have copies of things like Visual Studio C++ for $100 or so at computer stores.

It's still easier to think in C (LabWindows CVI) than it is in LabView and until I can develop LabVIEW as I can develop C code, I'm sure I'll still be using CVI. But I will always keep trying to learn new stuff.

Now as soon as NI comes up comes up with telepathic programming interface, I'll be there!

Green gone wrong

There's a lot of talk about "Green" and Green Engineering. Everything in going Green...Green, Greener, Greenest. Somewhere out there I'm sure there are Engineering positions with the title "Green Engineer".

As we move into the future, there will be more and more Green Engineers. Scientists will go Green to give the Green Engineers more work to do. Of course, the Green Scientist will become smarter and more powerful. Until one day, the inevitable will happen; There will be a Green Mad Scientist. The Green Mad Scientist will then try to take over the world. The Green Mad Scientists will make Green Monsters that will terrorize humanity, but be good for the environment.

These Green Mad Scientists will start working with Green Artificial Intelligence. The Green Artificial Intelligence will develop more adaptable, more specific, and smarter shades of color Green.

These smart shades of the color Green will become smarter and smarter until, one day...there will be super intelligent shades of the color Green wanting to take over the world.

So beware of Green Engineering and the inevitable super intelligent shades of the color Green.

(With apologizes to Douglas Adams and Tthe Hitchhikers Guide to the Galaxy" and to the Super Intelligent shades of the color Blue. You're super intelligent, but not as super intelligent as the super intelligent shades of the color Green.)

Obligatory mention of NI, LabWindows CVI, Test Engineering, and even LabVIEW. I'll write about you all next week.

NIWeek - Day 1

What a great day! Keynote this morning was very good. CVI information was great! (see end of the blog) NI Rolled out LabVIEW 8.6 with cool new features that even I may use! The auto complete for LabVIEW VI's is nice and keeps you from mousing through the pallets. Of course you have to know the VIs name so those of us who know "Modulo" rather that "Quotient & Remainder" or with DAQmx where some name differences start around the 30th character may still have some trouble.

I went to a LabVIEW FPGA seminar and it's continuing to evolve and getting more and more powerful.

I went to a seminar on Intelligent control because AI is my hobby. It sounds as if LabVIEW may have some Intelligent control vi's coming out. More details to come.

Joel [Garner] and Travis [I-dont-know-his-last-name] put together a get together talking about new FPGA stuff. It's some good information.

But the highlight of my day was CVI. There was a lot of good CVI information between the CVI round table discussions at lunch, the using multi-core seminar, and the CVI Users group. Wendy [Logan] and Luis [Gomes] did a good job of talking about the future of CVI. They emphasized CVI will be around for a long time to come. But then again, most of us have heard that over and over. Plus they have some good, forward thinking plans for CVI. The only down side was the CVI demo, where they were destroying a CD, was flinging shrapnel and so they wouldn't run it live.

Also, you (yes you!) can sign up to get a beta copy of CVI 9.0 by going to ni.com/beta. Wendy only mentioned it at every slide and two or three on times on some slides.

CVI...Learn it...Love it...Live it!

OK, I'm tired and getting a bit little loopy.

NI Week - Day 0

Tonight was the first night of NI Week. Just the meet and greet and get to know the Expo floor. There was only one CVI display, but of course it was great. They were stress testing CD's by spinning them up until it disintegrates which, of course, is cool! It was Good to see Wendy (Logan) again, Queen of LabWindows CVI. She is energetic as always. And CVI is exciting as always.

It was also good to see Santiago Delgado, king of TestStand. He always amazes me. Tonight he was playing the guitar at a LabVIEW sound demo...and he was VERY good.

I did get to go to 6th Street, heard some good music and drank some beer. There were a lot of obvious NIWeek participants out tonight (Nerds). I'm excited about Tuesday, the first full day of NI Week...at least for me.

To everyone not here, your missing some good stuff!

NI Week - LabVIEW-fest

NI Week is getting close and I'm excited. NI Week is a huge LabVIEW-fest, it's almost all about LabVIEW...LabVIEW presentations, demonstrations, and key-notes. I'm still excited about being at NI Week in spite of that. Luckily there are some LabWindows/CVI presentations and, at least last year, there was a CVI section in the NI display. I want to thank Wendy Logan for her work on the CVI stuff. Here's a link to some of the CVI events.

I'm not a huge LabVIEW fan, mainly because of the mouse use and Carpel Tunnel Syndrome. Recently I realized there were other reasons too. I read a book called "In the beginning was the command line" by Neal Stephenson. It talks some about the history of OSs and about controlling the computers. It made me start thinking about how I use computers...not at work but at home. At work, everything is setup for you, you use the OS, tools, etc that work wants you to use.

At home I use Linux (Ubuntu). I like it because if there is a problem, I can look into it, I can figure it out. I can look under the hood...so-to-speak. With LabVIEW, when one of the Vi's doesn't work, or seems to not work, you have to call NI and let them know and they fix it. It's out of my hands. Whatever is under the hood is proprietary, I'm told. You can't just open a Vi with a text editor or compile it from a command line. I can open a file for a C/C++ or Java program, enter it, compile it and run it. Very simple. LabVIEW introduces another layer of abstraction and I just can't see what's below the layer. I've written (in college) a simple C compiler so I understand it, I'm comfortable with it.

LabVIEW is the language of test, the language of the Future, and will be around a long time. You just can see what's under the hood.

NI-Week Seminars

Below are some links to view the NI-Week seminar's along with a message the Conference manager left me on their message board. You can use the links to see what seminar's will be availible.

Now you can start planning your learning experiance at NI-Week. I hope to everyone there!!

------------------------------------------------------------------------------

We are working hard to get the NIWeek Final Program onto ni.com/niweek so you can see all the great activity that will be happening at this year's event. It will be the largest NIWeek ever from a technical content perspective with over 240 sessions from which to select.

Until that PDF is available, here are the links that will allow you to see the content online, register if needed and start to build your personal NIWeek schedule.

If you are not registered for NIWeek and want to see the content that will be presented. Go here to View Sessions. This shows you the content but not the dates, times and locations of each session. Only registrants are able to see that information at the link below.

For registrants, you can now go here to Build a Schedule.

See you in 21 days!
Rod

Apologies

I want to apologize. I haven't been blogging much for a while due to my Mom being, first in the Hospital, and now in a nursing home.

Things are settling into more of a routine so I should be able to blog more, but she does come first.

Thanks

Flexability vs. Usability

I've had some family and work issues lately but I'm going to continue this blog, it makes me thinks about what's important in testing.

Lately I've been working with National Instruments PXI 6229 Multi-function I/O board and NI DAQmx drivers. Using DAQmx has made me think about flexibility versus Usability. First, DAQmx is a departure from the standard method of get a handle to a device and use it. DAQmx functions wants a DAQmx task to be created and used. The task is associated with a set of operations, whether they're Digital I/O, Analog I/O, counter operations, A/D operations, etc. The task is then started and runs however long it takes to complete or how long is specified in one of the many operations setups.

This allows the general DAQmx routines to operate on any type of board. The problem is usability. Not all boards support all operations. A Digital I/O does not support counter or clock operations. Not all operations are as clearly unfit as those. Also, it's not known whether the function will work on the board until the software is run and the function returns an error. The PXI 6229 that allows clocked operations but doesn't have a clock which disallows any "clock" DAQmx functions. (Clock operation require using the counter or an external clock on a PFI line) Things like this are not obvious. Another usability problem is that there are many clock functions and it's hard to tell which one is needed. When trying to operate the [nonexistent] clock on a 6229 it's not clear if the function itself is not usable in the situation or if the board does not support it.

The examples NI provides aren't for all boards. The examples won't run on all boards. Some of the Digital I/O examples won't run on boards with Digital I/O.

Overall, the flexibility the DAQmx functions allow inhibit the usability of the functions. NI needs to apply the KISS principle, Keep It Simple Stupid.

More LabVIEW for more LabWindows programmers

A lot of the resistance to LabVIEW from LabWindows CVI comes down to change and the unfamiliar. At Lockheed, there is a lot of change going on at the moment. Change is not bad as long as there is a goal or reason for the change. But to many changes at one time can overload people. With all the other changes and one of the bosses wanting to change to using LabVIEW is overloading.

LabVIEW is a paradigm shift from structure programming to data flow programing. I'm not sure if I'm on board for the data flow programming paradigm either. However, I believe LabVIEW and LabWindows can co-exists, as I've said before. I'm not entirely sure the boss who wants to switch to LabVIEW believes they can co-exist, it may be one or the other for him.

Also, some people are resistant to change no matter what the reason, change is bad. I can change their minds, I can only provide information to help allow them to change. None of it is easy, but it's not always as hard as it seems.

For me with LabVIEW, there's always the Carpel Tunnel Syndrome that also makes me not want to change, but that's another issue.

LabVIEW for LabWindows Users

I mentioned to a Test People who are LabWindows CVI users about the possibility of going to LabVIEW in the future, I was met with...well...resistance.

I am a LabWindows CVI user and I don't want to move away from it (unless it's to C++ and Measurement Studio or Java). But there are hardware guys who may be better at LabVIEW than LabWindows. I believe that there is room for both. The real programmers can use LabWindows CVI and those programmer wanna-be's can use LabVIEW. Since LabWindows and LabVIEW can both be used with TestStand (yet another NI product) both can be used. Or, through .dll's each can interact with the other.

NI is good at listening to LabWindows users (Thanks Wendy Logan) and implementing new features. Even though the features come to LabWindows about 6 months after LabVIEW gets the features. It was good to hear that NI will back LabWindows in the known future.

Hmmm, when will NI make a Measurement Studio like product for Java? ...or COBOL! Well, maybe not COBOL. Just a thought.

Have a great day!

LabWindows for real programmers

Yesterday, I blogged some about LabWindows CVI is for real programmers. I know that LabVIEW is NI's flagship product most of their other products are in support of other facet's of test, I'm still just not enamored with LabVIEWs data flow paradigm and graphical programming.
Throwing together a LabVIEW program is easy for a novice but that doesn't make them a software developer. There's still not the discipline it takes to program with discipline. It's like someone who goes 90 miles per hour on the highway believing they're a NASCAR driver.

The skill and discipline involved in developing a program is more than taking some icons that represent operations, putting them together, and calling it a program. There still needs to be the analysis on what the user wants (the requirements), some design and thought on how to handle errors, some thought behind the coding so that other non-programmers can understand it and follow the data flow.

LabVIEW is targeted to hardware engineers, guys who understand wires, circuits, and not necessarily good programming practices.

Bottom line is that to program correctly in LabVIEW or LabWindow, there still needs to be discipline needs to be applied to both.