How to install an older instrument driver (GPIB) LV2009 eval, 23 days remaining!

Question

Hi..
Still having fun (I think) here trying to "evaluate" LV2009.
I'm sort of happy with the higher level stuff, front pannels, block diagrams, flow control with error signaling etc, so now time to move on and try to talk with the real world.   The Front Panel development UI is a bit of a dog, but I'll live with that.
Anyway...
I have a Marconi 6960 RF power meter (and similar kit) I can use for this "evaluation" and have found a so called driver in the NI developer zone some(i forget)where.   It's a zipfile (no problem) with 4 files in.  .c .h .fp and .doc    Sadly, the .doc though documents the functions of the driver, gives me no clue as to how to install it in LV2009.  It also talks about LabWINDOWS V2.0, and dates from 1997.
(As an asside, most of what I will have to do, will relate to "older" or "Legacy" GPIB or RS232 connected instrumentation, and maybe one or two USB toys.   There is no choice, LV is expensive enough if we go this route.  But it's not even peanuts compared to the value of some of the instrumentation it will need to work with.)
Looking arround this board, I'm not realy any the wiser as to what to do with it.  (This downloaded "driver" code.)  It obviously needs compiling, but with what, and then integrating in LV2009, but how?
I found a link in one sort of related message, something about a driver import wizard, but the link is blocked by some spotty IT type this end, so that is of no help.
The inbuilt help from within LV2009 is sufficiently vague, or over complicated as to be of little use too.
What I need, is a simple, put that there, do this, do that type of procedure.
Again, stumped by simple details, and this is the area I will probably be spending most of my LV life in, from what's being muttered about "upstairs" in the big boss's office earlier.
Any help appreciated.
Regards.
DJB.
Just been "diverted" onto a hardware repair job, so no hurry, for now.
OK... Who let the smoke out?

Answer 1

Hi Dennis.
Yes, I found that page (and many others) but the info there is sufficiently vague, or so OTT for someone who does not know their way arround the darker recesses of LV (yet) to figure out.   It tells me a lot, but it does not tell me in sufficient detail *exactly* how to install a driver that someone else has created, or for that matter, how to find out what "Drivers" are installed already.
As you or someone pointed out, that code was also written way back for another system "LabWINDOWS/CVI" (whatever that was) but it shows up when you search for "Drivers for LabVIEW".  It is also listed as supported by LV7.0 and LV8.0.   Those IDN pages also do not yet (that I can see) make any mention of LV2009.  Is it just me that sees this as somewhat inconsitant and confusing for a new user, when NI are pushing LV2009 at this time?
Someone is now going to tell me that reusing existing older drivers *is* straightforward, but will be vague as to exactly how.
The only "exposure" to LV we've had here in the past/present, is as users of pre-compiled tools and utilities from some of our principles.  And it has to be said, all of them are without exception, extreemly buggy, so much so, I personally wouldnt say they were fit for even internal Beta testing, as they don't handle "unexpected events" at all well.  And some of these utilities could if they screw up, seriously damage hardware in some instances.
We've also found many many times, that anything using "VISA" IO drivers (that word again) is almost garanteed to be troublesome to get or keep working, especialy as one lab/workshop PC might have tools and programs from several vendors on it, and they must all work indipendantly when needed (not at the same time!) without interference from other vendors code or preferences.  For some reason, VISA seems to make that all but imposible.
We have a situation at the moment, where we suspect a "Clash of the VISA's" as we can't reproduce what a customer has reported in the way of bad behaviour of a semi automated test system, but we see other errors relating to the serial IO used, throwing up internal LV runtime error messages, and blank spaces where the *Real meaningfull* comments should be.   It's all pre-compiled code, so we have no way of supporting or debugging it, but try tell the end user that, who's test facility is now at a standstill, untill I can call the East coast USA later today (from the UK) not that I expect a constructive reply till sometime tomorrow, at best.  By then, there'll be Director to Director phone call's going on!
I've also just been informed, that the workshop PC in question, will not now run something else we need, since we earlier installed the program the user is using (made by the instrument vendor) and all it's baggage, so yet another "Fixit" re-install of VISA (this time from Agilent) is needed to complete another job, and that in turn will break something else.  It's a nightmare!
Sorry, but in my book, VISA is a no go for "Serious" multi vendor use.  It's too fragile.   In our industry (EMC and product safety testing) "Legacy" GPIB rules, almost without oposition.  USB and LAN connections may be alternatives where the instrument supports them. With some true RS232 point to point low speed dedicated links where needed (often via passively powered fibre optic convertors too) for some measuring instruments.
But, at this time, all I want to do, is talk/control a simple existing GPIB instrument (a MI 6960, that I know all too well) and I thought (wrongly as it turns out) that I had found a needed "Driver".   If I have to create one from new, I will, one way or another.   But it makes a mockery of the so often quoted aspect of LabVIEW, being quick to construct and deploy a test/trial/control system etc, with an existing vast library of tried and tested instrument/device drivers.  From what I see so far, it's anything but, as it's in the same ball park as all the other RAD IDE's etc (Even Delphi!) in that respect.  The devil is in the detail, and if that detail as often does not exist, it's a task and a half to create it, and get it right.
Sorry if I ruffle any feathers, but I've been arround RF test & instrumentation systems at the hardware and software level for more years (decades) than I care to admit.  Each and every time someone comes up with a "better" way to do something (usualy involving even more computing power!)  It's anything but quick and easy, and the end result is in all honesty, not realy different to how it was done, before "enforced newness" was applied.
Regards to All, I've still got the day job to do, so sadly I can't sit in front of this and mess with software all day.  Much as I need to, and often would preffer to!
DJB.
OK... Who let the smoke out?