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

[LandyRover]

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.

[AdnanZ]

Well, if it's .c, then you will need a C-based compiler to compile it. And, then you can create a DLL and call then DLL in LabVIEW. Have you programmed in C before?

[PJS]

There is a misconception.  This is not a driver you are looking for (although we do call them that here), your looking for the API to access the Marconi, and I did not happen to find one here either.  If you have the manual, you can easily write your own.  The GPIB commands should be in the user manual or maybe a programming manual.  Trust me when I tell you, that most of the drivers you will download from the instrument driver section will probably be tweaked by you anyway.

You can use  measurement and automation explorer to access your GPIB card and send and receive commands to make sure they work.  

Fortunately a power meter is usually a pretty simple device in that there is not a great many commands you will need to send.  

Someone here may have their 'drivers' for your instrument that they will share, but believe me, not very hard.  

Plenty of people here have experience at writing instrument 'drivers' from scratch, so getting help is not going to be a problem.

 

One piece of advice is to develop a utility that has a VISA Write followed by a read... would not be a bad idea to put a static wait between them as some RF instruments take a bit of time before returning their answer to a query.  I am willing to bet that 99% of Labview programmers who do GPIB instrumentation have this utility in their  library of utilities. And hey, just created my first snippet in LV2009.   

Good luck

[Dennis_Knutson]

At the bottom of the main Instrument Driver Network page are some links that explain what a driver is and how to use one. What you have found is an old driver written for LabWindows/CVI. LabWindows/CVI is an ANSI C compiler from NI. With the wizard that you mention, you can import LabWindows/CVI drivers into LabVIEW. What the wizard does is use the Call Library Function Node to call functions in a dll created in CVI from the C source code. Unfortunately, this old and unsupported driver was never compiled into a dll so the wizard cannot be used. Unless you get an evaluation copy of CVI and create the dll yourself, you would have to ask someone the CVI board to create the dll.

If you do not have an instrument that has an existing LabVIEW driver (or has a supported CVI driver with dll), you can create your own driver. Another alternative would be to use the Instrument I/O Assistant that comes with LabVIEW and the installation of the VISA drive, to communicate with the instrument.

[LandyRover]

Hi...

Yes, I have programmed in C before (and C++) but considering it's the only programming language I've had any formal training in, (way back when the K&R second edn' book was the latest&greatest etc) I'm pitiful at it these days, having spent most of my working software time, wrapped in the arms of Delphi (Object Pascal, with probably the best IDE of all.)

Seems this may be slightly irrelivant anyway, from other replies.

I have libraries in Delphi, that compile to Win32 DLL's that I can and do use to get to instruments in other software environs, and yes we have the manual, also yes, indeed most RF kit *Needs* time (in this case up to 30 seconds for a low level signal, not that we'd use it that far down!) to get a reading.  I also know that is is posible to get C code, to use third party DLL's, obviously specifying the Pascal calling convention, where supported.  (GCC does not seem to, or if it does, it's buggy.   Off topic..  Sorry)

Also, some of our bigger stuff, will need *Lots* of continious realtime status&error checking...  Or the magic high presure recirculating smoke finds a way out!

Regards.

DJB

[LandyRover]

Hi...

Indeed, as in another post in this thread, that's what I've done in other software environments (Delphi etc.) in great detail.  I'm no stranger to real time IO and control, that's what I do, as well as make/drink coffee/tea etc...

I need to learn how to do much the same in LV, and I can immagine that most of the instruments and devices our existing and prospective customers will be using, with a few exceptions, will be unique to them and our "industry" (EMC testing.)  Therefore, any existing or plagurised drivers will almost certainly need some gentle (and not so gentle) tweaking to work as needed.

Is there a detailed tutorial fully exploring GPIB/Serial IO?  Much like the infamous Getting Started document, but in more detail in regards to *Real World* IO with clasic GPIB/Serial systems.   (Section 4 is a bit thin in this respect.)

Cheers.

DJB.

[LandyRover]

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.

[Dennis_Knutson]

I don't agree with your assessment of VISA. I've been using it since before it's offical release and would not use anything else. It is no more fragile, imho, than the low level drivers that is calls. I don't understand why you might have VISA from different vendors installed. If you are using an Agilent GPIB controller, then yes you would need Agilent VISA and enable tulip support (if using LabVIEW) but for different instruments, you do not need that company's version of VISA.

