Testing with NI

FIRST Robotics - 3 weeks to go

2010-01-31T14:59:00.000-08:00

Sorry I missed last week, I was OBRE (Overcome By Robotic Events).

FIRST (For Inspiration and Recognition of Science and Technology) The build should be in full swing! If the robot building team hasn't started implementing the design, you need to get to it.

The software team, should have a prioritized list of what they need to implement and be trying to get it going. If you're doing the software, remember that the robot design, how things are going to work are changing. As the robot's being built, they ARE going to change things. Some parts of the design just won't work and so it will change. You need to be flexible and be prepared to throw away code.

The individual functions should be implemented in Sub-Vi's for LabVIEW and subroutines for Java or C++. For instance, the "kick" Functions should be implemented so that the SubVi/Subroutine only does what the robot needs to do to kick the ball.I.e Pull back kicker, release kicker. In the Teleoperated portion of the code, you should detect the button push and call the kick routine. This way, they change the way the kicker works, you only need to go to that function to change it.

This also helps when different groups are working on the code. One group can be incharge of kicking, one incharge of movement, one in charge of the sensors, etc.

One other import fact, and I've said it before, save off your code! when you have something working, save it somewhere so that if mess something up, you can go back to something that works.

Don't be afraid to try stuff in the code, just make sure you can get back to where you were.

Have Fun!

FIRST Robotics - 5 Weeks to Software

2010-01-15T18:44:00.000-08:00

FIRST (For Inspiration and Recognition of Science and Technology) design is in full swing! The first week should have been full of brain storming and starting the design. By this time (the second week) the robot team should be prototyping, figuring out what works and what doesn't. Also all the sensors that need to be on the robot and where they go. The software team should be figuring out how the sensor's, actuators, and motors work. One hint, put all the sensor's you can on the robot, whether your know if you're going to use them or not. It's better that they're on the robot rather than trying to get them on later.

This week the software team needs to make a list of the tasks the robot needs to do. Brainstorm the software requirements. Then they need to be prioritized the list based on what's most important for the robot to do. The list may consist of things like acquiring the target and moving the robot square for a shot at the goal as the top priority.

You need to make sure the software tasks that are highest priority are done first. Things needed for the teleop mode need to be done first since most of the robots time is in teleop mode. Also see what can be used in both autonomous and teleop mode. But don't forget about the software for autonomous.

Before you modify the basic code, make a copy of whatever code is working. Always keep a backup of the latest, working software so that when something gets screwed up, which it always does when you're trying new things, you have code to go back to. When you make a backup, put a date in the backup name so that you know what code was developed when.

Do not be surprised when you have to scrape what you're trying and go back to the last working code. But don't be afraid to try stuff, that how you learn.

After this week you should have a list of prioritized software tasks, and some experiments with sensors, the camera, actuators, and motors going. Basically a plan what your going to do.

Good luck with your project.

FIRST Robotics - 6 weeks to software

2010-01-10T12:41:00.000-08:00

I'm putting off talking about Testing a while and talk about software and robotics.

FIRST (For Inspiration and Recognition of Science and Technology) just announced the competition game for the 2010 FRC (FIRST Robotics Competition). I talked with several Rookie teams at the kick-off and practice build and a lot of them need help, especially with software. I was thinking there needed to be a "FIRST's Beginners guide to a Robotics software in 6 weeks". The reality is the software is usually worked on after the robot has shipped and even during competition.

I have worked with Team 704 (Go Warriors!) for a year and I've been in software since I started learning about software in High School, before FIRST, before PC's. I have my own robots at home (NXT and basic stamp controlled) and have played with them for years.

So on to the important stuff, how to get started with your software for your Robot. After the game is announced (or was announced as of when this was posted), the first thing your team should be doing is brainstorming about what you want the robot to do and the design of the robot. At this stage, the kids/mentors doing the software should be working with everyone else to come up with a design.

However, if you're going to be doing software you should also be looking at the motors, controllers, and sensors. Especially look at how to use the software to retrieve information and control the sensors. How to control the motors and pneumatics. The more you know about them the better you'll be able to use them. You can also speak up during design about what can be used for control and operation.

One of your main resources on the web should be the National Instruments web site. It's full of tutorials, information, help, and has a good technical discussion board. Also, contact the NI sales representative for your area and see how accepting they are to the idea of helping you. They might not be able to help much, but then again, if they can help at a crucial time when you're stuck, it could be key.

You need to work with the kids to figure out which programming language to use. With kids with little or no experience in programming I would suggest using the LabVIEW graphical language, it's drag and drop programming. If you have kids who are experienced in programming, find out what languages they know. If you have a couple kids who have been through a C++ or Java class, you might think about doing your project in one of those languages.

The main thing is to play with the sensors. Get the camera out, make a pattern on a wall of the target and see if you can detect it, lock on it, move it out of focus and back in. Walk between the camera and image and re-acquire.

See how the gyro works, how the accelerometer works, how the limit switches work with, all with your cRio controller. This first week should be learning what the kids know, how the languages are used, and about the sensors and controllers and how they work.

But also be in on the design and thinking of where you need sensor's, what sensor's and controllers you need, and the general build of the Robot.

More Software Architecture and Test Engineering

2010-01-06T17:11:00.000-08:00

Last time I wrote about some challenges doing software architectures in a primarily hardware group of test engineering. First, we need a definition, so here's one that I had laying around in IEEE 1471:

"Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment and the principles guiding its design and evolution"

The software developed in Test Engineering, at least where I work, isn't so formal as to have a definition. However, we still need guidelines of what an architecture is.

Basically, a software architecture defines the structure of the system, the relationship between the major components, the behaviour of the components. It focuses on the significant elements, extending out to the needs of the UUT (Unit Under Test), and takes into account the needs of the systems users.

Since a lot of testing is sequential, the structure is usually fairly simple. For that simple structure just about anything can be used to document it. However, any threading or other processes or interaction with other processors should be included which can cause some complexity in the architecture.

The relationship between the various resources and how they need to be used to test the UUT needs to be diagramed. Sometimes this is straight forward, sometimes there's some complex interactions. Any communications between componants need to be noted.

Also the significant attributes of how user is involved (user interface). Anything that has user interactions.

That's it in a nutshell. The main thing is to let the team know what is being developed on a higher level. Also, to try to let the managers know you've thought about what you're doing.

Software Architecture and Test Engineering

2009-12-28T18:26:00.000-08:00

After a hiatus, I'm back. I broke up with my girl friend which gives me much more time to do the things I enjoy doing and a lot less stress. Robotics, Artificial Intelligence, and my blog. Good nerdy engineering enjoyment.

The Test Engineering group I'm in is made up of mainly hardware people. A lot of them write software, some of them think they can write software, a couple of them really can write software. A software architecture is something required by the process but foreign to them. The bosses, who are mainly hardware types, want to make sure we've thought about the software before we start. Mainly because the hardware guys typically start writing software get to a point where it's a big mess and then patch as well as they can.

In the software past, the software architecture was called the preliminary design. Somewhere along the line someone came up with a paradigm shifting idea to rename it to software architecture. No matter what it's called, it's still just a high level view of the software job at hand.

Almost all of our tests are sequential, simple stimulate and check the UUT. TestStand is our standard test sequencer and we use it very simply, sequential testing with some very minor looping.

It can be a simple functional flow or a simple high level flowchart. We do set of similar tests followed by another set of tests, etc. The architecture is simple, non-complex by real software standards, and straight forward. Almost any thing should be acceptable as an architecture.

Occasionally the architecture will be more complex. Once this happens, then more advanced techniques are needed. More advanced flowcharts or especially UML would be a good candidate. Something to show interactions between different processors and different threads (although, where I work, threads are magic and unknown)

Any of this can prove to the bosses that we have thought about it, the flowchart is what they can understand. The people who are suppose to provide this are agonizing over what to provide and how to do it, taking a lot of time. The good software people are saying to let us know what format you want and we'll give it to you.

This is why we need people who can do software and not just hardware guys who code C. We know how to plan the software.

TestStudio vs. TestStand

2009-09-12T13:10:00.000-07:00

I've been trying to learn about the Teradyne test sequencing product TestStudio. I wanted to compare it with NI's TestStand.

I'm going to say now that there is no comparison, it's not ready. TestStudio locks up so often that it's hard to focus on anything except the problems.

The main problem we're having is when we try to connect DLLs compiled by LabWindows CVI. About every third node (Test Step) that was set up to attach to a DLL would hangup TestStudio. The easier hangups only required TestStudio to be kill (via task manager) and restarted. Occasionally the PC would have to be reboot to continue working in TestStudio.

The Teradyne eknowledge site (the on-line help) was almost non-existent. I'm told by Teradyne that issues submitted by a company can only be see by people from that company. That means people can't see any product problems, issues, fixes, or comments . However, when we entered a problem in there on-line case tracking system, I did very quickly get a call to talk about it. Unfortunately I typically got excuses and that fixes we going to be in up coming versions.

My overall impression on TestStudio is that it's not ready. It's as if its an immature product only tested in on very specific uses. Quality control on the product seems to be left up to the user. The problem is that it's been around since about 2001 and a lot of these kinks should have been worked out.

Bottom line is that if you have a choice, go with TestStand. In my opinon TestStudio is not ready.

Sadness

2009-08-24T20:00:00.000-07:00

I just want to let everyone know my Mother passed away last week from Pancreatic Cancer at the age of 86. She will be missed.

I'll continue my blog next week.

TestStudio vs TestStand

2009-08-13T18:02:00.000-07:00

Teradyne has a software product called TestStudio that is a competitor with National Instruments TestStand. Since I've had my training class inTestStudio so I'm ready to review it. I waited for the training so I would have a better understanding.

I've noted before that the installation was difficult, each individual piece had to be installed separately so it kept me busy. I also had to install an older version of NI-VISA so that TestStudio would install and then re-install the latest.

The training was not very good. It was developed to be used with hardware available, which we don't have yet. This casued the instructor to skip several of the exercises and parts of exercises. A lot of the training material was vague in what you were suppose to do and there were quite a few error's in the material.

The product seemed very immature considering it's been around since at least 2001, possibly longer. During the training TestStudio kept poping up errors. One person had to change computers due to the unknown TestStudio problems. My TestStudio crashed and corrupted my project to the point I had to start over from scratch.

TestStudio is browser-based, of which I am not a big fan. But that is more of a personal preference and was one of the smaller issues. Overall, TestStudio has a lot of small Quirks. Some panels use "OK" buttons to save data, some the "X" in the corner and a few you use the File >> Save. A utility called Express Services, which is big in TestStudio, has to be specified at project creation, however, if a project is created without the Express Services option and it is decided Express Services are needed, you have to start over with a new project. Like many IE based programs, dialogue boxes can get covered up. TestStudio can appear to be closed eventhough it's not really due to a hidden popup. Also, the file browser does not always keep the location of the last browse.

One of the biggest annoyances is that when you add a new node (Test Step) an "are you sure" type of window pops up...every time! No option to not do have it pop-up is available.

Also, when passing parameters to DLL's from nodes (test steps) it is passed as char *. You can't just pass integers, doubles, etc. This limits the direct re-use of DLLs.

TestStudio's big feature appears to be setting up switch matrices between instruments and the UUT. It seems to do well at this but, since we didn't have hardware, we haven't had a chance to check this out.

Bottom line is, TestStudio is a poor second rate competetor to NI's TestStand. It's been around for several years, at least since about 2000, but seems to operate as a buggy and immature product.

Next week, I'm going to review more of TestStudio features (?).

NI Week is here!

2009-08-05T06:06:00.000-07:00

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.

Loading TestStudio

2009-08-01T12:39:00.000-07:00

I've tried to head into the comparison of TestStand and TestStudio with an open mind, be objective, filter out my biases. However, TestStudio has made this hard to do. Before I do a side-by-side comparison, I plan on learning a little about TestStudio.

We received and I loaded the TestStudio software along with some driver software for the hardware we were going to use. Once I began to explore TestStudio I looked in the help file for a Getting Started section, which I found. It was found to be lacking. It had short sentences like “Create One Library tree” but it had no links to how to accomplish this and no descriptions on how to do this. I searched around and figured this step out eventually, I'm pretty sure. But then the next sentence had the same shortcomings, short, to the point, with no "how" to do anything.

I decided to do it the good old fashion way, trial and error. Choose actions from the menu or right-click and choose actions from the list. I found how to create a step for an annoying “beep”...always fun. However, since TestStudio is browser based, I received a script error. I could not find the options menu item in the TestStudio browser, so I went to my Internet Explorer (IE) and Internet options to turn on scripting. Our IT department, in a fit of control and paranoia, had set no scripting and made it where ordinary users could not change it. While I'm not an ordinary user, I'm not going to do anything to my work computer that would get me in trouble...like give myself admin privs.

Luckily the “beep” node went in and worked in spite of the script error. Accomplishment! I decided to try attaching a node to a DLL. I got the same script error, along with a “Teradyne TestStudio DLL addin has encountered a problem and needs to close. We are sorry for the inconvenience.” message and an error pop up message with only a large red X, no text.

I gave up for the moment and was going to try to talk to the Teradyne guys to get some set up help. So I went back to work, fired up TestStand and immediately got a “Could not start” error. It worked last week, I loaded TestStudio, and now it doesn't work.

I had flashbacks to the Microsoft browser wars of the 90's when IE would cripple other browsers. I'm going to continue to learn, continue to try things, and try to continue to have an open mind.

NI Week...Woohoo

2009-07-26T19:33:00.000-07:00

NI Week is almost upon us, it's the time of year to look forward to the new NI products and to network with all the NI people. I'm looking forward to the NI Week. I would be looking forward to all the seminar's and learning opportunities except that this year, some people at the place I work sees no immediate, short term benefit to conferences like this and AutoTestCon. Even in the long term it is hard to show measurable benefit. Since it's mostly secondary benefits, long term learning and networking, that is hard to measure, some groups will be poorly represented.

I am, however, going to to NI Week on an EXPO pass. I am excited about going and I am planning on making the most of my learning opportunities that I will have on my EXPO pass. I want to find out what various vendor's believe is the future of testing. I want to learn about the various products available to help us do our testing, I want to learn all I can...no matter what others think of conferences. I know there are learning opportunities, I know I am going to learn, I know I'm going to learn all I can, and I know it will help me in the future.

Overall, I'm excited about NI Week and all of it's opportunities.

Is Software Engineering relavent to Test Engineering

2009-07-24T07:51:00.000-07:00

I've been trying to get a hold of Teradyne's TestStudio in order to compare it to TestStand. It's been about a month and a half since I've been trying to get a copy. Good news...sort of. I'm told my constant requests may have finially paid off. I'm told, Teradyne finally relented and is going to send us a preliminary copy of TestStudio. It may be in the building, it may be in the mail, so I haven't actually seen it. So, hopefully soon, I can do a comparison.

On to other things...

I've been thinking a lot about where Software Engineering fits into Test Engineering. While I understand the fact that it is an integral part of testing, I've noticed a prevailing thought, at least where I work, that software is secondary and trivial piece of the overall testing practice, "You can get anyone off the street to do the software." (qoute from a manager at work)

This thought was brought about when it seemed like I was the only one trying to get a preliminary copy of TestStudio. The tech lead dealing with getting TestStudio seemed unconcerned on getting the software tools while spending endless hours on getting exactly the right hardware. TestStudio was even picked as a software tool with almost zero input from people who deal mainly with software.

Due to the shrinking of many UUTs, a lot of tests are moving to software. Either the UUT is loaded with an Operational Test Program (OTP) or the UUT only has communications port, test software is becoming more and more important. People need more software expertise rather than less software software expertise.

I'm just frustrated knowing that most of the software decisions are being made by the software inept and I may not have a path up the technical ladder because of my leanings toward software.

If you're reading this, thanks for reading my vent.

Peer Review Tool

2009-07-09T17:34:00.000-07:00

Last year I wrote a blog about Peer Reviews where I noted all the good peer reviews can do...as long as you do them. I believe that, when done properly, they can catch a lot of problems due to a "second pair of eyes" looking at the code. It also gets others at least sort of familiar with your code. That way, if you get hit by a beer truck, it's easier for someone else to pick up the code.

A peer review tool is an essential part of a groups set of tools. While you can keep track of defects on a piece of paper or in a document file, a peer review tool tends to work much better. On that note, SmartBear software has a peer review tool called CodeReviewer.

CodeReviewer - a simpler CodeCollaborator

SmartBear has a code reviewer sale going on, 5 seats of CodeReviewer for $5, follow the link to read more about it.

Yeah, this is sort of an ad, but lines up with my thoughts and beliefs on code reviews, so I'm putting it out there.

May your defects be trivial and you code be solid!

Little about TestStudio

2009-07-06T18:52:00.000-07:00

I had hoped to start comparing TestStudio to TestStand but with all our efforts to actually get a copy of TestStudio or much information about it have been thwarted by the people we're trying to buy it from. All the T's and C's haven't been finished up so we can't get an advanced copy. And, as I've said before, NI and their 30 day trial period pretty much set's the standard.

I could compare the Tech Support...but wait, I'm running into the same problem. We can't get into the e-knowledge until we actually purchaced there product. While I'm not saying the makers of TestStudio has anything to hide, what are they hiding? Again, NI sets the standard of customer support.

While I do understand their need for money, I just don't understand the business model that operates in a way contrary to helping the customer.

I'm just venting my frustration, after all the years of dealing with NI, their support, their mature products, it's frustrating to run into roadblocks like these TestStudio roadblocks.

Comparing TestStudio and TestStand..Not!

2009-06-29T19:45:00.000-07:00

Comparing TestStand and TestStudio at this point is...impossible. At the momment, I'm still waiting on the official PO to go to Teradyne so that they will be so kind as to give us the software we're buying. We have sent them 10% of the PO for long lead items but that isn't enough insurance to actually get the software.

It's starting to wear thin, I just want to learn a little about this monstrosity called TestStudio. I am assuming it is a steaming pile of ... code. Until I actually get to see a copy of it, I'm not going to change my opinion.

Once I get to play with TestStudio I really am going to compare it to TestStand. Okay, I do have one bit of pre-knowledge of TestStudio that I can compare to TestStand. Any parameters passed out of TestStudio to a DLL or other code is only allowed to be passed in Character strings. TestStand does it right and passes the value in the form it needs (i.e. integers, doubles, pointers, etc).

Last week the score was TestStand 2, TestStudio -2. The score is now TestStand 3, TestStudio -3 for TestStands ability to pass parameters correctly and Teradynes unwillingness to allow people who are going to use it to actually use it.

TestStudio, Hmmm...

2009-06-24T17:47:00.000-07:00

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.

Post Robotic relaxation

2009-04-26T15:23:00.000-07:00

Everything is calming down now after the FIRST Championships. I'm trying to capture some lessons learned and keep some thoughts and idea's for next time. If anyone has any fund raising idea's I'd like to hear about them. The money was probably the biggest hurdle.

We, team 704, does have pictures from Atlanta. One thing I'm doing now is buying a new and better camera with stabalization. A lot of my pictures came out fuzzy.

Below are some pictures on the team 704 odyssey that, mostly, I took. Also another link to the Google pic

FIRST Championships

2009-04-18T22:38:00.000-07:00

This has been an exhausting weekend at the FIRST Robotics Championship in Atlanta Georgia. We arrived Wednesday night but it all started early Thursday morning. We got in un-crated the robot. We ran some practice rounds and started scouting teams as well as warming up the Robot.

More fun was on Friday morning...the real thing started...qualifying rounds. We started out strong, three wins in a row. Unfortunately the win streak didn't last. We had some poor luck of the draw, our alliance was with some weaker robots and we were against 3 robots that all wound up in the final rounds. Our alliance lost. We lost one more Friday when two robots were blocking us and our alliance robots weren't coming to help break us loose.

Saturday looked promising at first, at least until we lost our first round...then our second round. There were no good explanations except not much cooperation between alliance teams.

Alas, at the finals team selection, our team number was not called. The race for the Championship was over for us.

It was an exciting weekend. The high school kids had a lot of energy and some of it translated to me. I had a lot of energy...more or less. Over all it was fun and tiring, it's most certainly a labor of love.

Headed for the FIRST Championships!

2009-04-09T17:38:00.000-07:00

Team 704, the SGP Robotics club, is headed from Atlanta GA for the FIRST Robotics Championships! This will be SGP's first trip to the big game!

We have the airplane tickets, another team will be taking some of our equipment to Atlanta in their trailer, and the excitement is mounting. I'm very excited! I contacted the Lockheed Martin internal newsletter about doing a story on the FIRST Championship. It's an event where there are potentially hundreds of future employees!

I was so excited I pulled out my NXT robot and started playing with it. I've also updated my personal web page with the robotics stuff from Dallas and Lone Star tournaments.

Building Robots to take over the world

2009-03-26T18:45:00.000-07:00

I apologize for not writing lately. I've been busy lately working with the South Grand Prairie Robotics team. I tell everyone it's to build robots to take over the world but it's really to build a robot for the FIRST Robotics Challenge.

The FIRST Robotics Challenge is (FRC) is a great organization where high school kids are given a game, a “kit”, and 6 weeks to build a robot to play the game.

The game is called Lunacy. Basically, you try to put your balls in your opponantes trailer. Every robot has a trailer behind it and so while you're trying to dump in someone's trailer, they're trying to dump in someone elses trailer.

The kit is a set of parts to build a basic Robot with enough programming to have a joy stick control it. From there, each team needs to figure out how to dump balls in opponents trailer, what to do in autonomous mode (the first 15 seconds of the match)

FIRST is a national challenge sponsored by a lot of technical companies who will need engineers in the future and want to get the kids interested now. They are a very organized group who have regional robot tournaments in various parts of the country.

The team I'm working with is Team 704, associated with the South Grand Prairie High school Robotics team. Each team, once a number is assigned, keeps that number and the numbers aren't re-used. If a team disbands, the number is no longer used. Team 704 has been going since 2001 sponsored by physics teacher extraordinaire Phil Harris.

I'll write more later. I just want close by saying that high school kids who are even vagually interested in robots should go to usFirst.org and find a team in your area. If you're an adult (who is a kid at heart) you can help mentor a team. (Even though they're using LabVIEW)

Thankful for Family, NI, and Sarcasm

2008-11-25T17:44:00.000-08:00

It's the season to be thankful. So in the spirit of the season I want to say what I'm thankful for.

First, of course, I'm want to thank God for all my blessings. Next, I want to thank my family. My Mom and Dad for giving me a good foundation and work ethic and encouraging me to go to collage in spite of their very limited education. I'm thankful for my kids for keeping me grounded through a bunch of tough years and for putting up with me and my warped sense of humor the rest of the time. And I'm even thankful for my hard driving have-to-be-right brother and sweet sister.

I'm Thankful for my really good friends who helped me get past my shyness, helping with my introversion, and helping me get through my tough years. They are fun to hang out with when I don't have a date. In other words, we always hang out.

I'm also thankful to National Instruments for making it easy to do my job. LabWindows CVI is a great tool for Test Engineers and makes it easy to develop code for test sets and for easy to use hardware. I'm also thankful for all the helpful people I've met and worked with there at NI like Joel, Wendy, Santiago, and Conan. I especially thankful for NI Week and the Wednesday night party they throw, maybe happy they do it than actually "thankful". And, yes, I'm even thankful for LabVIEW, it's a good language and most likely a piece of the future of software.

I'm also thankful to both of the Directors I work for, especially JT. They believe in me and know that I'll work hard to do a good job for both of them.

[Start Sarcastic Voice]
I'm also thankful for the boss who said I couldn't follow a process. Now that I've helped deveop our companies processes and reach CMMI level 5, you proved how well you know people. To the same boss who said I would never work in software at our company again. She was right, I'm not in the software group, I'm Test Engineering doing much more and fun software.

I'm thankful to Electrical Engineers. Since most of you guys don't think I can tell the difference between a resistor and an FPGA, you make it very easy to impress you. Especially, to they lead EE guys who couldn't find the problem between the IMU and GPU on LOSAT. You made it easy for "Just a software guy" to find the 25ns glitch that was reseting the IMU with just a schematic and an OScope.

I'm also thankful to the boss who believes that software is just a passing fad. You make everyone else seem so much smarter.

I'm also thankful to the place I work. [insert almost any sarcastic comment from Dilbert and it applies. I'm pretty sure he works where I work]

[End Sarcastic Voice]

The reality of it is I have a lot to be thankful for and I know that I am truly blessed.

Thank you

NI Help

2008-11-23T06:41:00.000-08:00

Since I work a lot with different instruments and don't have the luxury of completely learning the ins-and-out of one product, I rely on a companies help functions to get my job done.

Lately I've been integrating some Agilent RF equipment into a test set. I now have a much better appreciation of NI help. I've always felt like NI has some of the best technical help around, examples, and documentation but I've come to appreciate it even more.

I'm trying to use TestStand to control an automated test on an RF Signal Generator, RF Power Meter, and an RF Switch, all from Agilent but having trouble. Agilent really is trying to help but still have a really long way to go to get close to NI help. When I had problems I entered a couple of on-line help requests but received no responses. I had to call the local sales rep to get the e-mail of a tech rep. I have been e-mailing him and he has been helpful in a limited way. I did get the manual web sequence to control the RF Switch, but for automated tests, that doesn't mater.

The RF signal generator was easy because I've used it before and figured out it's quirks. The examples for the RF Power meter had nothing to do with actually reading power, hmmm. When I made calls to the driver functions, they came back with error messages that gave no hint at what was needed. The funcion panel help gave no hint at what the parameters were looking for. I wound up using some low level SCPI commands in combination with the driver functions. I couldn't get it to work with all SCPI or all driver functions.

As for the RF Switch, the examples seem to include calls to driver functions for many different switch types. For my RF switch, the driver functions generate a lot of "Not supported" error messages. But it was very hard to figure out what is supported or what calls I could make. Also, once I loaded the Agilent IO Drivers (which are required for the system to even see their switch) the Pickering switches disappeared from the PXI chassis, at least from a logical standpoint. I still haven't figured that one out.

It's been a week and a half trying to get the RF interconnections to work. I think I'm close but compared to the NI instruments, it's taken way to long.

Using Agilent instruments has given me more of an appreciation for how good NI help, discussion boards, phone help, and e-mail help really are. I especially want to thank Joel Garner, NI Sales Engineer extraordinaire, for his help.

Misunderstood

2008-11-09T05:37:00.000-08:00

I've found that the Test Engineering group is misunderstood, at least where I work. Most of the engineering groups have an identity. The Electrical Engineering group builds the hardware, the Mechanical Engineers builds the moving parts, Software Engineers write the software to control the hardware, and the Systems Engineers glue it all together.

