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.
Sunday, December 2, 2007
Friday, November 23, 2007
Without testing, how can you be sure?
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.
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.
Sunday, October 28, 2007
Software in Testing
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.
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.
Saturday, October 27, 2007
What is a "Test" Person
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.
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.
Wednesday, October 24, 2007
Testing is Tricky Business
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.
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.
Wednesday, September 26, 2007
Flexability vs. Usability
I've had some family and work issues lately but I'm going to continue this blog, it makes me thinks about what's important in testing.
Lately I've been working with National Instruments PXI 6229 Multi-function I/O board and NI DAQmx drivers. Using DAQmx has made me think about flexibility versus Usability. First, DAQmx is a departure from the standard method of get a handle to a device and use it. DAQmx functions wants a DAQmx task to be created and used. The task is associated with a set of operations, whether they're Digital I/O, Analog I/O, counter operations, A/D operations, etc. The task is then started and runs however long it takes to complete or how long is specified in one of the many operations setups.
This allows the general DAQmx routines to operate on any type of board. The problem is usability. Not all boards support all operations. A Digital I/O does not support counter or clock operations. Not all operations are as clearly unfit as those. Also, it's not known whether the function will work on the board until the software is run and the function returns an error. The PXI 6229 that allows clocked operations but doesn't have a clock which disallows any "clock" DAQmx functions. (Clock operation require using the counter or an external clock on a PFI line) Things like this are not obvious. Another usability problem is that there are many clock functions and it's hard to tell which one is needed. When trying to operate the [nonexistent] clock on a 6229 it's not clear if the function itself is not usable in the situation or if the board does not support it.
The examples NI provides aren't for all boards. The examples won't run on all boards. Some of the Digital I/O examples won't run on boards with Digital I/O.
Overall, the flexibility the DAQmx functions allow inhibit the usability of the functions. NI needs to apply the KISS principle, Keep It Simple Stupid.
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.
Thursday, September 13, 2007
The test development environment
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
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
Tuesday, September 4, 2007
NI and Education
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.
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.
Sunday, September 2, 2007
Requirements help from NI
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.
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.
Wednesday, August 29, 2007
Requirements are Required
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!
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!
Tuesday, August 28, 2007
"We've always done it that way" - argh
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.
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.
Monday, August 27, 2007
More On Fault Insertion
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?
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?
Sunday, August 26, 2007
Fault Insertion Testing
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.
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.
Wednesday, August 22, 2007
Getting test people into the 90's
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.
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.
Tuesday, August 21, 2007
NI Week residuals
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.
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.
Sunday, August 19, 2007
NI is Grea...eeh,it's Sunday
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.
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.
Saturday, August 18, 2007
More LabVIEW for more LabWindows programmers
A lot of the resistance to LabVIEW from LabWindows CVI comes down to change and the unfamiliar. At Lockheed, there is a lot of change going on at the moment. Change is not bad as long as there is a goal or reason for the change. But to many changes at one time can overload people. With all the other changes and one of the bosses wanting to change to using LabVIEW is overloading.
LabVIEW is a paradigm shift from structure programming to data flow programing. I'm not sure if I'm on board for the data flow programming paradigm either. However, I believe LabVIEW and LabWindows can co-exists, as I've said before. I'm not entirely sure the boss who wants to switch to LabVIEW believes they can co-exist, it may be one or the other for him.
Also, some people are resistant to change no matter what the reason, change is bad. I can change their minds, I can only provide information to help allow them to change. None of it is easy, but it's not always as hard as it seems.
For me with LabVIEW, there's always the Carpel Tunnel Syndrome that also makes me not want to change, but that's another issue.
LabVIEW 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.
Friday, August 17, 2007
LabVIEW for LabWindows Users
I mentioned to a Test People who are LabWindows CVI users about the possibility of going to LabVIEW in the future, I was met with...well...resistance.
I am a LabWindows CVI user and I don't want to move away from it (unless it's to C++ and Measurement Studio or Java). But there are hardware guys who may be better at LabVIEW than LabWindows. I believe that there is room for both. The real programmers can use LabWindows CVI and those programmer wanna-be's can use LabVIEW. Since LabWindows and LabVIEW can both be used with TestStand (yet another NI product) both can be used. Or, through .dll's each can interact with the other.
NI is good at listening to LabWindows users (Thanks Wendy Logan) and implementing new features. Even though the features come to LabWindows about 6 months after LabVIEW gets the features. It was good to hear that NI will back LabWindows in the known future.
Hmmm, when will NI make a Measurement Studio like product for Java? ...or COBOL! Well, maybe not COBOL. Just a thought.
Have a great day!
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!
Wednesday, August 15, 2007
Moving to LabVIEW...maybe
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.
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.
Monday, August 13, 2007
NI Euphoria
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
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
Saturday, August 11, 2007
LabWindows for real programmers
Yesterday, I blogged some about LabWindows CVI is for real programmers. I know that LabVIEW is NI's flagship product most of their other products are in support of other facet's of test, I'm still just not enamored with LabVIEWs data flow paradigm and graphical programming.
Throwing together a LabVIEW program is easy for a novice but that doesn't make them a software developer. There's still not the discipline it takes to program with discipline. It's like someone who goes 90 miles per hour on the highway believing they're a NASCAR driver.
The skill and discipline involved in developing a program is more than taking some icons that represent operations, putting them together, and calling it a program. There still needs to be the analysis on what the user wants (the requirements), some design and thought on how to handle errors, some thought behind the coding so that other non-programmers can understand it and follow the data flow.
LabVIEW is targeted to hardware engineers, guys who understand wires, circuits, and not necessarily good programming practices.
Bottom line is that to program correctly in LabVIEW or LabWindow, there still needs to be discipline needs to be applied to both.
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.
Friday, August 10, 2007
After NI Week
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!
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!
Wednesday, August 8, 2007
NI Week...another day at 'nerd'vana
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.
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.
Tuesday, August 7, 2007
NI Week - Tuesday
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!
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!
Monday, August 6, 2007
NI Week - First night
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.
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.
Sunday, August 5, 2007
NI Week T-1 Day
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'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.
Saturday, August 4, 2007
NI Week T-2 Days
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.
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.
Thursday, August 2, 2007
NI Week T-4 Days
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.
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.
Wednesday, August 1, 2007
NI Week T-5 Days
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.
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.
Tuesday, July 31, 2007
NI Week T-6 Days
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
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
Monday, July 30, 2007
Road to NI Week T-7 days
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.
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.
Sunday, July 29, 2007
NI TestStand Panel Programming
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
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
Saturday, July 28, 2007
TestStand, how it works (Sequences) part 1
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 hitm (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.
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
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.
Friday, July 27, 2007
Intro to NI TestStand, Part 1, ancient history or untrue facts
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.
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.
Thursday, July 26, 2007
Introduction and National Instruments
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.
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.
Subscribe to:
Posts (Atom)
