jzoller

Commercial Off The Shelf

Ben

Side note:

One of the recent ISO standards transforms it to SOUP: Software Of Unknown Provenance.

Joe Z.

Let's make it a three way fight...

Four way?

Note to any generic HR folks out there: that is how to write a "help wanted" ad for a techie: no salary mentioned, no "8 years of Java, 3 years of C++, must be a team player...".

Sorry for gushing, I'm seriously impressed.

Joe Z.

What do the users want?

Usually, performance can be tweaked to work. User-tweaking, much harder.

Joe Z.

Not that I've seen.

You can build your own hash table system with arrays for storage. The actual hashing function is up to you, as are features like chaining and collision resolution.

You can also implement dictionaries, either with parallel arrays, or using the Variant and Variant Attribute types (which have an underlying red-black tree for speed).

Joe Z.

The Google custom search service:

http://www.google.com/cse/

Joe Z.

Unfair as it is, it's still going to cost Toyota jobs, market share, and $billions. My point is simply that perceptions matter.

Good product with a bad rep would be Microsoft, Apple, or Linux (take your pick). Bad product with a good rep... things don't work in that direction for long.

About quality vs. reproducibility: yep. My contention is that overuse of systems like Six Sigma leads to reproducible products that no one really wants.

From Wikipedia's Six Sigma entry: "A BusinessWeek article says that James McNerney's introduction of Six Sigma at 3M may have had the effect of stifling creativity. It cites two Wharton School professors who say that Six Sigma leads to incremental innovation at the expense of blue-sky work."

The next wave seems to be officially sanctioned, process driven "Innovation", complete with consultants and management retreats.

Adds that claim "Our new software is not as buggy as the old stuff!" have probably been copyrighted by MS.

Ben

Well, I suppose it's better than MS' old motto: "Our new software is *much* buggier than the old stuff!"

Joe Z.

You can't possibly support an application for indefinite time without some charge. Even if it is a big fix. We do have a warrenty period on our software but if a bug hasn't been uncovered in that period then it wouldn't seem a critical bug. Also where do you consider the limit between a bug and a new feature? What if your application suddenly misbehaves because of some changes to the system you could have foreseen logically? Is this still a bug or is this some other thing that warrants some charges.

Generally if you work for some production environment those people understand that maintenance has its costs. Computers do get older, system parameters do change, once perfectly running code can get affected by all this. If you do this all for now cost for many years after having delivered a system, you do get into problems with your business plan for sure and you might have issues defending your rights towards your customers.

Maybe your car gets serviced for free every year where you live and any repairs are for free because the car manufacturer believes that his prodcut should run 10 years without any failure but it is not how things work here. That RPM sensor that failed two times causing system check errors? Well normally charged both times! Does it sound like a possible systematic error? One could argue that way as two times the same error in just 4 years is a bit strange. But it is how business works today.

Fascinating that you chose cars as an analogy.

Did you know Toyota's expected loss is around $7.7US billion dollars? Just this quarter? It's their first loss in 70 years. Think how much they could have saved, had they fixed their "bug" in timely fashion.

Do you sell products, or do you sell reputation?

Reputation is worth a lot more.

Joe Z.

I actually have a co-worker who is running into the same problem. Windows 7 64 bit on a laptop. LV Speak does not work on his laptop natively, but if he runs a VM it seems to work. Thoughts?

It looks like the SAPI versions changed between Windows versions.