It seems what Test Engineering does is a mystery to the other groups. We are called in late in projects because Project Managers don't know why they need us until they realize they need to make more than one widget (or whatever it is they're making). Then they realize their widget (or whatever it is they're building) was designed in a way that makes it incredibly hard to test.

It's too late but that's when they figure out they needed us to begin with.

We're trying to educate the programs on what we can do for them. We can do is:
- We do hardware and we do software.
- We develop systems (Test Systems)
- We can help them design their widget so it can be tested.
- We can make their tests automatic and repeatable.
- We can help with developmental testing
- We can make sure the widget is built correctly
- We can test your system in the field or on the production line

...Bottom line is we can help.

CVI Rules!

2008-10-10T16:03:00.000-07:00

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!

Music and Teams

2008-09-23T17:55:00.000-07:00

I was hanging out at the book store, as I tend to do since they have almost all that is needed in life; Coffee, lots of books to read, and free wifi. Some how, I accidentally wander out of the Computer book section, somehow missed the Science and Engineering section and wound up in the music book section. I browsed a book about Zappa for a while but stumbled a book call "Comfortably Numb: the inside story of Pink Floyd". It's a great book!

There were several points that seemed counter intuitive about teams until you realize that Pink Floyd produced many great albums (for the young people, an album is a vinyl disc that music was recorded on and played on a record player...with a needle) including The Dark side of the Moon, one of the best selling albums of all time.

First point, hiring people based on best team fit is over rated. Sometimes the band members were at each others throats. The point was they were all smart, all creative, and they had the drive to get the job done. They didn't let creative differences or personal difference get in the way of there goal.

Second point, some teams fall apart with dissension between team members, some teams refocus their experiences into creativity. Pink Floyd re-focused into writing great music while software teams can refocus into great software.

Third point, Creative people push themselves, and others, hard. Creative people will push themselves to bring their idea's to the forefront and sometimes will push others to get their idea's out there. They seem to push each other, sometimes in not so nice ways, to get people to complete there own ideas.

Fourth point, don't let technology overwhelm the ideas. This one may be a stretch but it has a good point. With Pink Floyd all the technology behind the shows sometimes got in the way of the music. Today, all the e-mail, IM, blogs, distract us from reaching the goal of developing our ideas.

Overall, the parts that I read were very enjoyable. I'm going to have to go back to the bookstore, hangout some more, and read the book. Or, hey, I could actually buy the book! We'll have to see.

LabVIEWism

2008-09-14T16:38:00.000-07:00

-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...

2008-09-07T18:03:00.000-07:00

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!

2008-08-24T19:39:00.000-07:00

OK, Now that we know the Super Intelligent Shades of the Color Green are going to take over the world, lets get on with less important things... like testing.

I've been working on processes and metrics for developing test sets for quite a while now (a couple of years). I love doing technical work so it has been tough doing mainly documentation. I have worked on some test programs part time while working on the processes, so it hasn't been totally tortuous.

I believe there is always a process of one type or another in developing test stations. The problem is some times the process is the POOMA (Pull Out Of My A**) process or maybe the "wing it" process. But then there's the other end of the process universe. This is where the process makes it nearly impossible to do a small project. Then, in the middle, there's the agile process which is suppose to be the processes that allow tasks to be done quickly and with the ability to easily adapt to changes. It's still not a cure all.

Even people who say they have no process, have a process, it's just not as straight forward as most or even seems coherent.

After working on the processes for a while I know that one process does not fit all projects even though that's what we try to do. I was suppose to document the process we go through to build test stations. Each project has been unique in it's own way, with some process steps that aren't in the process and skipping other steps that are in the process. Some projects that try to follow the process finds that outside groups don't follow the process which makes our process fail. There's many reason's process fail.

If the processes aren't working (not that people just don't want to do it), they need to be adjusted , in real-time rather than going through the year long process change process.

The project leads, the one's actually have to make the process happen, have to be the ones to adjust the process as needed. They need the lead way to adjust it as needed. The Process police also need to understand a single written process is not a panacea, it won't cure all. The processes need to be adjusted.

While I've been working on the processes, this is the dilemma I've been dealing with, having processes that don't imped getting things done but satisfies the Process Police.

Green gone wrong

2008-08-23T09:13:00.000-07:00

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.

What I learned at NIWeek

2008-08-08T10:16:00.000-07:00

While I could say what I learned about FPGAs or LabVIEW I know that's not the most important lesson I learned. On the last day of NIWeek Andrew Hargadon spoke on "Green Entrepreneurship" ...more or less. He really spoke on Innovation but he told NI he would speak on Green so he could get on the stage at NIWeek.

His talk made me think; It made me think about thinking, about using my brain, about getting things moving in an innovative way, not a new way, but a different, better way.

And that's what I like about National Instruments and NIWeek. Not that there's new products that are Smaller, Better, Faster than the older products. It's about innovation, taking things known, re-combining them, and making something better and getting it out there.

I'm not a LabVIEW fan, I may have said that before, but I am a fan of the innovation of LabVIEW. Dr. James Truchard, Jeff Kodosky, and Bill Nowlin combined the computer, programming, and graphics into LabVIEW, an innovative graphical programming product. It's more than just the Test, the Software, or the Hardware aspects of NI, it's the innovation.

To me, innovation is the whole point of NIWeek, the Innovative thoughts behind the new products. NIWeek inspires me to be innovative, combine old things into new, better things. It get's me thinking along different lines, about more than Test, Software, or Hardware, it's about what can be, about more.

The Experience of NIWeek and the products showcased are great. And it's a good way to get everyone together, to network, and focus on test. But, at least to me, it's much bigger than that. NI Week is like Disney world is to a child. Disney World makes kids imagine what could be. And that's me with NIWeek, I'm imagining what can be.

Now I need to move past the kid in me, and move the imagination to innovation. The next step.

NI Week - Day 3

2008-08-07T06:31:00.000-07:00

First, the NI Week block party was great fun last night. The band was great, the food was great, and everyone there had fun. Whomever didn't go, missed out! A lot of the people wound up on 6th street after that. It was a great night!

It's the last day of NIWeek and I'm sad that it's over. I went to the last of the seminars, I always enjoy learning more. I will admit that my mind is getting tired. Or maybe it's from only getting about 5 hours sleep.

Today, I learned some about TestStand, more about FPGAs, and about DAQmx synchronization. I feel good about everything I learned, especially the FPGAs and DAQ information.

The new NI PXIe5673 is a very cool device since you can use it to generate a test GPS signal. We won't need the Spirent thing to generate a GPS tests anymore.

All in all, it was a great week. It was good to see the NI people that I know, especially Wendy and Santiago. It was good to see Luis was still working hard on CVI, keeping it better than LabVIEW.

But now it's good to be home, see the kids, and I look forward to sleeping in my own bed.

I can't wait until NI Week 2009. I'm planning on going even if it's just on an Expo Pass for a day. Remember, it's only 362 days away!

NIWeek - Day 2

2008-08-06T11:08:00.000-07:00

Another day of Fun and Frolic at NIWeek. I'm getting a lot of good information again today, but it's not as good as yesterday because there's no CVI sessions. Somehow I'll survive no CVI today...I think.

The keynote started the morning off really well. My favorite news was that NI allows different OSs to run on separate cores. That means you can have RT running on one core and Windows running a User Interface on the other core.

After that it's all a blur of LabVIEW, FPGA, DAQmx, and some TestStand thrown in. There are a lot of really nice features in LabVIEW FPGA that make it really flexible and usable. I learned some about DAQmx data streaming and I got to hear the TestStand roadmap for the next couple of years.

I really beleive NI is doing a really good job of developing new and innovative products. But I think what NI does best is listening to their customers. They do VERY well at asking what the customer wants and showing the customer what is coming up and asking "Is this something you would use". Of course, half the time, we customers don't know what we would use until we actually get to use it.

"The futures so bright I've got to wear shades" to re-use lyrics from a song. NI should be wearing shades!

NIWeek - Day 1

2008-08-05T12:04:00.000-07:00

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

2008-08-04T22:19:00.000-07:00

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! Nerdvana

2008-08-03T12:31:00.001-07:00

Nerdvana - State of total geekdom.

It's NI Week, I'm in Bastrop with a friend and I'll move over to Austin tomorrow. I'm very excited about the start of NIWeek, I will be in Nerdvana!

Most of my friends think this is nerdy, that I'm excited about going, and it may be. However, it's a great networking and learning opportunity. They go to their industry own conferences and networking opportunities, but "Market-vana" doesn't sound that good. Most of them are in sales and marketing and, to them, everything is a networking opportunity.

NIWeek is a time to live immerse myself in Test, Software, Hardware, and like minded people. A time to become one with Test, a time to reach...

Nerdvana!

NI Week - LabVIEW-fest

2008-07-27T05:57:00.000-07:00

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 - Boondoggle?

2008-07-19T07:45:00.000-07:00

It's about two weeks until NI-Week and I'm excited. However, some at work say it's just a boondoggle (Definition: Boondoggle - To do work of little or no practical value merely to keep or look busy. [Dictionary.com]). They say people go to Seminars just to get out of work, get paid, and goof off. I say that NI-Week (i.e. Seminar's) are what you make of it. You go to learn...you learn. You go to party...you get a hangover. No boondoggle here.

Most of them had a chance to go themselves. However, since we're suppose to report on what we learn from NI-Week, most people chose didn't ask to go.

Last year I went and I learned a lot, not just about NI products, but about how other companies do things, equipment is out there, and what services are available. There was a lot of helpful seminar' on many different subjects.

One problem I had last year was I brought back a lot of good information, but then I was indirectly told to do my job like we've always do it. So is it really a boondoggle if you learn and not allowed to use what you learn? I say no.

At least this year I'll get to report on what I learn whether I get to use it or not.

I'm planning on learning:
- What are the future trends in Test Software Development?
- Trends in shrinking Test Set design.
This is where my learning experience starts, but once I get there my focus may change. I also want use the digital video camera to come up with some good man on the street views on these things.

My goal for this year is to go, learn, come back and teach anyone who will listen. Of course I want to network and have fun, too.

Everyone should go, learn, and have fun.

NI-Week Seminars

2008-07-15T06:14:00.000-07:00

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

Great Engineers

2008-07-06T16:36:00.000-07:00

I've written blogs on how people are the most important tool and I've written on what test people need to know. But as I watch various engineers, not jsut test engineers, there are some who do better than the rest. And some who seem to have potential but can't quite have it all together. I was thinking about some of the characteristics of great engineers (Test or otherwise). Here's what I think.

Great Engineers...

...know what they are doing, they have a reason for doing what they do and they know why things are happening like they are.

...don't believe things "Just Happen" (corollary to the above) They don't feel comfortable with just using instrument, specific electronics, API's or algorithms. They need to know how they really work.

...understand their business and their customers. Great Engineers know what matters for their customers and their business. They can make trade offs that make the most business sense and for their customer.

...put customers and their team first. No task is below a great engineer and no customer is unimportant.

...have the highest integrity and ethics. They care about how they accomplish their tasks. Great engineers care about their team and their customers and keep integraty and ethics in all of their dealings.

...have excellent people skills and communications skills. Great Engineers work well with others, respect others, and communicate clearly and effectively.

...have a wide support network. Great Engineers have contacts and a network to support them and to allow the engineer to be far more effective and become a great engineer.

There are many other aspects like quality, focus, and design skills but I have to stop typing somewhere.

These soft skills differentiate the great engineers from good engineers. I know I have short coming in some of these area's but I also know I am always trying to improve and hopefully become a Great Engineer.

"Know me for who I am, Revere me for how I got here" - Qwezzen

I'm going to NI Week!!

2008-07-02T17:56:00.000-07:00

The company I work for has decided to allow me to go to NI-Week. My boss said that anyone who goes will have to give a presentation on "What I learned at NI-Week". Apparently not many wanted to do that, but I'm more than willing to give a presentation to go to NI-Week.

I've also had some e-mail correspondence with a PR person from NI and she said I could check out a USB video camera to record my experience at NI-Week. It will a video for NI but I'm also going to put some of the video here, so I want to get some good footage. I'm looking for any interesting and unique aspects of NI-Week I can find; Or any interesting or unique people I can get on video.

I would also like to meet anyone who reads this and is at NI-Week for the video, too.

I want encourage everyone who is able to go to NI-Week, at least on the free Expo Pass. It's a great experience! Plus Austin is fun, the music on 6th street is great, and UT is there.

Future ot Test Development

2008-06-29T12:59:00.000-07:00

Since I am a test developer I think a lot about how to make my own job easier. I believe National Instruments is on the right track in the future of test software with LabVIEW. Graphical is very much the way to go, especially for the Hardware guy forced to write software tests. It still has room for improvements especially with the amount of mousing that it requires. I have mild Carpel Tunnel Syndrome but when I use LabVIEW, it flares up and I have pain in my wrist. LabVIEW also easy to leave out a lot of the discipline really needed for software, things like clean code, readability, and documentation. But LabVIEW is still the way.

In the farther future, I believe that the development of hardware and software will be more coupled and much more automated. NI, again, is doing well on this. With NI-Scope, NI-DMM, and NI-Switch. When you get an NI-DMM card, any DMM card, and use NI-DMM to deal with it. All that really needs to be known is the basics of what DMM measurements need to be made. It's all drop in from there.

The more distance test development future should bring more automated and integrated development. I believe the Test Engineer will specify what signals, tolerances, and communications channels needed to be tested for each of the UUTs that are to be tested. A test development (TD) tool will select the best instruments for the job and layout the Interconnect panel (ICP) (The ICP is where all signals from all the instruments come out to the outside world) The Test Engineer would verify the instruments are right.

The TD tool would use the signal to be tested and instrument it chose to create an Integration Test Adapter (ITA) to self test the station. (ITA take the signal from the Instrument through the ICA and routes it to cables, switch cards, and other instruments). The wire lists for the ITA fabrication would come from the tool. From the ITA and wire lists the software for a test set self test would be generated.

Then the tool will take Save Nowthat ICA output and the UUT signal specs that we started with and would develop the ITA and wire list for each UUT test. Using the UUT wire lists and ITA a UUT self tests software and UUT test software would be generated.

