Rube Goldberg Code

[Hooovahh]

Seriously what is up with that?  I've probably downloaded on the order of a 100 drivers for various hardware devices over the years.  I'd say of those 100 maybe 10 were good enough to be used as is without any issues.  And of those 10 probably 8 didn't meet all of the coding standards that I would expect from a co-worker.  Maybe I'm too critical but I generally spend a few hours re-writing these drivers into something more usable and efficient.  Our lab doesn't often buy random equipment anymore, so if we get some new hardware that needs an API, you can bet that hardware will probably be around for a while, and having a nice reliable set of drivers is important.

[Blokk]

---

@Hooovahh wrote:

Seriously what is up with that?  I've probably downloaded on the order of a 100 drivers for various hardware devices over the years.  I'd say of those 100 maybe 10 were good enough to be used as is without any issues.  And of those 10 probably 8 didn't meet all of the coding standards that I would expect from a co-worker.  Maybe I'm too critical but I generally spend a few hours re-writing these drivers into something more usable and efficient.  Our lab doesn't often buy random equipment anymore, so if we get some new hardware that needs an API, you can bet that hardware will probably be around for a while, and having a nice reliable set of drivers is important.

---

You are right. But for me so far this was the most extreme case. Of course, I did not "meet" that many drivers over the years as you, so I have less statistics to compare the different cases and draw a "baseline" 🙂

[wiebe@CARYA]

---

@Hooovahh wrote:

Seriously what is up with that?  I've probably downloaded on the order of a 100 drivers for various hardware devices over the years.  I'd say of those 100 maybe 10 were good enough to be used as is without any issues.  And of those 10 probably 8 didn't meet all of the coding standards that I would expect from a co-worker.  Maybe I'm too critical but I generally spend a few hours re-writing these drivers into something more usable and efficient.  Our lab doesn't often buy random equipment anymore, so if we get some new hardware that needs an API, you can bet that hardware will probably be around for a while, and having a nice reliable set of drivers is important.

---

Maybe it's just easy to give away crap, and harder to give good stuff away. I've rebuild drivers (NI's as well), but rarely put the update online. It is a lot of work to finish libraries\drivers\toolkits\etc..

But that doesn't explain why companies are so reluctant when it comes to software. Without good software, their hardware isn't worth anything. Jet the treat software as a "necessary evil". Guess most of us had customers like that: "the plan was made in 4 month. Now we have -5 days to finish (=start making) the software!"...

[JÞB]

---

@Blokk wrote:

---

@Hooovahh wrote:

Seriously what is up with that?  I've probably downloaded on the order of a 100 drivers for various hardware devices over the years.  I'd say of those 100 maybe 10 were good enough to be used as is without any issues.  And of those 10 probably 8 didn't meet all of the coding standards that I would expect from a co-worker.  Maybe I'm too critical but I generally spend a few hours re-writing these drivers into something more usable and efficient.  Our lab doesn't often buy random equipment anymore, so if we get some new hardware that needs an API, you can bet that hardware will probably be around for a while, and having a nice reliable set of drivers is important.

---

You are right. But for me so far this was the most extreme case. Of course, I did not "meet" that many drivers over the years as you, so I have less statistics to compare the different cases and draw a "baseline" 🙂

---

I am glad that I don't work with Hooovahh!  Sometimes, you just need S#^t to work!

On a different note:

Spoiler

How the hell do you get IE to turn off the spell checker that thinks I am typing "En Espaniole"

EDIT: hit the "United States" bar before you log in to the forums 😮 and all is well.

[crossrulz]

---

@Hooovahh wrote:

Maybe I'm too critical but I generally spend a few hours re-writing these drivers into something more usable and efficient.

---

The ones I have ran into, the LabVIEW drivers are mostly just wrappers around DLLs.  And you can tell the LabVIEW was an afterthought.  I specifically remember a 1553 driver suite I spent a good portion of my Christmas break making usable (I was bored and found it strangely fun).  First thing I did: make it so that every single VI did not have the exact same icon.  The other things were making consistent connector panes, properly handling errors, a lot of diagram cleanup.

But the ones that really irk me are the ones that have DLLs to do simple SCPI commands.  Seriously?  Couldn't just use the normal VISA functions?  Those I am quick to completely throw away and write my own.

[Hooovahh]

---

@JÞB wrote:

---

---

I am glad that I don't work with Hooovahh!  Sometimes, you just need S#^t to work! 

---

Don't get me wrong I understand those modes too.  But usually when I'm working on drivers and testing communication out, it isn't crunch time yet.  This usually takes place well before anyone can tell me anything about what they want.  All they know is well we have this DMM, and well we have this chamber, and we'd like to use one of these two DAQ systems, and we have no hardware to test with yet.  So I generally have time to get things working well enough with communication.

[Blokk]

---

crossrulz wrote
But the ones that really irk me are the ones that have DLLs to do simple SCPI commands.  Seriously?  Couldn't just use the normal VISA functions?  Those I am quick to completely throw away and write my own.

---

I am really happy when I can deal with SCPI approach, nice and clean 🙂 These DLL calls scare me, I have no real idea what is going behind the curtain.

Ok, another annoying things in company device drivers when they have proper documentation describing the serial communication, they configure even a termination character. But then in the VISA Read/Write VIs they use the "Bytes at port" function with some ad-hoc delay between the request and response 🙂

[JÞB]

---

@crossrulz wrote:

---

@Hooovahh wrote:

Maybe I'm too critical but I generally spend a few hours re-writing these drivers into something more usable and efficient.

---

The ones I have ran into, the LabVIEW drivers are mostly just wrappers around DLLs.  And you can tell the LabVIEW was an afterthought.  I specifically remember a 1553 driver suite I spent a good portion of my Christmas break making usable (I was bored and found it strangely fun).  First thing I did: make it so that every single VI did not have the exact same icon.  The other things were making consistent connector panes, properly handling errors, a lot of diagram cleanup.

But the ones that really irk me are the ones that have DLLs to do simple SCPI commands.  Seriously?  Couldn't just use the normal VISA functions?  Those I am quick to completely throw away and write my own.

---

Agilent Connection Expert.

That was a fail at making SCPI equal IVI.   Probably as bad as the Plug-n-Play project drivers that NI produced about the same time.

Spoiler

Damn it Lili ! go over to feedback

[Hooovahh]

---

crossrulz wrote: 

But the ones that really irk me are the ones that have DLLs to do simple SCPI commands.  Seriously?  Couldn't just use the normal VISA functions?  Those I am quick to completely throw away and write my own.

---

OH YES THIS 1000%.  I have several drivers that just won't work on my embedded Linux RT chassis because it is a wrapper of a DLL.  Now if they would have just used standard functions it would have been no problem.

[bsvare]

I've sadly also met my fair share of horrible drivers. A lot of what I encounter are DLL wrapped VIs. Lately, though, I'd be happy to see that vs some of what I have been seeing lately.

For example, the latest driver I got has this "Init" function:

It requires passing in references to controls I don't use, need to know internal of which port is RS232 vs RS485, and Comport and MacID per connection.  (Among other Rubes).

In fact, the "driver" is just 4 VIs, Init, Status, State, and Main (Demo VI)