Effective LabView programming (Bress) - ebook version

[Blokk]

Hello,

I have just bought this book via google play, as an ebook. Anyone has it in the same format? I would like to use this book as part of my practices toward the CLD exam.

http://www.ntspress.com/publications/effective-labview-programming/

I would like to read it on my monitor, I tried Firefox and Chrome so far, but the visibility of the block diagrams are very bad! When I try to download it in pdf, hoping the quality will get better, I get some kind of Adobe drm protected file...

So maybe I just wasted 25 EUR buying the ebook version?

As I saw it is only available from NTS press as hard copy, is it possible to get this book in Germany in a reasonable time?

[Blokk]

I have found a possible way how to get readable pdf from the google Play.

So, first buy the book in google play. You will notice that, the qualitiy of the BDs are poor, not readable (i tried Firefox, Chrome, but also with my google smartphone and tablet for test purpose). There is an option in google Play books, under My Books, to download pdf. Actually this will download not a pdf file, but a *.acsm file, which is a ticket to download the book from the Adobe Digital Editions. I did this, and the ADE downloaded the DRM protected pdf file to its subdirectory. I was able to see this book in the Adobe program, but only the 1st page. Checked properties, and I saw that it is only copy and print protected DRM pdf, but there is permission for viewing it.

However, I could not open this pdf file with any pdf program (adobe, foxit,etc).

So at this point someone get annoyed, and under 1 minute the DRM protection can be removed using any free tools from the internet. Of course I do not say I did this, since it would be illegal 😉

Anyway, the block diagrams in the pdf file are lets say OK, not 100%, but MUCH better compared to ebook versions... (i guess we can blame google for bad scanning quality...)

[Blokk]

Actually I just asked my boss to buy the hard copy too, I like to read a real book during flights or train travels 🙂

In the book the author seems really like using feedback nodes over shift registers (combined with single iteration while loop) for Functional Global Variables. I am just curious why I see FGV implementations with shift registers like 99.999...% of the VIs in discussion forums, Core teaching material, etc? I also feel somehow the shift register solution more "neat" compared to feedback nodes (cmon, data is goind BACKWARD on the BD! 😄 ). But these are not rational decisions, so I wonder what other reasons led to the present when almost everyone uses shift registers? I know there are many forum posts about performance benefit comparisons, but I would like to see other reasons... Just beeing curious, what others think about this topic 🙂

[JÞB]

The SR is more "Traditional."  Shift registers have existed longer than Feedback Nodes. (Longer than Global Variables even!)  FBNs have the advantage of not needing a single iteration while loop for Action Engines or FGVs (there are differences between an AE and an FGV).  But, the FBN is not always as scalable as a SR Nor, is a SR always more scaleable than a FBN.  They should never be viewed as direct replacements for one another despite their similarities.

For example: A SR cannot "Z(n)" Transform nearly as readably (Especially for large "n" values)  - A FBN cannot output the last n elements (Where n is constant) as easilly.  Both have many uses outside "Action Engines" and the "Engine's Actions" should be thought of before selecting one over the other.  As well as the familliarity of the maintainence developers with the subtle differences with each constructed AE.  

OK so that's a "Non-Answer".

Honestly,  It probably is the "Backward running Wire" required by the FBN that makes it less prone to adoption by LabVIEW Developers (We HAVE been trained to avoid data flow backwards)  and the (optionally) disconnected initialization terminals (Move one initiallizer out three loops in a spaghetti coded BD that needs the Navigastion window) almost seams to teleport data rather than pass it along a wire. Also, SR's are initialized or not- we can tell by seing if the data wired or absent.  The FBN init options are a whole Right-Click away.  This can induce the LabVIEW equivallent of "Sea-Sickness" where we know we are safe but, there is just "something" unsettling about it.  Most LabVIEW developers are "Humans" after all.  On the rare occasion If doubted that the developer was "Human" I've noted the thought process fell well within 30 sigma* of human norm

Spoiler

* 30 sigma is a rough estimate and assumes the process is normally distributed for humans: it may be a trimodal distrubtion with a low incidence of the upper and lower modes or .... well, the potential for the occasional non- human developer is not immediatly rejeced on empirical evidence by this author.

(

[Blokk]

thanks for enlightening some very interesting aspects!

"(there are differences between an AE and an FGV)"

An AE always has at least one FGV, and does some work on the stored data, does actions. An FGV is simply an uninitialized shift register in a one iteration while loop, placed in a non-reetrant subVI to lock. So if we only use FGVs (like read/write actions) we can still have race conditions if we manipulate the stored information outside the FGV subVIs.

This is all I know about AEs and FGVs, is this correct? Or you would add some more to this "comparison"?

thanks!

[crossrulz]

There is a push in the LabVIEW community in the last few years to actually define the Action Engine and Functional Global Variable.  To put is simply, a FGV is an AE that just has a Read and Write action.