The switch cards needed to route the signals for the Station Selftest and UUT tests would be added to the design.

Below is a simple flow I threw together.

This whole thing is conjecture on my part and very over simplified but, in general, seems doable. Overall, eventually, there will most likely be a lot more automation of layout and test.

Future of Test

2008-06-21T11:26:00.000-07:00

One thing that a lot of test engineering companies are doing really well is gathering and analyzing failure data. But in the future the data could be gathered to a central repository and the fault data mined more efficiently, the way some companies data mine for business intelligence. Very likely using some AI techniques to analyze the data. Potentially some type of Neural Net, advanced statistical analysis, and Bayesian mathematics that accepts the failure information and gives the most likely fix. Well, that's what I hope since AI is my hobby. Both test set and Unit Under Tests (UUT) could be analyzed and information about future failures be determined in advanced from current failures.

When a test set or UUT failure occurs the failure information and analysis could be directed to the Test Engineer's pocket PC. He/She would be able to attach to the test set from where ever they are and trouble shoot most problems. Through the remote link some problems would be fixed and some would need to be coordinated with on-site technicians.

As for operating the tests, there could be a central operator planning, scheduling, and controlling all of the tests in a factory. The operator would have the various test screens on his/her screen to interact with the test software. There could be some people on the work floor to make sure everything gets hooked up correctly and the UUT's flow from one manufacture operation to the next.

I do believe wireless and the web will pay a much bigger role in future test. Remote operations will be more common and more advanced failure detection, reporting, and analysis will be the norm.

I also believe that AI will pay a bigger role in test...and not just because it's my hobby.

Future of Test

2008-06-13T13:43:00.000-07:00

At work, I've been dealing with innovation, future of test software, and even doing a little bit of real engineering work in my spare time.

With all this I keep wondering, what is the Future of test set? Of test software? How much will change before I retire? When can I retire (different topic)? Also, I was doing an install of some software and had some time to contemplate the future.

I know in the future the Engineers creed of "Smaller, Better, Faster" will be in effect. Also the concept of Cheaper is being pushed really hard. So what will happen in the future.

Smaller is easy. We've seen it happen for years in standards like VME going to VXI and to PXI as well as chassis like the compactRIO. With these different architectures we've also seen faster speeds. So in the next 10 years I'm sure there will be a sub-compactRIO or RIO-micro.

I'm pretty sure distributed systems will be more common. A system where there is a central control and information repository with connections to small "brick" testers that can be put just about anywhere, temperature chambers, remote less access able test area's. There will be wireless connections where possible so that even wires aren't needed. Some type of Ethernet (hardwire or wireless) will connect to the brick and the brick will control and communication with the units under test (UUT). All test results and operator interface will back at the central computer. The central computer will control several different tests at one time.

There will be more embedded test programs in the units under test (UUT), there will be less discrete interfaces. Since UUTs being tested are getting smaller (better faster) too, there will be less area for interfaces. Software expertise will be needed to develop Operational Test Programs (OTPs) to load into units to test them.

With distributed test systems and smaller test sets there will be more "soft" instrument front panels on the display screens and less physical instrument front panels. The soft instrument front panels on the screens would give an image of what the real instrument front panel would look like if it were real. They would control the various instruments manually when it's needed and would minimize when the device isn't being used. Touch screens would be great for this function so that the operator would still "touch" on the interface.

Of course, all this are just some possibilities for the future.

From Hack to Engineer

2008-06-08T07:28:00.000-07:00

I talked about people being the most important tool of Test Engineering. People are the most important factor in any Engineering discipline. People, Engineers, are the constant though out development. No matter how good or thorough the processes are people still have to implement them. And if the processes are not good the people still have to develop the product.

There are several levels of skill that go along with doing the job of Engineer. A hack (not be be confused with hacker) learns as he goes, acts and then thinks, and cleans up his messes only when he absolutely has to, if he can't pass it on to someone else.

Then theirs the craftsman Engineer. He studies, he plans, uses his best practices and tools and takes pride in his work. But a craftsman is not to the level of Engineer because while, he develops a well crafted product, it lacks predictability and certainty.

Then theirs Engineers. With Engineers it's all about knowing instead of guessing. An Engineer doesn't estimate, he/she calculates. An Engineer doesn't hope, he knows. Estimates can formed based on what they devise. Engineers basically have consistency.

Consistency is what Engineers are about. They still need the hack characteristic of learning as they go and the craftsman characteristic of using best practices and tools.

The best way to get a good product is to have good Engineers working on the product. We also need to encourage and train the hack Engineer to become a Craftsman. We also need to encourage and train the craftsman Engineer to become a real Engineer.

SQA - a necessary evil

2008-06-01T19:50:00.000-07:00

Software quality is not a myth in Test Engineering…although it's not always accomplished. I know that around here it's not always acknowledged that Test Engineering has software so that the SQA people don't bug us to much. I believe that if everyone had a good software discipline, we wouldn't need SQA. The fact of the matter is, even most of the pure software engineers don't have that type of discipline.

If people are not monitored, at least occasionally, they tend to fall into the bad habits as schedules get tight or work loads increases. The code will degrade, maybe not into Chaos, but to at least crappy code. With a police presences (SQA) to keep the crowd of programmers from moving in the dangerous direction, it remains fun and good code is developed. Without over site, the results would be code chaos (or maybe just bad code). With the software police around, we move in the right direction.

Test Software, at least where I work, is not monitored by SQA like it should be. Typically the SQA people, or whomever sets up their budgets, don't budget enough for TE Software. The mission critical flight software gets the attention while test software is left alone.

Test Software needs to follow some standards, meet some criteria, needs to be verified to a certain level of "goodness", just like every other software. The standards are followed when we know someone is making sure we follow the standards.

The test software lead should demand the Software Quality group to do their job for test engineering, like for the other software groups. This is probably a departure from what most test engineer's want, but if the company wants solid software, then it needs to be done. If the SQA can't do the monitoring of the test software then the Test Engineering lead needs to do at least the basic monitoring. I know the lead doesn't have time but it needs to be done. The goal is good solid test software.

Basically, at the very least, the test lead needs to make the following is done:

Code reviews are done and problems found early
Make sure the requirements are met in the design and again in the code
He needs to make sure at least minimal style is met for reuse ability sake and for debugging.
He needs to make sure the code is checked and verified against the requirements.

The lead shouldn't just ask the engineer's “did you do it?”, it's the same as you letting the engineer's police themselves. Then need to be checks. This duty can be delegated as long as whomever it's delegated to knows what to look for.

Again, the goal is good code, the policing the engineers is how to get there.

Peer Reviews

2008-05-28T19:48:00.000-07:00

"Peer reviews are a waste of time", "Peer reviews don't help", "We don't have time to peer review the", peer reviews are evil, blah, blah blah! I've heard this for years and all I can say to this is "Bologna!" A second or third pair of eyes on something is useful. Haven't you ever had a problem while debugging code and said "Hey Bob, can you take a look at this" and then either through your explanation or something Bob says you have an "a-ha" moment can get past the problem? A peer review is like trying to get to the "a-ha" moment before you realize you need to.

Statistics have shown that Peer Reviews do help if they're done right. (see the book “Best Kept Secrets of Peer Code Reviews” by Jason Cohen.

First, some good reasons to do peer reviews. The best reason is defects found early cost less to fix, simple economics. A second pair of eyes can help. Another reason is that less experienced programmers can learn from more experienced programmers at peer reviews. One note is that typically everybody can learn something from other peoples code.

Second, to shoot down some myths. People have a lot of reasons to not do Peer Reviews. Things like "my code is already good enough". To this I have to ask, have you ever had any problems with your code? If you answered No then you are better than any of the Rock Star programmers that I've heard about. Peer reviews are to get rid of problems before they get out.

How about “We don't have time for peer reviews.” Then how much time do you have to fix problems later? And how much will it cost?
Another myth is that peer reviews don't help. They don't help if you don't do them. They don't help if you don't really review the code. If you find just a few defects it can be worth doing it. My Mom and Dad used to say “Anything worth doing is worth doing right”.

There are alway excuses for not doing peer reviews, but no good reasons.
People have ego problems with peer reviews, too. There's the “Big Brother” effect where programmers feel like the peer review is to monitor their every move. This is not how it should be, it should be about removing defects and not about monitoring.

Earlier I said peer reviews help if they're done right. That means the code is really reviewed, the reviewers read over the code and look for potential problems, makes sure it meets the requirements, and is understandable. If this is done then defects are found and fixed. If the code is just glanced over, fewer defects are found, problems are found later and costs more to fix.

To close there are some truisms about Peer Reviews:

1) Hard code has more defects – the more complex the code, the more potential defects.
2) More time yields more defects – The more time spent reviewing the more defects found
3) It's all about the code – Review the code not the programmer
4) The more defects the better – Defects found early are cheaper to fix

The bottom line is a better product and that's what peer reviews should be all about. Happy reviewing!

Technical Debt

2008-05-24T11:34:00.000-07:00

I was browsing around the web and found a interesting concept, Technical Debt. This was a concept brought up by Ward Cunningham in OOPSLA '92. It is being taken over by the Agile people under Agile Project Management . I think it's a good concept for test engineers to take into account, too. The Agile portion and blogs by Steve McConnell (Technical Debt and Technical Debt Decision making) discuss it from a software standpoint. But for test engineers, it can be more than just technical debt in the software. The articles don't go into much detail on exactly what technical deficit is.

Here is what I think. For software some items that would cause technical deficit would be issues:

- Hacked together code or code with a lot of short cuts
- Spaghetti code
- Code that is complex or hard to follow
- Incomplete or inadequate error checking.
- Code to be implemented later
- TBD's or incomplete requirements.
- Poor or Incomplete design
- Anything “owed” to the software that is deferred.

I was contemplating technical debt for the rest of test and hardware can most certainly have technical debt, too. Again, it would be anything owed to the hardware. Some of this would be:

- Incomplete schematics
- Unspecified connectors
- Incomplete grounding or shielding
- Incomplete wire lists
- Incomplete wire specifications where they were needed.
- Again, anything “owed” to the hardware

The mechanical portions could have technical debt as well. It would be things like:

- Incompatible of incomplete layout
- Unspecified mechanical connections,
- Other items that are needed but left unspecified.

(I not as much an expert on hardware or mechanical aspects of test but I'm sure a lot of the hardware people can add to these lists.)

The blogs by Steve McConnell on Technical Debt equate it to financial debt because they have a lot of the same issues. Technical debts, as well as financial debts, have to be taken care of at some point in time or they will bite you in the rear end. If they are not the hardware and mechanical technical debt can be disastrous at integration time or when test operators actually use the equipment. The Software technical debts can come back at anytime, like an unpaid bank loan. Some software debts may bite you at integration time, or worst validation time, or even worse, while the equipment is in use on a production line. To keep it in financial terms, this would be like a bankruptcy. You could get past the technical bankruptcy but your reputation could be ruined for a while.

Also, the hardware technical debts can cause the software have a technical deficit if a hardware debt has to be fixed in software. It's like the hardware defaulting on a technical loan co-signed by the software. This seems to happen quite often.

Overall, when technical debt is taken on, it needs to be taken into account for future releases. If there is to much, it can cause a burden on your future of your tests. If it's not taken care of it could bring everything crashing down, potentially during validation or production.

The scary thing is if you don't realize you're taking on technical debt you have bigger problems and your people need to be trained or replaced.

NI Week - I'll get there some how!

2008-05-20T16:26:00.000-07:00

It's all but official, I'm Not going to NI Week through my company this year. Due to training budgets shrinking and a "one person can train everyone else" philosophy, the company is thinking of only sending one person down to collect information and then let him pass it on to the rest of us. [sarcastic voice] I know how well that always works. [/sarcastic voice]

The reality of it is that I AM going to go on my own, if nothing else on the "Exhibition Only" pass. I live in the Dallas Tx area which is about 3 hours (2 1/2 hours the way I drive) away. I'm planning on leaving one morning, early, with a gallon of coffee in hand, making it there for the opening address that day, seeing the exhibits, then coming back that evening. Simple...right!

I may get a cheap motel and stay one night but I have a while to figure that out.

The bottom line is I'm will be at NI Week, one way or another. This is something I'm passionate about! Even if just for one day. It is an experience that everyone should have. I was fortunate enough to go last year and I'm thankful for that. If I can find the money, I'm going to register for some of the other options, you know, things like food or the sessions for one day. However, as a single Dad with a Son in college and a Daughter about to go to college (UT Austin, near NI), I can't justify much more than the gas for the trip on my own right now.

I would like to blog some more on NI, since I've been pulled off to write processes I haven't had a lot of testing to write about. (In 2009, I'm going to make sure that's not the case!)

I will blog about my road-trip and my experiance at NI Week.

Here's the link to register for NI Week, sign up early. June 1st is the deadline for the Early Bird Special.

The most important tool - Good People

2008-05-16T17:13:00.000-07:00

I've talked about tools that can help people be more efficient and do a better job. But a good software engineer/programmer will beat all the poor programmers with good tools hands down, every time.

A person who has had software classes on “How” to program and what is a good program and not just coding is much better than the guy who has had one or two classes and thinks he's a programmer. NOTE: I do want say that there a many really good programmers who are self-taught, they understand the what, the how, and the intricacies of how. Theses are the code ninjas (without getting into the pirate vs. ninja discussion) These are the guys that you should really find, but I don't know if they would be willing to work in test.

Failing on finding the code ninjas out there and convincing them test software is the place to be, you need the good software people who loves to operate the hardware. I don't agree with programming tests at interviews but I do believe Test Software people need the skills and knowledge of programming in order to do the job right. Even if they are doing both the software and hardware parts of the job. Programming skills should be a requirement to do test software.

Another aspect of the people portion of the job is “can we all get along”. Engineers are notorious for personality quirks. Major problems can happen if a teams quirks don't mesh. In this world of diversity we're all suppose to be accepting of each other. But sometimes, it just doesn't work. Especially if there's a time crunch or big technical hiccup. So, even with diversity, sometimes teams don't work due to personality conflicts. If there is a toxic personality on the team, it can be just as bad as having all bad engineers on the team. (When I hear Diversity I always think of the Dilbert cartoon where someone says “The longer I work here, Di Verse it gets”, say it out load and you'll get it)

