When is a VI a "driver" ?

[Gary Rubin]

QUOTE (PaulG. @ May 15 2008, 10:00 AM)

LabVIEW SDK: ActiveX, dll's and/or C code drivers written by the manufacturer wrapped in LV Vi's. They usually include "example" programs demonstrating most of the functionality of the hardware along with full documentation*. They cost around $200 - $300.

My experience is that these are usually so poorly written (i.e. overuse of sequence structures) that we end up rewriting them amost from scratch anyway. The Labview SDK's that I've used are often only useful as examples to show the order in which dll functions should be called and how their inputs need to be formatted.

[BrokenArrow]

QUOTE (Gary Rubin @ May 15 2008, 10:48 AM)

My experience is that these are usually so poorly written (i.e. overuse of sequence structures) that we end up rewriting them amost from scratch anyway.

Yep, or so old that they use the old serial driver interface! I just re-wrote a handful of turd balls from [popular signal generator company] into one VI. (note I said one "VI" not one "driver")

[PaulG.]

QUOTE (Gary Rubin @ May 15 2008, 10:48 AM)

My experience is that these are usually so poorly written (i.e. overuse of sequence structures) that we end up rewriting them amost from scratch anyway. The Labview SDK's that I've used are often only useful as examples to show the order in which dll functions should be called and how their inputs need to be formatted.

My experience as well. That's why they are called "software development kits". Kind of like model kits we built as kids. You gotta do a lot of cutting and fitting and gluing.

[Michael Aivaliotis]

QUOTE (BrokenArrow @ May 15 2008, 08:17 AM)

I just re-wrote a handful of turd balls from [popular signal generator company] into one VI. (note I said one "VI" not one "driver")

Re-Write? Uh oh, You're never suppose to use that term. Ever! It translates to: "You just wasted company time and money on a perfectly good piece of code"

Remember, LabVIEW users "Optimize, Modularize and Reuse". Now go forth and practice these terms in your day to day conversation. For example: "I optimized that code we got so it's more modular and can be easily reused in our current and future applications". Now doesn't that sound more salary increase slash promotion worthy?

[Rolf Kalbermatter]

QUOTE (Gary Rubin @ May 15 2008, 10:48 AM)

My experience is that these are usually so poorly written (i.e. overuse of sequence structures) that we end up rewriting them amost from scratch anyway. The Labview SDK's that I've used are often only useful as examples to show the order in which dll functions should be called and how their inputs need to be formatted.

Now you are exagerating a bit . I mean I've seen those "drivers" and they usually come from companies producing some hardware and wanting to make it available to LabVIEW users but they do not have a professional LabVIEW programmer and sometimes even just use the evaluation version of LabVIEW to create their drivers. It's in general a very bad idea to do since the technical support requests those companies create in such a way is huge and they have obviously no resources to support that. Which depending on the customer means: he is writing his own driver or abandones LabVIEW or the hardware in favor of a different product -> both cases result in a dissatisfied customer.

Now I do write VI libraries too and develop "drivers" regularly. Some of them are openly available, some even free and I would hope that those libraries/drivers would not fall under your category of poorly written "LabVIEW SDKs". They definitly almost never use sequences and if they do it is for data dependency only and nothing else.

That there are people that want to still rewrite them may be true but I would like to think that that has more to do with the "Not invented here" syndrome than anything else and I have to admit that I have been going down that path at times in the past too.

Rolf Kalbermatter

[Gary Rubin]

QUOTE (rolfk @ May 16 2008, 02:54 AM)

Now I do write VI libraries too and develop "drivers" regularly. Some of them are openly available, some even free and I would hope that those libraries/drivers would not fall under your category of poorly written "LabVIEW SDKs". They definitly almost never use sequences and if they do it is for data dependency only and nothing else.

Rolf, I'm sure that nothing you release would be considered poorly written.

I'm refering to A/D board LabVIEW SDK's that I've seen that have used up to 14-frame stacked sequences nested within other stacked sequences and local variables to pass data from one sequence to the next.

[BrokenArrow]

QUOTE (rolfk @ May 16 2008, 02:54 AM)

.....I've seen those "drivers" and they usually come from companies producing some hardware and wanting to make it available to LabVIEW users but they do not have a professional LabVIEW programmer........

Rolf Kalbermatter

A company (who will remain nameless), has been in contact with me (more than once) to write some "drivers" for them, but in actuality, the job entailes working on the phone putting out fires for people who are struggling with interfacing LabVIEW to their products. They continually run a job ad that reads something like: provide customer solutions for (blah blah blah) must have excellent communication skills, Help Desk experience is desired, LabVIEW is a plus." This company's president told me personally that he doesn't "like" LabVIEW. When I probed further, I found his opinion was formed from bad example code from the mid 90's and a few of his engineers downloading the eval version and giving up in a few hours. Now THERE is your example of bad SDK's, or turd balls.

Richard

[Gary Rubin]

QUOTE (BrokenArrow @ May 16 2008, 09:11 AM)

A company (who will remain nameless), has been in contact with me (more than once) to write some "drivers" for them, but in actuality, the job entailes working on the phone putting out fires for people who are struggling with interfacing LabVIEW to their products. They continually run a job ad that reads something like: provide customer solutions for (blah blah blah) must have excellent communication skills, Help Desk experience is desired, LabVIEW is a plus."

I don't know whether it's amusing or sad that a company would think that LabVIEW experience is a "plus" but not a requirement for their in-house LabVIEW expert...

[Michael Aivaliotis]

QUOTE (Gary Rubin @ May 16 2008, 04:53 AM)

I'm refering to A/D board LabVIEW SDK's that I've seen that have used up to 14-frame stacked sequences nested within other stacked sequences and local variables to pass data from one sequence to the next.

Thank You! C'mon people. none of you have seen code like this?

I think the hardware vendors should start outsourcing the development to LAVA members.

[Rolf Kalbermatter]

QUOTE (Michael_Aivaliotis @ May 16 2008, 01:10 PM)

Thank You! C'mon people. none of you have seen code like this?

I think the hardware vendors should start outsourcing the development to LAVA members.

My thinking exactly. However quite some of those manufacturers compete with NI mainly on one base and that is being cheaper than NI so I guess that leaves not much space to spend money for real software development especially since NI hardware has been getting more competitive in price too in the last years.

Rolf Kalbermatter

[LAVA 1.0 Content]

QUOTE (Michael_Aivaliotis @ May 16 2008, 02:10 PM)

...

I think the hardware vendors should start outsourcing the development to LAVA members.

Lets hold this thought for a minute. OK long enough.

[set Crazy Idea Mode = True]

What would it take to make "LAVA Cerified" the LV equivelent of "Good Housekeeping" seal of approval?

Vendors could submit drivers to a CR and if they the req's of the code repository, they get certified.

LAVA could be supported by the income.

[set Crazy Idea Mode = False]

Ben

[crelf]

QUOTE (neB @ May 16 2008, 02:42 PM)

[set Crazy Idea Mode = True]

It's not a crazy idea at all, but it's been done: http://www.ni.com/devzone/idnet/ We could offer our services to create or get their drivers to the NI certified level though...