Customer Reviews

A Software Engineering Approach to LabVIEW

5 star:		(3)
4 star:		(2)
3 star:		(2)
2 star:		(0)
1 star:		(5)

 

 

This book has the poorest print quality and picture quality that one could hope to find. I have even contacted the printer who says there is nothing they can do and Amazon won't even think about exchanging the book because it has been a while since I purchased it, but who reads engineering books the minute they hit your door?

The book is very well written but the reproduction is horrid. Very few of the figures are readable. It looks like a particularly bad reproduction on a poorly tuned copier. Prentice Hall should refund my money except they refuse to even acknowledge my complaint. I have since found out from a LabVIEW user group that except for an early printing, all of the books are very poorly printed. Unfortunately, the figures contain the most important information. I really wish I could get a clean copy. DO NOT BUY THE BOOK unless you first see the figures!!!! Its vertually useless without readable figures!

This book was a quick read, rather short. About half of the book goes over actual programming concepts, and the other half goes over a long design example scenario. The book is written in a fun engaging way, but in my mind the book costs a little too much for such a short read.

Coming in, I was an intermediate Labview user, and the book has opened my eyes to some better ways to program.

For those of you complaining about the quality of the figures, visit the website at authors.phptr.com/watts. Note that there is a typo in the URL on the back cover!

The content of this book seems excellent, but I cannot stand the poor print quality. LabVIEW is a visual programming language, and most of the diagrams are too blurry to read. I contacted the publisher, and got no follow-up response. If you purchase this book, look through it right away and be prepared to return it at your inconvenience. Prentice Hall should be ashamed. The book is published in New Jersey, but it looks like it was printed on an old dot matrix printer from the 1980s.

The book I received today has a very poor printing - the blurred pictures just cannot be understood.
I'm asking for an exchange, or the money back.
Too bad for Amazon and Prentice Hall's reputation. And also for National Instrument's, that also has its name on the front cover top.
The main question is: there's already been another review complaining on this printing problem - that I unfortunately hadn't read before. Why Amazon keeps shipping this unacceptable quality?
Posted by: l.mendes@pucpr.br

As a self-taught, 10-year veteran LabVIEW developer, reading this book was a huge eye-opener to all the things that you should be doing with a large project. I recently changed jobs to a company that practices RUP, and have been struggling to fit LabVIEW into this development framework. This is the crash-course in software engineering I should have taken in school, but didn't.

Some of the chapters cover topics in NI's courses and online documentation (front panel and block diagram styles, state machines, loose-coupling and strong-cohesion, GOOP). However the real jems in this book are:

1) how to put together software specifications for proposals, including strong focus on pre-coding tasks such as GUI prototyping for customers and post-coding tasks such as testing and metrics for customer acceptance. Much of the architecture of a project occurs at the proposal/specification stage and this book dedicates a whole chapter to it including an example specification;

2) a methodical approach to defining objects ("components" in the language of this book, but GOOP to the rest of us);

3) the concept of data flow designs to section up a larger project into smaller chunks you can get your mind around.

The examples are some of the best I have seen in print. The authors have not chosen overly-simplistic examples, nor have they chosen overly-abstract examples. There are plenty of screen shots and "software meat" to look at.

The other part of this book that I liked was the "Why LabVIEW Sucks" section, which addresses the "C++/C#/VB/.net/[insert other language here] is so much better than LabVIEW, why should I use LabVIEW" question every LabVIEW developer runs into eventually. Sure, they're preaching to the choir here, but they do acknowledge that LabVIEW has a fundamental image problem, explain why they think it has it, and why as an advanced developer you should understand that the problem is its image and not anything fundamentally wrong with LabVIEW.

This is not a book on the mechanics of programming LabVIEW. There are some programming techniques in here (state machines, GOOP), but you can get this for free from NI's website. It is written for the architect of the team (the person doing proposal writing, high-level design, interacting with the customer, etc.), not the code-jockeys actually writing the code.

The text content of this book is informative, succinct and useful. However the figures are all very blurry and it is almost impossible to get much out of them. This is too bad since it seems that the authors intended to convey a lot of information through the many figures. Until this is fixed, I wouldn't recommend wasting good money on the book.

I love "A Software Engineering Approach to LabVIEW". It is a book intended for the intermediate to advanced LabVIEW programmer. It is a crash course on Software Design using LabVIEW as the tool. It introduces the concept of LabVIEW Component Ortiented Design (LCOD) making the development of large applications manageable. LCOD is programming based on Action Engines ( a.k.a. functional global variables), but do not be discouraged by this, because the principles still apply to LVOOP and the ideas of planning/designing your application before laying the first wire still applies. It also has useful information on how to gather requirements, prototype and design the user interface.

The first copies of the book were excellent quality. However some of them are not so good, making the images non readalbe (have we mentioned that LabVIEW is a "graphical programming language"! ). The information is still great and you can access the code through http://authors.phptr.com/watts/

This book was invaluable when I started doing LabVIEW consulting on my own. Unfortunately given that Prentice Hall decided to move it to "on demand" printing (hence the poor quality), I don't think the authors would be encouraged to write any updates anytime soon.

I'm not sure what is the cause of the bad reviews over picture quality. The pictures look great in the edition I have - if there was a problem, it's fixed now. The content of the book is great and gives LabVIEW programmers (both new and old) a quality approach to engineering good code.

I would definitely get this one to add to the reference library if you are or are interested in becoming a LabVIEW programmer.

It is agood book to know the design concepts.Although the print is not clear but the website provides most of the Block diagrams.
Recommended reading for anyone developing and designing using LabVIEW.