The point I want to make sure I get across is that People are really and truly the most important asset, and are more important than all the tools in the world.

NI Week is Coming!!

2008-05-11T15:16:00.000-07:00

NI Week is getting close!

August 5 - 2008

I went to last years NI week, and it was incredible!! It was a very valuable experience. I would love to go to this years but typically the company I work for won't let the same person go to something like this two years in a row. They tend to want to send different people every year. I'm going to try convince them I should go, I guess we'll see how it goes in the next few weeks.

Below is a link to the preliminary program for this year. By the way, a quote from me is on page 27.

View the NIWeek 2008 Preliminary Program

Testing using simulations

2008-05-11T06:51:00.000-07:00

I've written a couple of times on unit test, however, I've heard the old Test Engineers mantra of “our software is different, you can't unit test it!”. I say Bull! I will agree that Test Equipment software is different but if you say “you can't unit test it” then you're lazy, or just don't know much about software.

The main reason TE software is different is because a lot of it runs against hardware, it calls hardware drivers to read information from hardware and control the hardware. It does take work but it's testable. Some situations where you don't have hardware to test with, can't induce all the error's you need to check, or just want a good software product, you need to unit test.

Some common failures that happen during the “Go” path testing are typically checked because they come up during regular development. But not all faults are checked. These off nominal paths are not easily checked with standard UUTs on a test set.

Some tools for more comprehensive testing or fault testing would be:

IVI drivers simulation mode
Other simulations (I.e. DAQmx in MAX with Simulated drivers)
Inserting error data.
Software tool code testing KlocWork

The easiest of these test methods is a Software Tool Code tester, such as KlocWork. This is because, after the tool is set up, you just run it and let it tell you about the potential (or certain) failures. I’m just starting to learn about KlocWork so I don’t know all the specifics at the moment. It appears to be able to capture a lot of the logic and path problems. It goes past the ability of LINT to verify standards and does checks along paths. I’m not sure how it works if you use LabWindows CVI functions or if that’s a non-problem.

Another way of testing is using simulation. Some easily available ways to do this are the simulation features in some IVI drivers, tools such as Agilent''s virtual rack, or with DAQmx and NI's Measurement &Automation Explorer (MAX). I haven't used virtual rack but it sounds like it will simulate instruments as if you were actually running tests with a rack of instruments. I don't know about the setup or operation of the, but the presentation I saw made it look like it could be useful. Virtual Rack IVI drivers

The simulation typically built into IVI drivers allow for instruments to be run in simulation mode. However, a more powerful simulation tool, at least for some NI instruments is the measurement explorer. For NI's DAQmx instruments, you can set up a simulated instrument and the test software operates as usual. The simulated instrument can set up to return various values, as needed. The main problem with this is that if an instrument is simulated using measurement explorer you have to go back to the measurement explorer to check it. In other words someone could take out a card and simulated an the software wouldn't know.

One brute force method of simulation is to comment out the call to and instrument driver and just set the return variable to a value. Without some software discipline, this can be dangerous. If one of these is left in the code then test won't return a valid answer. If this method is employed either a comment tag (I usually use //JAV) should be put in where the test is or a compiler directive should be used, like an #ifdef. I typically use this during developmental testing but I always make sure that, before the end of the day, all of these are out so that I don't forget about it before the next day.

My main point is to use tools that are readily available to make sure you put out the best product possible.

Code and Unit Testing

2008-05-01T15:53:00.000-07:00

Last time I talked about Unit Testing or external types of test. Now some thoughts on internal testing.

IDEs (Integrated Development Environments) using basic debugging techniques (i.e. single step, view variables, break points, etc) are the front line of internal testing. They give developers insight in to what's going on in a program. A program is run, it doesn't work, you debug. But there are other ways, more powerful ways, of doing debugging internal to a module that aren't as time consuming.

First, there is an ASSERT statement in most C/C++ languages. In NI's CVI in the toolbox it is a DoAssert statement (include toolbox.h to use this). The DoAssert statement is used to help find problems during development that don't happen that often. Basically, it is a condition passed to the DoAssert (Eample: i>1) and if the condition evaluates to TRUE, execution continues. If the statement evaluates to FALSE, module information is printed and execution stops. It prints out the module name a number like the line number (remember __LINE__ is the current line number in the program) and a message, typically with some debug information.