WinXP uses SAPI 5.1, Win7 uses SAPI 5.4. (http://en.wikipedia.org/wiki/Microsoft_Speech_API#SAPI_5_API_family)

There seems to be a lot of confusion on the matter:

One posting

MS tech note <- not for the faint of C (like myself)

The file needed looks to be "sapi.dll". On my Win7 Pro machine (no LabVIEW), this dll appears in a couple of locations (it's 5.3, though, hrm). Possibly the reference to the dll in the code will need to be updated for the 64-bit version?

2 cents.

Joe Z.

Jeff: For the record, I strongly recommend the SSP for anyone who can manage it. I still don't agree with charging for bug fixes, particularly now that it's technically feasible to separate them from new content.

Chris: Bespoke software and off-the-shelf software are pretty different models... (NI isn't letting you spec out LV, is it? If so, where do I apply!?)

I'm content to remain discontent on the subject... NI will do what they do.

P.S. For some more opinions on the matter, check out: http://stackoverflow.com/questions/426319/should-you-charge-a-customer-for-bug-fixes

Joe Z.

This is Jeff Phillips, one of the LabVIEW Product Marketing Managers. I just wanted to take a moment to clarify a few things:

...

Anyone who purchases LabVIEW 2009 is entitled to that version, the following Service Pack release, and the release the following year (i.e. LabVIEW 2010). If your service lapsed between the release of 2009 and the release of the Service Pack, then that means that you received LabVIEW 2009 as part of your previous service (at a MUCH discounted rate compared to a true upgrade).

...

Respectfully,

Jeff

The above "release the following year" is how you end up without the SSP for the bug fixes.

I think this gets away from the point, though.

If I release code to a customer, the bug fixes are priced in. If they come back to me in two years and say "Hey, we found a bug that matters to us", I'm going to fix it for them, gratis (and have done so). I consider it to be what professionals do.

In the past, NI has released features and bug fixes commingled. Not so much, this time around, but the SSP rules haven't changed.

Personally, I would prefer to buy a single version of LV and get all bug fixes for that version free forever, rather than getting the cheap upgrade the next year.

Joe Z.

http://msdn.microsoft.com/en-us/ff384126.aspx <- Small Basic, a beginner's language

I thought it was interesting, particularly the web and Silverlight integration, and ability to convert it to Visual Basic.

Joe Z.

Funny thing is, if they ship me a bad hardware card, or PXI chassis, they replace it for free.

This has left me with a bad taste for years.

Joe Z.

jzoller = NI forums Underflow http://forums.ni.com/ni/profile?user.id=16166

Haven't posted there much in a while.

The code for generating the typedef and code itself is simple and nice, but there's absolutely no way I would stop using the other solutions (such as the OpenG VIs shown earlier or the MGI VIs) to use this.

This will be difficult to read, difficult to edit and no easier to work with than the other solutions (see Jim's snippet which shows how easy it is to use them, and it becomes even easier when you need to add elements to the cluster).

I can't disagree...

But let me propose some alternative thinking.

First, dependency on external code libraries can be difficult, especially for validation and package maintenance. A fully "native" solution avoids this. (Yes, I know that there is no actual difference, but clients are not always reasonable.)

Second, in my heretical opinion, the generated code should not be maintained. At least, not at the wiring level. If changes are necessary, the code should be regenerated, not tweaked by hand. In other words, generated code should almost never be read, and so readability of generated code is no longer as important.

Now, please note, this isn't to excuse sloppy wiring. Hopefully, the wire cleanup algorithm will improve with time so that the generated files are cleaner, and reduce to the final solution in one step.

Thanks,

Joe Z.

Nice Code.

One suggestion would be to have the generated read code (INI_Read_Test) create a file if necessary set to true instead of false. This would allow for the creation of an ini file if the ini file was not present.

Hi JoeC,

That was actually a style choice: I couldn't come up with a use case where I wanted to try to read a blank INI file. I would rather throw a "missing file" error.

Of course, it's an easy mod to make if you prefer the creation: just set the file create flag in GenINI_Read_Template.vi to true.

Thanks for the feedback,

Joe Z.

Good one. One immediate suggestion would be to design- not to repeat the section name for every key!!!

Hi SAS,

I seriously considered doing that. To do it right, I think I would want to unflatten the data to have another level (that is, an array of Section clusters containing a Key Value pair array).

In the end, I made the decision that the extra constants were easier to live with than the extra complexity in the generation code.

Thanks,

Joe Z.

I love it. This'll go in my LabVIEW\project folder.

I like using the OpenG config file VIs but still have had to make the typedef cluster. Excellent idea.

Thanks,

Jim

Thanks!

I'll look into the ability to abstract out which config files are used... <famous last words> it looks pretty easy </famous last words>

Joe Z.

Over time, I've found writing INI files (section followed by key/value pairs) to be easier than writing the LV code to read and write the INI files.

So, here is a small tool to automate the generation of code for reading and writing existing INI files.

• Download zip, open project, open and run GenINI_Main.vi.
• Point the top file control to an existing standard INI file (like the one included in the Test folder, for instance)
• Click the "Read File" button, and select the Key Type for each entry from the INI file.
• Click the "Generate Code" button to spit out the read and write VI's (saved in the same folder as the INI file).

There are a fair number of limitations and possible enhancements, but I would love to hear any feedback people might have before I complicate this too much.

Thank you kindly,

Joe Z.

GenINI.zip

I'm trying to extend Darren's history probes a little bit. The idea is to use an XControl within a probe to allow better inspection of the data that's being probed.

Unfortunately, the probe seems to end up missing data events if they occur too quickly.

Anyone have an idea of what might be going on, and whether it can be fixed?

Thanks,

Joe Z.

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

I'm no expert on XControls, but a LV2009 demo is attached: the XCon_Probe folder and XCon_Probe_String_History.vi go into the probes folder (On Windows, it's My Documents\LabVIEW Data\Probes). The XCon_String_History_Test.vi goes wherever, with the custom probe placed on the format output string.

XCon_String_History.zip

In addition to reading, I'd encourage you to actually create some object models, on paper, of real world systems.

It's one thing to read about whether the Square class should inherit from the Rectangle class or not (what is it with OO authors and shapes?... and cars?) It's quite something else to try to make the messy, analog world into neat packages with clean interactions. It's fun, though!

Joe Z.

Of course, the term geek originally meant a circus performer who bit the heads off small, live animals.

Such an odd word permutation.

Joe Z.

I know any time one makes a blanket statement about any architecture being "good" or "bad" that there's room for real disagreement - I don't use QSMs but I am sure that there are people (like Joe) who know exactly what they're good for and how to make them work so they shouldn't be dismissed out of hand.

However, I will take exception to the statement about the licensing limitations of LuaVIEW (can't speak to TestStand - I don't use it). With LuaVIEW, the license is per project (or a site license, which I have). At any rate, all deployed apps built under this license are covered under the development license cost - no additional deployment license required - and all developers on the project are covered under the single license. Also, all license management is "honor system" - there's no license management software mucking things up so you don't have to worry about licenses expiring at your customer's site (or for your developers) and getting those angry phone calls. Also, the entire Lua interface is accomplished thru a CIN so there's no additional dll's or run times or anything else that needs to go with the deployment. It's really pretty simple.

Mark

The issues aren't technical (well, primarily, since I've seen LuaVIEW's daemon cause some stability issues), they're financial and company cultural. And (rewrites post 7 times) ...a bit too detailed to go into here. PM me if you're really interested in details.

Joe Z.

mesmith is right: this is a function library, not really a state machine.

I wouldn't try to diagram it. Rather, I'd describe each "function" (or case), with pre- and post-conditions expected. If it modifies a variable with multi-function scope, I would add that as well. I would also document typical use cases for each function and for the program flow as a whole.

However, I see nothing wrong with this style of programming: it's powerful and flexible. The problem with inserting states into other state sequences can be solved by adding a batching mechanism to the architecture (I use a second queue).

I've found the licensing limitations and additional software requirements of TestStand and LuaVIEW are really restrictive in the environments that I work in, and a native LV solution is usually easier to handle.

... then again, I like to build compilers, so maybe this should be taken with a grain of salt

Joe Z.

If you're using MyODBC, you may need to update your driver, or possibly recompile with an optional switch.

From http://bugs.mysql.com/bug.php?id=7445:

A note has been added to the 3.51.18 changelog:

Connector/ODBC now supports batched statements. In order to enable catched statement

support you must switch enable the batched statement option (FLAG_MULTI_STATEMENTS,

67108864, or Allow multiple statements within a GUI configuration). Be aware that batched

statements create an increased chance of SQL injection attacks and you must ensure that

your application protects against this scenario.

I've also added an entry to the FAQ to cover the dangers of batched statements and how to

enable support, and the connection options table has been updated.

As far as cursors, it appears there may be a mismatch between MySQL cursors (http://dev.mysql.com/doc/refman/5.0/en/cursors.html) and the DBCT cursors (http://www.ni.com/pdf/manuals/321525c.pdf, page 62)... not sure how well they'll work together, but I haven't had the toolkit for a while.

Joe Z.

hmmm so you are saying that I can actually keep my version7.1 and install version9 without uninstall my version7.1?

Thanks!

Warning! Installing newer versions after installing 7.1 will remove your 7.1 DAQ drivers.

Such a charming behavior.

Joe Z.

Congratulations!

I expected it to mean something in Japanese...this all has nothing to do with controlling electrons anymore.

Oh, fine

One can guide charged particles through free space using fields generated by guide plates or guide wires. For instance, time-of-flight mass spectrometry uses this: http://en.wikipedia.org/wiki/Time-of-flight_mass_spectrometry.

For the pulse of energy itself, you could use anything that generates a gaseous plasma or free electron cloud: laser, ebeam gun, etc.

All of these (including various ball lightining experiments) require large amounts of equipment and power, positioned very carefully, and aren't terribly useful outside of scientific fields. Hence, no public demonstrations of lightning guns.