p.s. On pages with an actual LabVIEW driver, there are detailed installation instructions.

      On the download page for the CVI driver, it does not mention LabVIEW support.

      Drivers as defined by NI, are not supposed to handle 'unexpected events'. That is the job of the programmer and part of the application.

      If you can find any other programming language with as many existing drivers that NI provides, I will pay for your license. I think you'll be hard pressed to find more a couple native Delphi drivers. It's extremely naive that you would expect each and every instrument ever manufactured (in your case an obsolete instrument) to have a prewritten driver.

[LandyRover]

Hi again Dennis...

Just back from the bench, another sick amp fixed, so catching up with this before going home.

It's a fact sadly that with the information available to "Users" of the pre-compiled code that different third parties spit out that in turn use VISA drivers, they do not coexist on the same PC very well, if at all.  (Unless you dont use them.  Then they coexist fine.)  If they try to use just one VISA driver library, whoever's that may be.

The reason for different installs of VISA from different vendors, is that programs that use them from Agilent for example(there are others) just DO NOT WORK with the VISA drivers from NI, and vice versa.  We (and I don't know how many others) have found to our cost and frustration ourselves in this situation too many times.

If they should be cross-vendor compatable, prey tell us how?    It does make sense that NI VISA drivers are needed for NI GPIB cards, and Agilent VISA drivers for an Agilent/HP GPIB (HPIB?) card.  But in most cases, we are talking about plain RS232 serial IO, so the hardware is the exact same.  In fact, on the workshop PC in question this morning, it had not got (to my knowledge never has had) any GPIB IO installed at all.  It's only used with RS232 devices.

Maybe there could be, or is already (with automated install's you never get the chance) a way to put for example Agilents VISA drivers in one place, and NI's in another.   From memory from this morning, when we installed the Omnia program with it's NI drivers (from the time of LabVIEW 6.x) the only choice we got was to install NI VISA, or not.  We know that even though that PC had a working VISA system on it (another vendors program was being used earlier, with no problems)  the Omnia test program is not be able to use it, because of some compatability issue.  So, we have to let it put it's own baggage in the system, and that no doubt overwrites other apps pointers or registry entries (whatever VISA uses to announce itself) so it can work.

Often such installs will go ahead blindly with no prompting of the luckless user that there is something that is going to be overwritten.   Result, total mayhem.  For many of us, the only "VISA" that works, is the credit card! (And that can work out expensive in other ways!)

As to LV's collection of instrument drivers, I dont doubt for one moment that LV has a massive collection, just that for what we and our customers do, the selection seems poor from what I've seen so far.   In the last 20 years, I can count on the fingers of one hand, the number of times I've seen any "Live" labview system actually running an EMC test.  I've seen it exersising and monitoring the EUT many times, but not performing the test itself.  I also know several customers who have tried writing their own in LabVIEW, rather than spend money on a third party program from the likes of us.  Some succeed in a small way, but eventualy they end up spending big bucks on software from the likes of R&S, Teseq or us, because it generally works with the equipment they have, and more importantly, the methods and procedures they use are known and approved within the industry.

As for "Delphi Drivers", Delphi is a general purpose programing language/IDE.  Much like Visual C, or Visual Basic (it's compeditors, among others.)  There is large selection in Europe of test and measurment tools and utilities written with it, most are very robust and stable, using NI GPIB too.  As well as native COMx: support (Serial IO.)   There is rarely if ever (I wont say 'never') any compatability problems with a program from one supplier, corrupting the IO system so a program from another vendor will not work. (There are one or two that don't release resouces correctly if something error's, but that's another issue.)

I just went through the Starting LabVIEW, Instrument Driver creation project, from a template.  I was suprised that it defaults to VISA only IO.  Other than blanking the whole thing, and using somthing like "PJS" showed (Thanks Paul) it just would not talk GPIB.    I can't give you details, as searching the help system (in regards to the VISA subsystem initialisation module) deadlocked the entire LV environment again, and at 18:17 I've had enough for one day.

I do know, that tomorrow morning when I restart LV2009, it will give me an option to restore the last session that didn't get formaly closed, that is a neat feature, it has to be said.

Cheers All..

DJB  Going to play with the traffic!

[Dennis_Knutson]

VISA drivers from NI do in fact work with Agilent VISA if you install everything correctly. I have done that. In 99% of the cases, you simply have to enable tulip support and/or correctly selecting the primary and secondary VISA. If you are not using LabVIEW, then there is no reason to install NI's VISA and you can use, for example, IVI drivers from NI with any other programming environment.

If you were to look at instrument drivers from any of the large companies, you will see at most three options - native LabVIEW, IVI-C, or IVI-Com. All are based on VISA. All are designed to be portable and for the most part, in my experience, are.