I use ASSERT or DoAssert (CVI) to check for out of tolerance conditions that happen once in a blue moon (good 'ol southern saying that means “not very often”).

Another way of internal testing is to do logging. Some people only use logging as a last resort after problems are found but I advocate putting in logging as your coding, putting log statements in at potential problem spots. Compiler directives can control whether the logging is executed or not. (#ifdef and #endif)

I have some logging routines laying around that I always use. They use the vaprintf style of functions so the logging is more like a printf statement in C. The LogOpen function is called at the start that opens the log file. A LogClose function is called at the end to stop the logging. It does I/O during execution by flushing the buffer every time the LogData is called but that can be controlled with compiler directives. The flush can be turned off if you don't want the I/O delays.

And, like I started with, there is always the standard debugging tools. These are just a couple of ways to do debugging internal to the module. I just want people to step out of their little box and think “How can I make my code better?” and “What can I do to keep from giving incorrect results or give errors?”

Code and Unit Test

2008-04-27T04:57:00.000-07:00

One thing I've noticed is that many test engineers, for coding and design, just hack something together so it can be thrown onto the test set. Sometimes it’s because of schedule pressure, sometimes it just more fun to touch hardware, sometimes it’s because it’s EE’s doing the coding with only one software class worth of training. In any case, this has got to stop!

Test Engineers (TE) doing software need to have some software discipline. They don’t need the same discipline as tactical or man-rated software development needs, but Test Engineers do need software discipline none the less. TE's need to do some unit testing, some stress testing, some fault path testing, Diagnostics levels, some issue like that.

Many TEs use the excuses of “our software is different” or “Our software is to hardware intensive” to avoid code testing. I say any 10 year old can give excuses, what about results? What is the quality of your software?

As I see it there are two basic types of software testing, internal testing and external testing testing.

First the external testing or unit testing. In the software world there is quite often a test group. The software developers develop software and throw it over the wall to testers. In the Test Engineering world, there's not always that luxury. That's the reason to have software self discipline. There's more to external testing but for now I'm limiting myself to unit testing.

Definition: Unit Test is the testing of a module or a logically grouped set of modules where inputs and outputs, limits, stress, path test occurs.

To test a unit(s) it can be as simple as a function calling the unit(s) being tested over and over with various inputs and then checking the output. If NI's TestStand is in use then a sequence is set up to call the module(s) under test and the output checked.

One tool that I use quite often is called CUnit. It's a unit testing framework and there is a whole range of _Unit type of frameworks. JUnit for Java, CPPUnit for C++, xUnit for MS Visual stuff (I.e. NI Measurement Studio) and some others I can't think of right now. A lot of this can be found at SourceForge.org, a great source of open source software.

Since test software is quite often hardware intensive, sometimes some hardware simulation is needed, and I use the word “simulation” in the weakest form. It's as simple as creating a dummy routine to replace the hardware instrument driver that returns the data you want to test with. I.e. good data, erroneous data, stressed data, etc.

To test, the driver routine would call the module being tested. The module being tested calls the driver simulation which returns a predetermined set of results which allows the module being tested to return a predetermined result. If the returned result is really what you expect, the test worked. Otherwise, the module needs to be fixed.

Overall, the point I'm making is not to hack something out and throw it on the hardware. There are options, whether you've thought of them or not. By The Way, this isn't a comprehensive list of ways to unit test. Use your imagination, I know you have one, you're an Engineer!

I just want people to step out of their little box and think “How can I make my code better?” and “What can I do to keep from giving incorrect results or give errors?”

Note: Some of these test methods are the part of Agile development called TDD, Test Driven Development (TDD). It just means your code should be driven by the tests. I didn't want to scare anyone with the word "Agile."

Zephyr - test management tool

2008-04-18T16:08:00.000-07:00

Yea, this blog is about testing, usually about NI stuff, but competition is good for us all. Saying that, someone e-mailed me about a test management system called Zephyr. I read about it and it sounds like it has a lot of potential.

Zephyr is a complete test management system. It has collaboration tools, customizable dashboards for instant status, Test Desktops, with built in metrics, and test execution capability with defect tracking.

You can read about it's list of product features here and see an overview video here. There's also a limit person trial version here. It has some very good looking interfaces.

I have only read about the product and have not tried it out but it sounded like it had some very useful features. Since I have not actually used it I can only give you my impressions. Some things I liked were:

- Central repository for documents or at least links to the documents.
- Test/QA/Management Collaboration
- Instant update of test status
- It sounds like it was for Agile development with all the communication and collaboration, but I'm sure it can be used for any type of development.

The ability to manage widely distributed test systems is impressive and massively useful.

A couple of big questions, at least for me.

One, how well it plays with TestStand and other NI products. NI is the big dog on the block for test software and electronic, at least at Lockheed and to get a foothold it would need to complement our NI abilities.

Two, We have a lot of legacy code and equipment from NI that we don't want to lose. Since our previous tests cases are in TestStand written in CVI or LabVIEW, how well you can re-use your old tests? How well will it interact with the legacy code?

I'm probably download and try out the trial version but it would be in my spare time. Unfortunately, that wouldn't be until the end of the year.

All-in-all Zephyr looks like it has potential and I would like to hear from anyone who tries it.

Apologies

2008-04-18T07:38:00.000-07:00

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

Design Tools

2008-03-26T20:05:00.000-07:00

From what I've seen, test engineers don't always do a good job of designing software. They just sort of code away until it's done. And if there is any complexity to the design, they code even harder until it's done. Not a lot of real design is done.

There are a lot of simple design methods that can be done for a better test set. Just a simple flow chart to layout the design is good at a minimum. Something like MS Visio or any drawing program can used.

Another design tool is to do what is called swim lane charts. This is where each separate item (i.e. UUT, Test Set, Other Computer) gets a lane and every time something is required of that item, communication to or from that item, some process/decision/operation block is put in that lane. It shows the interaction between each of the different items and the operation each item does.

UML is another design tool, especially when doing object orienting programming. I read about UML but not done design with it so I don't have a good grasp of it. I know it's a way of displaying objects and showing the interaction between them. The software engineers tend to use UML for their designs.

State diagrams are also really useful for showing transitions between states.

My main thought on all of this is don't just code away with little or no fore thought. Use your tools for a better test set software design, it will work better in the long run and be more maintainable.

Test and a lack of understanding of software.

2008-03-17T17:58:00.000-07:00

“Software is a necessary evil”, a statement I’ve heard several times made by a test engineering manager. Other of my favorite statements by managers are “Test development is the development of hardware…and then you do software” and “We have no software problems” as everyone developing software laughs or shakes their head.

It’s absurd to think of test development in one dimension, the hardware dimension. If you’re involved with CMMI, Processes, etc. you’ll know that it all started with problems with software, or the mis-understanding of software and it's development. Manager’s didn’t know how software worked, or what it takes to develop it. Software practitioners were just “winging it” and learning by tribal knowledge. Projects were brought down by software problems.

Test engineers developing software for ATE need to at least come into 90’s and develop software using at least some standard software engineering approaches. Simple things such as keeping the requirements. Test requirements very often involve hardware and software and not exclusively one or the other. That’s fine, you still need to understand the software portion of the requirement.

The requirements need to be understood and traced up to any other higher requirement or derived requirement of something in the UUT that is required to test. This can be done in a tool, such as requisite pro or DOORS, or in an Excel spreadsheet. But you need to know what you’re testing.

Other tools that can help is a tool called Requirements Gateway by NI. I haven't used it personally, but it seems like a useful tool.

More test tool stuff to come

Test Engneers

2008-03-10T18:53:00.000-07:00

Most people dealing with Automated Test Equipment (ATE) call themselves “test engineer’s” (TE) or test people. However, since there is typically no degree’s in test engineering, they get degrees in Electrical engineering or software engineering or computer science and engineering and then are recruited in the “test group”. I’ve seen most TE’s come out of the group with EE degrees, a lot of SW Engineers don’t like to touch hardware. But then a lot of EE’s feel that doing software makes them dirty or is FM (Freaking Magic) and only took minimal, how to code classes in college.

Since most TE’s are out of EE the software portion of ATE is “hacked” out (the old-school meaning of hack, to bang out code until it works) the code is less than optimal. In other-words, it works for the normal case and little else.

Some people who have software degrees or have been doing software for a long time work toward having more software discipline in there ATE code, but it still tends to be lacking in most area’s. Software tools tend to go unused or limited use, some believe an IDE is all that is needed.

There’s more to developing software than just an IDE and some time. Tools are available to help develop code. I think software tools aren’t used in test due to a lack of understanding, lack of knowledge, and lack of patience.

Time to come into the 90s

2008-03-02T13:13:00.000-08:00

I apologize for not writing in a long time. I've had family illnesses, Mom going into nursing home and all the financial items that come along with that...things like that. It's not an excuse, it's part of life. I asked myself, what is important to me...there was no contest, it was family.

While real-life has gone on personally, work-life has continued, too, since I like to eat and live indoors. One of my biggest pet-peeves that has been affecting me is people are stuck in "the way we've always done it." It's really just fear, the new way of doing things may affect their job, may affect the bottom line, they may not really understand new ways of doing things.

Have you ever thought where we'd be without evolution? Whether you believe in Creation or Evolution (I personally believe in Creation but we Evolved from there) businesses, business practices, business methods evolve. That's why some business that don't change with the times die-off (ex. Braniff air-lines and Remington Rand Typewriter company) and others change, evolve and continue to thrive (IBM and Harley Davidson Motorcycle company). People in all businesses need to learn to change and evolve or die off. People within the business need to evolve to keep the businesses evolving.

The people who are stuck in the 70s and 80s need to come into the 90s or their businesses will stay in the 70s and 80s. They need to change but I wouldn't want to push them to fast by trying to get them to come into the 2000s.
They need to evolve, try to get up to date in their thinking,

New ideas need to be tried, at least ideas like Object Oriented Programing (OK, that's not new but it is to them), Agile programming, using ASICs and FPGAs. At least get past vacuum tubes and transistors. All this is not magic, it's just evolution, or coming into the 90s from whatever decade you're stuck in.

It is a disservice to the people who work for the less evolved, too. If you want to compete in this world you at least need to be involved in this world.

I don't know how to get these people up to date, or even close to up to date, but for the businesses sake and their sake, it needs to happen.

Good Enough for DAQmx

2007-12-02T12:50:00.000-08:00

Define good enough software. It's a very subjective answer, what's good for th developer may be no good for the customer, even though it was eloquently implemented. What's good for the customer may not be good for the developer, it's what the customer wants even though the developer had to use practices he/she tries to avoid.

Saying that, I've been trying to use National Instrument DAQmx software. As a customer of NI I have to think it's good for the developer. It's probably eloquently implemented, a mastery of object use, and development style. It's probably great if you use it all the time and learn it's idiosyncrasies. But, as a part time user, it's not that great.

My problem with it is they tried to cram all operations for several different classes of devices (I.e Digial I/O, Counter/Timers, A/D, etc) into one set of drivers. Some functions have nothing to do with some boards. You can call a function to start a clock on a board when the board has no clock. You can't tell until the function is run.

The DAQmx function set is so feature rich that it will do almost everything for you except wash the dishes. But in order to Read 1 bit off a Digital I/O board it takes at least 4 calls although I did it (accidentally) in 5 with no complaints from the system. I think it's because I had to set up the clock I didn't use for the operation. The main function that actually does the work of reading the bit takes 8 parameters (I think, after about 5 parameters I usually get tired of counting) and I really only use 3 of the parameters.

I'm sure there was some elegant programing involved, but I don't see it as I'm struggling figure out how to read a bit.

Without testing, how can you be sure?

2007-11-23T16:33:00.000-08:00

There's a lot of questions about "Is testing really needed". By the way, the correct answer is Yes. It seems that during development most developers say they'll develop the tests for their own equipment. This will ensure the unit won't be tested well.

Developers don't necessarily design for testability. Quite often they design connector's that can't be mated to easily, circuit cards that are embedded into the system to where they can't easily be tested, or circuit cards that just hard to deal with.

Designers know what parts of their design is weak and typically test in a way that their circuit will pass. Not consciously, but more of a sub-conscious because they don't want to see their baby fail. Or testing to what is designed and not in a way to truly verify the design.

I say testers are needed and need to be brought in early if they are to be able to help. Also, since quite often management don't see proper testing as a necessity, the test budget and schedule is shorted or cut to the bone. This will hamper the the testing effort and typically cause shotty testing of a unit.

If shotty or only partial testing is desired before sending a unit out to a customer, bring testers in late, or not at all. If you want to ensure the customer is satisfied, bring in the testers early and let them make sure a good job is done.

Software in Testing

2007-10-28T14:07:00.000-07:00

Even in testing, you have to pay attention to software. It's part of the test development knowledge base. The old paradigm of "Software's free" needs to be left in the dust. If it's ignored or the attitude of you design the hardware and plan the test...oh yeah, just do the software needs to be left behind and you need to move forward into the 90's (yes, the 1990's). If you ignore the software, you'll pay in the long run.

I say this because this is the attitude from a test manager. He said there were no software problems with the test sets at his site. Everyone had a good laugh but I think he was serious.

Even in Test Engineering people need to continuously improve your software skills. If you're a hardware guy who had 1 software class you need to try to improve. If you're a degree in Software Engineering and have been developing software for 15 years there's still room to learn new software techniques.

If the software is poorly written the tests will be hard to maintain or possibly won't work properly. Without the proper software discipline the overall testing process won't go smoothly. As you move through the test development process, things will be rocky, problems will occur, and it will take to long to fix the problems. Software is one of the corner stones of testing.

So don't ignore it or it will come back to bite you.

What is a "Test" Person

2007-10-27T06:22:00.000-07:00

Lately, I've been thinking about what exactly is a "Test" person...or more to the point a good test person. Someone who is good at testing needs to have multiple skills, good at each but not necessarily an expert in them. The skills needed are Software Engineering, Electrical Engineering, and Systems Engineering. The good test person needs to be good at Software because software drives the test. With tools such as TestStand, NI is trying to make software easier, when in actuality they're trying to make people who don't do software think they can. But if you do software poorly, the tests developed don't work well.

Electrical Engineering skills are needed because that's what is tested and the interfaces need to be understood. Also, the Unit Under Test (UUT) has to be understood well enough to know it's being tested throughly.

Systems are needed to tie the tests together and to understand how the UUT fits into the rest of the system so it can be tested.

A good tester has qualities of each and most are very good in one area and adequate in the others.

I was pondering this as I was trying to understand a test, in TestStand, where the developer used a lot of nifty TestStand features that just made the test harder to follow and understand what was really going on. I think the person who wrote it understood Systems really well, knew hardware well enough to use it, and knew a lot of the details of software without being that good at developing software that will need to be maintained by others.

Testing is Tricky Business

2007-10-24T14:19:00.000-07:00

Actually, testing can tricky if your customer doesn't know what they want. You can't base real requirements on "Test this!". You say OK, you look at all the inputs and outputs and test them, you test the circuits behind the interfaces as best as possible. You even tell them in advance what you're going to test, they say "that looks good" (you keep all the e-mail transactions) .

You go to the test set sell off and you get the conversation "That's not what we wanted". "Well...What did you want", "I don't know, but when I see it, I'll know it". That's not how it really goes because after the "That's not what we wanted" you start cussing (in your head) and discussing what they signed up for and what they say they signed up for.

Again, this is the need for the good requirements up front so that they understand what they will be getting and you understand what they want.

Recent experiences have shown that the above discussion happens more in testing than the good requirements.

Good luck on getting through the cussing and discussing part. It's never easy.

Flexability vs. Usability

2007-09-26T02:47:00.000-07:00

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.

The test development environment

2007-09-13T16:56:00.000-07:00

This is less about computer development environment and more about physical development environment. In the past I've been in the unfortunate situation of going off-site to develop. It went slow and I got phyically sick at least once a week. This situation is about to happen again.

I bring this up because a test set we are working on is being sent to the customer's site. In the earlier parts of the contract the tests will be developed here. Due to the lateness of the UUT's being developed, the test development process will be moved to their site, where the UUTs will be. They originally promised to send UUT's for us to verify our tests in April 2007 but changed the agreement, rather ignored the agreement and changed what we had to do. That meant the we have to send a test set up to there site and the use their UUT's. The same UUT's that their engineers will be using at the same time we would like use them. Or maybe we have the midnight to 6am shift to use the UUT's.

This winds up putting all the pressure on us. We're in a strange place working the test set. If we need technician help we have to find one of there technicians to help us. Same with tools, seating, and, most of all, UUT's. We will be at their mercy on when we can use the UUT's and guess who will be at the bottom of the priority list for use of the UUTs. (answer: us)

The only good thing about this situation is we will have at least some access to the UUT's to complete our test verification. Nothing else is good about it. We'll be out of our environment, staying in hotels, away from family, and eating out all the time. It gets old quick.

As for me, I'm only going up there occasionally, I can get my stuff done down here. Since I'm a single dad, it would be tough for me to go up there for 3 months like some of the others.

Have a great day

NI and Education

2007-09-04T17:09:00.000-07:00

I'm currently involved with the Grand Prairie Independent School District (ISD) to help develop academic programs for a Technical High School currently being planned and built. When we started I found out, to my dismay, that GPISD only had a simple Intro to Engineering class. They do have a programming class under the area of business and an electronics class under science. But nothing to lead people into engineering. I was appalled at the lack of Engineering curriculum.

Now, I'm interested in helping them get some engineering programs in place for the new technical high school. I was looking at what academic information NI has. They have an NI Academic area on there website. It is mainly LabVIEW based academics...as if that were a surprise.

They also have NI ELVIS which a LabVIEW based electronic is an integrated design and prototyping platform for engineering and science laboratories to teach concepts in measurements, circuits, controls, microcontroller, and embedded design. It is a bit pricey for high schools and I think targeted to colleges.

Hopefully, the GPISD can afford to put in place a good engineering program. Whether they can afford NI or not is yet to be seen.

Project lead the way is a good, somewhat canned engineering curriculum. There are other school districts that use Project Lead the way and GPISD will probably follow suite.

Well, have a good day.

Requirements help from NI

2007-09-02T13:06:00.000-07:00

NI has a product I'm looking at right now. It's called NI Requirements Gateway and it's to help keep track of requirements. It won't help deal with poorly written requirements like "The user interface shall be easy to use by anyone". It will help you track the requirements from the requirements document to the code. Whether the requirements are simply documented in MS Word or MS Excel, or kept in a requirements database like DOORS or Requisite Pro.

I'm dealing with requirements written in MS Word. Specialized MS Word tags (similar to tags like Heading 1) can be put in the requirements document. Then the complimentary tags can be placed in TestStand and down in the code called by the sequence step. NI Requirements Gateway then extracts the tags and follow them down to the code. I know it works with TestStand, LabWindows, and LabVIEW. All NI Products, and figuring NI is doing what they do, I bet it can flow down into other languages, like .dlls built in C++, though I'm not sure about that.

It can come up with a requirements traceability matrix, a table to easily trace the requirements from the document, to the code. It assumes the requirements are specific and not vague, general requirements like the one above. But for real requirement it helps prove the requirement was implemented.

Happy Requirements tracing.

Requirements are Required

2007-08-29T17:18:00.000-07:00

Test Requirements are required for proper testing. The project I'm currently on, more or less, have requirements. I say more or less because there are requirements written down, but they're not signed off. I, as a sub-contractor, and I'm trying to follow the requirements as written, even though it's not signed off.

Today I was working with the contractor, going over the user interface. Some questions came up about how the operator interface worked, he wanted things done differently. At one point I pointed out that I did it according to the requirements. The contractor I was showing it to said "I don't care what that [the requirements] says, I want it like this."

To change something they want is not the problem, it's the fact that it's written one way and going to be implemented a different way. We could held accountable later for not implimenting the requirements correctly.

I'm not an anal retentive person, I'm probably more loosy-goosey, but I also want to protect my self. I've been in the situation where a boss told me to do things one way instead of the way the documentation explained it. Later, the same boss called me out in a meeting on doing it incorrectly. Since then, I do it the way the documentation says and if someone wants it done differently, then change the documentation. That's when I'll change it.

Basically, to protect yourself, write down what's wanted (requirements), agree to them, then follow them. If someone wants changes, change the documentation, agree on cost and schedule, and then implement the changes.

Bottom line, CYA!

"We've always done it that way" - argh

2007-08-28T16:36:00.000-07:00

That is one statement that has always bugged me. National Instruments (NI) is cutting edge, forward thinking, and a has an overall good product. Now, mix doing testing the same old way and modern technology. What does that leave you? A good overall mess, but at least it's eas to develop.

Sometimes, contractors will layout requirements for products, like User Interfaces (UI), the way they've always laid them out. And no matter what arguments you use, the want what they want.

NI makes their products very flexible. The good and bad is that it makes it easy to develop a cumbersome, less flexible UI for stubborn customers.

UI's should be independent of the UUTs to be tested or test sequences run. They should allow the tester to add new test sequences and remove old test sequences without changing the UI. NI makes developing UIs with this philosophy easy. However, UIs that are heavily integrated with the test sequences can also be easily developed. While this is good for future work and continued employment, it's not good adding or removing new tests.

But we all do what we need to do to get the job we're given done. So thanks to NI, we can easily develop inflexible projects as well as flexible projects.

Have a great day.

More On Fault Insertion

2007-08-27T18:02:00.000-07:00

How about "Fault Insertion, More On". In the past I've seen two different attitudes on fault insertion. The first test engineer was diligent at inserting and verifying faults he inserted. It took a while but, and the test lead, has confidence that if there are faults in a UUT, the test sequence will catch them and report them correctly.

Another test engineer, said he didn't have time to insert and verify faults because he had to get his test running. I thought making sure your test would catch faults was part of getting the tests running. Very recently, a fault was put into his testing (I probably shouldn't have pulled the break out box shorting plug) and I noticed it wasn't caught. He just got annoyed that someone was messing with his test.

Another time, his test crashed instead of catching a UUT error. When I say crashed I mean his code had a fatal error and could not continue. He just said "That shouldn't happen". He fixed the UUT so that it didn't cause the error (a broken wire in a cable) and didn't fix the error.

So, which tester do you think was embarrassed at sell off time with quality assurance there, watching, keeping track of problems. So who do you think was the Fault Insertion More On?

Fault Insertion Testing

2007-08-26T16:12:00.000-07:00

I don't understand why test engineers only want to test the Go path, the path that gives you that nice green "PASS" screen, if you're using NI TestStand. I will admit the "green screen of goodness" does give you that good feeling. However, testing doesn't always get the Pass screen, sometimes Units Under Test (UUT) fail. Test engineers need to make sure these failures can be caught. That means when running their code, test engineers need to insert faults.

I've heard to many engineers they don't have time for fault insertion, "it takes to long", "I don't know how", "I can't". Blah, Blah, Blah. Think about the cost and embarrassment when a UUT gets through. Sometimes faults aren't thought of because they're in the future so they'll be verified later. Typically they're forgotten about after that.

The only faults that should not be inserted and verified to be caught are if the fault insertion could damage the UUT or the Test Equipment. Any other faults should be open for testing.

There are ways to insert almost every fault when you're testing a UUT. Some easy, some hard. Any fault that has a high probability of happening or a fault that can cause major problems needs to be verified that it can be caught. Sometimes it can be as simple as pulling a plug from a break out box, sometimes you have to get more creative.

Once, in order verify I could catch communications fault over a channel I had no control over, I temporarily added a function to the communications driver that allowed me to add errors to in coming messages. While this was not allowable in the final test configuration (no extraneous code in the final version) it did allow me to insert error's in order to verify my code.

Not enough people have the imagination to come up with ways to verify their test code works. They write and just assume it will work. This is a huge mistake made by many test engineers and not caught until the they're in front of the customer.

I was thinking about this because I was going to use a test set (the test engineer wasn't in the room) and disconnected the cable between the test set and the UUT. It was then I noticed a test was running and about half the tests were still passing. They shouldn't have been passing. Apparently there wasn't enough fault insertion done.

Getting test people into the 90's

2007-08-22T18:18:00.000-07:00

I was speaking with someone about the future of test and where it is going. Many test sets being used have the older, larger, VXI technology. Some test sets, not many around Lockheed, are still manual, where points are manually checked for continuity/voltage whatever.

When the older technology test sets are rebuilt with the same old technology, they are more expensive to maintain, the instruments are harder to get a hold of. Technology continually moves forward. I've noticed some test people want to stick to the old ways, old technology, unchanging. Technology, people, test, need to move forward. As Units Under Test (UUT) get more sophisticated and smaller, better, faster, Test Equipment must also get more sophisticated, shrink, and faster.

Attitudes to test developers also need to change and get more sophisticated. People need to understand better ways of testing, more sophisticated ways, ways that haven't been tried before. They need to have better understanding of what's being tested and why. Basically people need to change, learn, grow. Those who don't, will be stuck in the 90's, testing things that are simple to test because that's all they know.

Test people need to move into the into the 2000's and beyond. A few are moving forward and growing. A lot, possible most where I work, don't seem to be moving forward, seem to be of the mind of "we've always done it this way".

We need to keep moving...or be left behind.

NI Week residuals

2007-08-21T16:49:00.000-07:00

NI week was awesome, a great learning experience. It made me think more about LabVIEW for work. I found out today that another guy at work, who was less of a supporter of LabVIEW than me, was thinking of LabVIEW as something that can be used at work.

I think of LabVIEW of more viable of a product in more area's at work than before. It's something that can be mixed with LabWindows. Both can be used in places to meet the goals of product testing.

Now, I need to work on learning LabVIEW a little better so I can understand the best ways to use it to achieve my goals, a better test product. It has some really good aspects already that I haven't fully explored. LabVIEW FPGA (I'm still hoping for LabWindows CVI for FPGA) and LabVIEW for Lego mindstorms.

I'm embarking on my LabVIEW journey, starting with mindstorms since I can download a free student version that interacts with the NXT brick.

NI is Grea...eeh,it's Sunday

2007-08-19T14:31:00.000-07:00

It's Sunday and NI is a work product so even though I want to blog about NI, that's to much like work.

So I'm going to blog some about some of my hobbies and how they may relate to NI. Today, after Church, I was playing with my Genetic Algorithms (GA). I was moving it from C++ to Java, partially to to learn Java and partially to get away from MS Visual Studio. I started working on using GA to beat the stock market after my Neural Net work didn't beat gains made in some of Mutual Funds.

I continue to look at Neural Networks because they intrigue me. They have so much potential, but I need to work on it some to beat the stock market. However, I heard that one of the big mutual fund companies was using GA to help with their mutual funds.

I was thinking that the Neural Networks would be good in LabVIEW. Some of the math may be hard but since I saw at NI Week (Which was awesome) it was easier to do math in LabVIEW, it might be doable. The graphics interface would be good for the set up and the connection of neurons. If I ever get LabVIEW at home (which I probably won't due to cost) I may try it. To be honest, the hardest part of Neural Nets is data preparation which may or may not be easy in LabVIEW.

So, I'm relaxing on Sunday playing with GA and thinking about Neural Networks, I have to have my fun sometime. Yes...I am a Nerd.

Have relaxing Sunday.

More LabVIEW for more LabWindows programmers

2007-08-18T08:26:00.000-07:00

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

2007-08-17T14:38:00.000-07:00

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!

Moving to LabVIEW...maybe

2007-08-15T18:17:00.000-07:00

We're starting to investigate using LabVIEW for testing here in our group at Lockheed Martin. I'm not a LaVIEW fan but I'm always open to change if it's for good reasons. LabVIEW is for non-programmers. Since our Test Engineering group is mainly Hardware Engineers who think they can write software, but in reality, they typically don't do it well. LabVIEW targets hardware people, you connect graphical objects by "wires".

LabVIEW, like any other programming language needs style and discipline. Some of us have had LabVIEW training some haven't. Some people are dead-set against LabVIEW, some are having trouble with the paradigm shift from structured programming to a dataflow paradigm. There are many hurdles to overcome, some will accept them some won't.

One thing I'm looking into is LabVIEW style. At NI Week (which was really great) a book was available from Bloomy controls called the LabVIEW Style book. We're going to order the book to get some style for our LabVIEW. In a graphical programming, like text based programming, you need discipline to have style. If style isn't archived in text, is it easier in graphical? I don't know if it can be.

There are a lot of questions to be answered about using LabVIEW, we'll have to see how it goes.

NI Euphoria

2007-08-13T19:23:00.000-07:00

After NI Week I'm excited about work, excited about development, excited about the possibilities. I talked to some NI hardware people and I think I could cut down our three (3) bay test set to two (2) or maybe one (1) bay. Our 3 bay test set has a standard scope, signal generator, and spectrum analyzer. Those 3 things take up a lot of real estate and a good bit of power. If those were put down into a PXI form factor space and power could be saved.

We could put all major items in PXI chassis and have a separate bay with power supplies and loads. The Integrated Test Adapter (ITA) would be on the bay with the power supplies. All lines for relays, DMM, Scope, etc would go from the control bay to the power bay with the ITA receiver panel.

With that setup, the instruments would be standard for all setups. The power and loads would be unique for each set up but with some cable standardization the setup could be standard between all test setups.

Just one use of a PXI chassis to shrink a test set, or at least to make it more mobile.

Have a great day

LabWindows for real programmers

2007-08-11T20:37:00.000-07:00

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.

After NI Week

2007-08-10T16:10:00.000-07:00

Wow, what an NI Week! It feels go to a seminar where I felt like it was worth it. It's in the past now, and I have a 6 inch stack of information to go through. I have a feeling about 5 1/2 inches were picked up just to get the swag at the booth or NI was giving out information on LabVIEW that I was thinking would work great in LabWindows.

I did have some fun...On Wednesday, I put on my LabWindows CVI shirt (thanks to Wendy Logan and the LabWindows Users Group) and then went around to LabVIEW displays and say "That's OK for LabVIEW but I bet LabWindows could do it better". OK...that's nerd fun. But then again, I'm a nerd.

I can't wait until they migrate multi-core operations from LabVIEW to LabWindows. Well, I'm off to listen to the band LeFreak...The worlds greatest Disco Band!

NI Week...another day at 'nerd'vana

2007-08-08T21:14:00.000-07:00

I want to make sure it’s clear (in case it’s not clear from my blogs) I’m Joe Engineer, NI Product user and not an NI detractor or any loyalties to NI. I started my blog to express my opinion as an impartial NI user.

Keynote, again, was very good and showed off several of there future products. Something new is NI Labs, NI’s online products beta test site. They are putting their products ready for final beta test out there and letting the NI community at large do the final beta testing.

LabWindows CVI users group was good, we got to voice our opinion on LabWindows CVI and it’s operations. One thing that came out from a guy who did both LabVIEW and CVI development was LabVIEW seems to cause over confidence. People can put together a simple LabVIEW VI and they feel they’re a programmer. Then, after several small LabVIEW successes, they’re given a big project in LabVIEW and they do it poorly. While LabWindows programs are typically developed by programmers, with the understanding, knowledge, and discipline of a programmer.

Also, the VP of applications indicated there are not as many help calls about LabWindows, most likely because it’s done by programmers who can figure things out. Although it was said that if they want more help calls, they should write more bugs into it…like LabVIEW has done. Remember, it was a LabWindows CVI users group.

One guy I work with came last year and said it was boring after the first day. All I can say is he must not have been at NI Week.

NI Week - Tuesday

2007-08-07T14:28:00.000-07:00

Quick Note: Last night I went to 6th street after the NI Festivities and the music was very good, even for a Monday night.

Today, the had very good coffee, fuel of the Geeks and Nerds, and breakfast burritos.

My take on NI Week:
Keynote speakers were very good. They generated excitement about NI's latest product releases as well as upgrades to their own standards, like LabVIEW. The VP of development was very personable. He kept things flowing very well with sever quick hit demo’s and kept it form getting boring with jokes and planned “impromptu” demonstrations and “show us more demo’s. It made me think about possibly doing development in LabVIEW...then I had some coffee and that passed.

I did get to talk to some LabVIEW developers about my reason's I don't like LabVIEW. I have mild Carpel Tunnel Syndrome and all the mouse work that it requires gives me pain in my arm. My doctor says either use the mouse less or get an operation. I don't want to be cut on so it's less mouse. I can use my left hand for the mouse but I don't have the dexterity to connect the wires to the right terminals.

I did suggest, apparently like many other they have some kind of magnify feature so that my left hand can connect the wires. I also suggested that, once a wire is connected, you could "tab" the wire connection to the correct place. That someone like me, could just connect a wire then "tab" it to the right place. They seemed very receptive, but then again, NI is very good at listening to their customer.

We have a Block party for later in the Expo hall...more free beer.

Have a great day!

NI Week - First night

2007-08-06T18:24:00.000-07:00

Tonight was the first night of NI week. I had fun...in a nerdy way. The Expo floor was open for an initial viewing. It's not a huge Expo floor but it's full good information. There are a lot of companies that use NI products. I know that I got a lot of good information, some information on things I wanted to see (Lego Mindstorms) and a lot of information on what I need to be looking for for my company (Test Sets and LabVIEW)

I was impressed by all the vendors, there was a good mix of all NI products users. Some who deal with vision and motion,I('m not necessarily interested in that), some dealing with TestSets, some dealing with sensor's, some with LabVIEW. There were a lot of test solutions houses, the companies who build test sets and develop software to test a UUT (Unit Under Test). G-Systems, a company that builds test sets for Lockheed and other companies, was there.

I have a lot of information from the vendors that I will go through to see what we need now, need in the future, and don't need. That is the problem with these, information overload. Each vendor booth you walk up to you have about 2 to 4 minutes to find out what a company does, figure out if it's something you need or something you may need. Or even something that is not needed but has good swag (Free stuff).

Some companies want to get rid of their swag and some companies want to give away the good swag to those they think are really interested. The trick is to learn enough about a company from their banners to know what to say to get the good swag.

While swag is the perk, information is the what you need to go for. The key is to get what you need (information) along with some of what you want (swag).

I'm now geared up for the seminar's that will come up tomorrow. I also met someone who actually read my blog...Cool!

Have a blogging great day.

NI Week T-1 Day

2007-08-05T07:22:00.000-07:00

Tomorrow will be the first day of NI Week. It's called Alliance Day. It's the day where NI "Alliance" partners have there own get togethers, seminars, and general NI ra ra. Alliance partners are people/companies who are closely coupled with NI. They use and understand NI Hardware, they use NI Development tools...all of them. They know what all the products are, the best ways to use them, they have Certified NI Developers, the experts basically. I'm not an alliance partner nor do I work for a company that is an alliance partner, so I'm not invited. I am interested in learning more about NI products.

NI's main products like LabVIEW, LabWindows CVI, and TestStand. But the alliance partners know about the new and lesser known products. Things like NI Elvis...NI in a white jump suit with rhinestones! Not exactly, it's NI Educational Laboratory Virtual Instrumentation Suite. (It show's NI has a sense of humor) It's a platform for school test with virtual instruments rather than real instruments. It can also be used for rapid prototype, to see how things look before you go into full development.

Another, not-as-well-known product NI Lookout. While it doesn't have as cool of an acronym as NI Elvis, it can be useful. It's for industrial control of SCADA (Supervisory Control And Data Acquisition systems. I'm not a SCADA person but my brother is. I didn't know about NI Lookout until very recently so I couldn't give him any information on it. I don't know if it would fit his application since, when he talks about SCADA I go into meeting mode (My eyes glaze over, I zone out, I have just enough attention going to here if someone says my name). It's just not one of things I'm interested in.

Well, have a blogging great day. My next blog will be after the first event of NI Week...I can't wait.

NI Week T-2 Days

2007-08-04T14:04:00.000-07:00

NI Week is really close. Since it's the weekend I'm not really thinking a lot about the seminar's that will help me for work, the work networking possibilities, or pretty much anything dealing with work. I'm thinking more of the fun aspects of NI Week like the evening activities. I'm not sure what to expect from the evening activities. First, this whole seminar 'nerd'vana for geeks, It's all about technical stuff. But during the events in the evening that are supposed to be fun, there will still be a bunch of geeks...90% guys.

My only experience with seminars is AutoTestCon (Automated Testing Conference) and the evening events from that, while fun with lots of alcohol, were still just a lot of guys just hanging around. I did hear a lot of good geek jokes and they're all funny after a few beers. But how interesting will the NI evening events. NI Week is in Austin Tx and Austin can be fun. I've been to 6th Street many times on the weekends. It's a lot of bars and bands and where the great Guitarist Stevie Ray Vaughn (Originally from Dallas. Tx) was discovered. I've heard a lot of good music on 6th street but I have a feeling there will not be a geek invasion of 6th street.

The first NI Week evening event is on Monday evening, the day before the first main day of NI Week. Here is what the NI website advertises the event as:

"Enjoy food, drinks, and music at the hottest party in the neighborhood! Exchange best practices with fellow developers from a wide range of industries and companies and interact with community leaders in design, control, and test to discuss the latest technical innovations. Also visit more than 130 exhibitor booths to see the newest tools, applications, and solutions using NI products."

I think I may spend Monday night on 6th Street...unless there's free beer at the event.

Have a blogging great day.

NI Week T-4 Days

2007-08-02T19:14:00.000-07:00

It's only four (4) more days until NI Week. I've found out that the festivities begin on Monday evening in the Expo hall. It will be our first chance to see the exhibitors and whatever NI will be showcasing this year.

There are 5 people from our site going to NI Week. This is a pretty big number for us. I also found out that one of the bosses from Test Engineering is going, that makes 6. I don't report directly to him but he does have influence. I see one of three things happening, I avoid him, thus I don't have to deal with him. Since we have different interests I'm pretty sure we'll be going to different seminars. Another posibility is that I'll try to suck up to him. I don't see this happening since I don't suck up well, I either say what I feel or just keep my mouth shut.

What I hope to happen is some bonding. For me it may take some alcohol to want to hang around him. Not because he's not nice, he just doesn't seem to be the guy I would hang around with. I could be totally wrong and we have fun. I maybe learning more at NI Week than just about NI Products. But then, I'm always up for a learning experience, as long as it doesn't kill my career. I'll buy him a beer and see how it goes.

I can guess that he's going to look at LabVIEW. He's pushing our department toward LabVIEW even though many, many of us don't want it. It's a graphical language geared toward hardware people and he's most certainly a hardware guy. I admit I'm going to learn more about labVIEW so that I dis-like it less. Unfortunately, as long as it has a lot of mouse movement and it aggravates my Carpel Tunnel Syndrome, I probably won't like it.

So much for the extended learning opportunities at NI Week. It's still only 4 days.

NI Week T-5 Days

2007-08-01T17:48:00.000-07:00

NI week is getting closer! I didn't have a lot of time to get excited about NI Week today, that 'work' stuff got in the way. It was mostly metrics and Diversity Maturity Model review. Very unexciting, but it's part of the job.

I did talk with our NI rep yesterday. Joel Garner. He's a good guy, NI all the way. He keeps pushing LabVIEW and pointed out a lot of good LabVIEW seminars at NI Week. LabVIEW is NI's big thing and main product. Unfortunately, for real programmers, it's a paradigm shift and a different way of thinking. For real programmers, it's another language in a format that is not really wanted. I'm not really going to say much more about LabVIEW at the moment, but I'm sure there will be more blogs about LabVIEW in the future.

Joel, the NI rep, talked with several of us about what will be going on at NI Week. He had some suggestions on seminars and let us in on which seminar's will most likely be less interesting and why. One of the more interesting one's are "LabVIEW, The Good, Bad, and the Ugly", he says that's one of the more lively sessions.

One of the main things is all the NI experts will be around at different times so we need to get our questions and our suggestions together.

They have activities every evening, I guess it's to keep all us 'wild and crazy' engineers busy so that roam the streets of Austin.

I'll have more interesting information about NI Week, tomorrow.

NI Week T-6 Days

2007-07-31T18:36:00.000-07:00

NI Week is one day closer. I was impressed by the National Instruments NI Week auto schedule helper, even though it didn't easily have everything I wanted.

You have to be logged in and registered for the auto chedule to work, but here's a brief synopsis of how it works. You log in and go to the session catalog. You click on the link that allows you to pick your interests. You can view and pick your sessions along technical lines like DAQmx, or Hands On sessions, or all the sessions. Once figure out how you want to look at the sessions, you you can pick the sessions you're interested in. You just go down the list and pick and the label changes to "interested".

Once you've selected everything you're interested in, you click "auto scheduler". It will set up your schedule and will allow you to resolve your conflicts. The auto scheduler goes through each time slot and lets you know what sessions you expressed interest that overlap each other. From there you pick which which one you want to schedule for that time slot. If a session is scheduled for multiple times, it will let you know and allow you to move that session to another time. Of course, the 2nd time a session is given may have a conflict, too.

Your whole schedule can be set up in this manner. Later, there is an option to manually change your schedule. The scheduler will let you know when you pick a session that conflicts with another. After that you can then export the schedule to MS Outlook, or in csv format or tabbed format. This allows you to have your schedule in almost any tool to carry around with you.

The one thing I didn't like about NI schedule is it wasn't easy to extract all the session at one time. I had to bring up all the sessions at one time, print that, then go to the next time, and print, etc. It's a bit of a problem but not to bad.

They have a lot of good sessions planned, a lot of potential learning. I can't wait!

Have a great day

Road to NI Week T-7 days

2007-07-30T19:00:00.000-07:00

NI Week is coming up. NI Week is National Instruments week long showcase of products and learning opportunities. This will be my first time to go to NI Week and I'm hoping I'll come back inspired. In 2003 I went to AutoTestCon (Automated Testing Conference) and I came back inspired to write a paper. I wound up writing a paper on Simultaneously, multiple UUT testing and I got to go to the 2004 AutoTestCon to present it.

There are several things I want to learn and it sounds like this is the place to learn. Almost all the NI employees will be there to answer questions and they have a lot of seminars on NI products. One thing I want to learn about is NI Requirements Gateway. It's a product to help trace requirements from requirements documents to TestStand to code. The group I'm in at Lockheed doesn't do requirements as well as we should and so I want to find out what we can do to do them better. Also, I want to learn about LabVIEW. I've had training in LabVIEW, I written some LabVIEW, and I've tried to like it, or at least not dis-like it. So far I've failed. I'm going to try to learn to like it...and not come away with Carpel Tunnel Syndrome. (But that's another blog)

One of the things I really want to learn about is Lego Mindstorms NXT. Lego and NI went into a joint venture to come up with an easy way to program Mindstorms NXT. They came with a LabVIEW derivative graphical language that works a lot like LabVIEW.

NI Week should be really great and I'm excited. I'll write more about it tomorrow.

NI TestStand Panel Programming

2007-07-29T14:41:00.001-07:00

It's Sunday, so this will be short. Yesterday I mentioned that to set up calling functions in TestStand a panel was popped up and the information was entered. A HUGE leap National Instruments has made between earlier TestStand's and there current version of 4.0 is getting away from Panel programming.

TestStands sequences resembled a programming language in many ways except for the Panels. Panel's were used to set up sequence steps, it was as if in a language like C, to enter an "i = i + 2", a panel had to be opened, the variable "i" is found and added to the statement, then the operation "=" had to be found and added, etc. Version 4.0 eliminates that. It meant a lot of mouse movement. TestStand is finally growing up.

TestStand 4.0 is more of an Integrated Development Environment (IDE). Group changes can now be made rather than opening a sequence in notepad and doing search and replace on multiple statements. Everyone who starts with TestStand 4.0 won't know the hassle's Pannel Programming, at least with TestStand.

All I can say to NI is thank you for TestStand 4.0...and my carpel tunnel syndrome thanks them too.

Have a good day

TestStand, how it works (Sequences) part 1

2007-07-28T08:08:00.000-07:00

Yesterday, I wrote about my vague, rumored history of TestStand...it put me to sleep, too. But I slept really well!

Today, I just wanted to talk a little about how to get started in TestStand. The New User Data sheet gives a 30,000 foot view of TestStand, the basics of it's structure. My favorite way of getting started on anything is to try it. If you make an account on ni.com and then go this TestStand Download link you can download a 30 day evaluation copy. I believe there is a getting started tutorial that gets you past the basics.

Baically, with TestStand you build test sequences (.seq). That's the start of all things TestStand. A test sequence is a list of steps that do actions, tests, checks, and control. Each step can call and run other programs, run functions in .dlls, diddle (technical term) TestStand variables. make ActiveX calls, call LabVIEW vi's, call other TestStand test sequences, call .Net objects, and probably do a few other things that I haven't tried.

NI took a page from Microsoft ole, their products integrate well together. But one thing NI did much better than Microsoft is integrate with other products. Like I noted above, once you have to specified what type of call you are making with a drop down box at the top of TestStand, you can call almost anything. If you have old code, it can be reused in the sequences.

To use a function, say a dll function, first a step is created. To do this right-click and select add a step. A step is created based on the drop down box at the top of the screen. Then a sequence step is highlighted and you hit m (or right-click on Specify Module...) , a Specify module panel pops up. If you're specifying a .dll, either generically made or made using LabWindows, the .dll, functions can be called from a sequence step. One think I really like about TestStand steps is that once you call out a .dll, all the functions defined with the standard dll declspec can be seen from the panel, you don't have to know what functions.

Bonus Note: Actually this can be handy when you have any .dll you can find out what kinds of calls are available. This is good for looking at just about any .dll, playing around with it, figuring out how it works.

Like I indicated, .dlls are just one way to set up a sequence step but, like may parts of TestStand, they can be very useful.

I'll talk more about sequence steps later, give my opinion on the "Panel" programming paradigm.

Intro to NI TestStand, Part 1, ancient history or untrue facts

2007-07-27T15:14:00.001-07:00

Today, I'm going to start writing about National Instruments TestStand. Of course you can read all about it at the above link, but that's the NI take on things, and it's not my vague, rumored history. Overall, I'm not sure how long TestStand has been around but I know that I've seen some very old version's of it on test sets around work. It's now at TestStand 4.0, although 4.0 has only been out for a few months.

I'm not really sure of it's origins, but one rumor of it's origin is that a test group in a division of Lockheed Martin came up with an example of a standard structure for running tests. It was little more than a main program that you added calls to your own functions that made up the individual test steps. Basically, just your standard program with some standards on how it was set up. The rumor is that it was in the late 80's or early 90's that Lockheed was working closely with early versions of NIs LabWindows CVI instrument drivers. More of the rumor is that someone gave the structure and code to someone at National Instruments. (Note: it was not proprietary code, the rumor continues) NI took the concept and the early code, massaged it, changed it, updated it, worked with it and came up with TestExec 1.0. Little did anyone know how far it would go from those, rumored, early beginnings.

In case people reading this didn't know, Automated testing is typically made up of a series of test steps. Each step would conduct a specific test to check out a Unit Under Test (UUT). I'm sure I'll discuss testing methodologies in the future. TestExec 1.0 did little more than control the test execution steps but it did make it easier to set up your test sequences. But, NI doing the good job at incorporating feedback from the customer that they usually do, worked and upgraded TestExec 1.0 to TestStand 2.0. It began to take on a little bit more of it's modern look. It allowed the test developer to build sequence files for testing.

TestStand 2.0 was a quantum leap for TestStand. NI developed a basic TestStand engine to drive the tests and sequence files to be executed by the engine. All future TestStand versions were built on this TestStand engine and sequence file concept. It has continued to work and evolve over the years.

Well, that's a quick, vague rumor, or set of untrue facts, of the ancient history of TestStand. (Is that statement wishy-washy enough?)

I wrote this because everything that has come before now is history. And since TestStand came before, it has a history. Well, it's obvious my mind is tired from work and I'm starting to ramble semi-incoherently...or maybe it's because I was writing about history. Anyway, I'll stop here for now.

I'll write something more interesting about TestStand and testing tomorrow.

Have a great evening.

Introduction and National Instruments

2007-07-26T16:46:00.000-07:00

This blog will be about various testing issues using the National Instruments products, at least the ones I use. These are mainly LabWindows CVI, TestStand, and LabVIEW. I decided to write this blog simply because I use National Instruments products, I'm always interested in making them better, and I wanted to learn more about blogging. I have to start somewhere, so here I am.

This will be a positive blog, I like National Instruments, and I like their products. However, like every other product, there are good points and not so good points. Overall, there's a lot more good than bad.

NI's website at this link NI. It has an incredible amount of information about NI, it's products, and about automated testing. However, while NI's focus is automated testing and everything around testing, their products can be used for many, many other applications.

Coming up soon is NI Week, which National Instruments showcase of it's products and how various companies use their products. I'll be attending this year for my first time. I'm told it's very informative. I'm starting to gather questions/issues/information needs that can be answered there. All the NI Experts will be there so it should be a good forum to gather information.

NI headquarters is located in Austin Texas, which is where NI Week will be held. This should be interesting, the University of Texas and the Capitol of Texas is in the area. If nothing else, I should be able to get in some good sightseeing.

Well, like I said at the beginning, I'm just learning about blogging, so I'll stop here. I'm always interested in improving so suggestions are welcome. I haven't learned to put pictures in the blog yet, so it may be more spiced up tomorrow.

Thanks for your patience with this noob Blogger.