Sunday, December 2, 2007

Good Enough for DAQmx

Define good enough software. It's a very subjective answer, what's good for th developer may be no good for the customer, even though it was eloquently implemented. What's good for the customer may not be good for the developer, it's what the customer wants even though the developer had to use practices he/she tries to avoid.

Saying that, I've been trying to use National Instrument DAQmx software. As a customer of NI I have to think it's good for the developer. It's probably eloquently implemented, a mastery of object use, and development style. It's probably great if you use it all the time and learn it's idiosyncrasies. But, as a part time user, it's not that great.

My problem with it is they tried to cram all operations for several different classes of devices (I.e Digial I/O, Counter/Timers, A/D, etc) into one set of drivers. Some functions have nothing to do with some boards. You can call a function to start a clock on a board when the board has no clock. You can't tell until the function is run.

The DAQmx function set is so feature rich that it will do almost everything for you except wash the dishes. But in order to Read 1 bit off a Digital I/O board it takes at least 4 calls although I did it (accidentally) in 5 with no complaints from the system. I think it's because I had to set up the clock I didn't use for the operation. The main function that actually does the work of reading the bit takes 8 parameters (I think, after about 5 parameters I usually get tired of counting) and I really only use 3 of the parameters.

I'm sure there was some elegant programing involved, but I don't see it as I'm struggling figure out how to read a bit.

No comments: