I have not yet met with success, but I have a little more experience ;) Since so many people have made helpful suggestions, I thought I'd include the current status.
Just downloaded the most recent version of NI-488.2 version 2.5 off the NI website. It downloaded/unzipped/installed without any apparent issue. The "Devices and Interfaces - Measurement & Automation Explorer shows several different applications in the software tree, but does not recognize either of the two HP-IB interfaces that are installed/attached: - USB to HPIB (Agilent 82357A) - PCI to HPIB (HP 82350) I did go back to the Agilent Connection Expert (it still sees the two devices) I did check the "Enable Agilent GPIB cards for 488 programs" The MS Win XP Device Manager sees both of them. I did learn that you cannot just re-install NI-488.2 from the downloaded zip file, but have to use the MS software uninstall process first. Still no joy in recognizing the interface card(s) Thanks again & Regards, Jerome KC6ENE -----Original Message----- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of David C. Partridge Sent: Wednesday, October 14, 2009 2:27 AM To: 'Discussion of precise time and frequency measurement' Subject: Re: [time-nuts] Getting GPIB to work on HP5382B Universal counter Dave, I don't remember being your college tutor on this - in fact I never was a college teacher, but what you've laid out below is pretty much what I taught all the trainee programmers I had. You've done a very good job of putting it "in a nutshell". The objective of the whole is to achieve understandability so that the next poor sap (this might be you two years later) who comes along to work on this thing (whatever it is) can get stuck in to fix it without having to reverse engineer the thought processes of the original author. Dave -----Original Message----- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Dave Baxter Sent: 14 October 2009 10:15 To: time-nuts@febo.com Subject: Re: [time-nuts] Getting GPIB to work on HP5382B Universal counter Hi... I use mostly NI GPIB cards & adapters, but from the little work I've done with the HP/Agilent stuff, I think the same overall principle applies, re software development for instrument control. First step... Install the USB<>GPIB adapter drivers, tools and utilities "Exactly" as the instruction say to for whatever OS you are running. Run and verify any diagnostics they supply too. If anything does not work as expected, find out what and why. Then, in the folder tree all that will probably create somewhere on your system, there will be some documentation, and probably some worked examples in various languages, VB, C, Delphi etc, as to how to do the basic (as in simple) IO communication stuff. NI is particularly good in that respect, it's been a while since I hand hands on, of any Agilent kit like this. Look around the web. You will not be the only, or first person to be doing this! ;-) Don't expect older kit to conform to the more usual these days IEEE488.2 command structures, or SCPI for example. Modern more complicated protocols are often not intuitive to mere mortals, some can even be downright misleading. In particular, do not expect some older kit to respond to '*IDN?' (an identity query) Some will just take for example a command 'ID'. Do not expect instant results/success! It takes a lot of time and effort to often "reverse engineer" someone else's code (even simple stuff) so you "Fully" understand how and why it works. Take the time needed, it'll pay off in the long term. Try to first talk to/control a much simpler bit of kit, or only do very easy predictable stuff with it, if you only have one instrument. The only "Libraries" you "Need" will be the ones supplied for your programming language, to talk to and control the GPIB controller. Do not expect the instruments manual to tell the whole truth, in regards to it's GPIB functions. Some books are good (older HP for instance) some are totally useless, written by accountants I think. Understand how to use the instrument manually first also helps a great deal. (Something along the lines of know your enemy!) Many manuals have minor errors, that though experienced programmers and users will spot, cuss, and carry on, if you do not have that "time served" experience, they can stop you dead in your tracks. Common misprints, in nth generation photocopies and scan's for example, commas that look like periods, semi-colons that look like colons etc... VB though you can get some versions for free, is probably not the best choice for instrument control (or anything else some would say) But it can be very useful. Try to find the exact same version, as Agilent/HP/NI used in their examples. MS are terrible for changing small details that often cause show stopping problems when trying to do things like this, especialy if you're trying to "learn how to" at the same time. Despite what all the hype will say, do not expect it to be "Easy" or "Quick" (whatever programming language you use, and I include LabView in that respect too!) Programming, and doing it well, in any language, for whatever reason, takes time and thought to get "Just Right", so that all circumstances are covered. Something that many programmers seem not to appreciate. What I mean, is expect errors from the instrument, and the users input (often you!) and make the program robust enough to catch and handle them safely. IF a condition is met (or not) THEN do something you want ELSE take care of any unexpected conditions! As my old college tutor kept trying to drum into us, the programs purpose and function should be easily read in the comments. The "code" is the translation from your comments, to get the machine to do your bidding. Document what you do, in the source comments, line by line at times! You'll save a lot of time when you come back to something later, even only a few days time! Split your code into logical segments, subroutines, modules whatever. Add plenty of "white space" in the source code, it makes reading it so much easier, and also modifying it later too.. One module for example, to handle the GPIB interface. So if you ever give the code to someone else, or you get another PC with a different GPIB system, it's only that part that needs re-writing. Likewise, a separate module for any RS232 IO for example, if/when needed. Another to handle IO to/from the instrument, this can be for each individual instrument, or a common module for several similar instruments. Most instruments you can query to find out what they are, reporting back the model number and often any firmware version. Most useful! Another to do the "guts" of what you want. Where eventually you'll spend most of your time and effort. Processing measurement data, doing the "experiment" in essence... And finally, one to handle the user interface, all the pretty bits etc. Where you can "personalise" it to your taste.. This is usually the first one to be made, in most GUI aware language tools, often much of it is done for you when you make the on screen form. Again, VB (if that is what you end up using) will have many worked examples for you to learn from. The modular approach, does also make it quicker and easier later to make a new software tool or experimantal process, using the same IO but with a different instrument, or the same instrument in a different way. Take your time, don't overdo it, and eventually you'll have that warm fuzzy happy feeling, when all of a sudden, the instrument is doing your beck and call from your software, and doing it reliably!... It's I think second only to rebuilding a dead engine, and the happy time when it first bursts back into life again! If you get "stuck into it"... Expect complaints from partners family (or a persistant hungry cat) as the time will just fly by... Keep a pencil and notepad by the bed. You'll wake up in the middle of the night, knowing exactly what and how to solve some problem you were working on, write it down, draw a sketch whatever & however strange it may be, and then you'll remember it in the morning! ;-) Above all Enjoy! If it's not fun, don't do it, unless someone is paying you plenty to do so! Regards to all.. Dave B. > ------------------------------ > > Message: 7 > Date: Tue, 13 Oct 2009 16:07:38 -0700 > From: Hal Murray <hmur...@megapathdsl.net> > Subject: Re: [time-nuts] Getting GPIB to work on HP5382B Universal > counter > To: Discussion of precise time and frequency measurement > <time-nuts@febo.com> > Message-ID: <20091013230739.58c8db...@ip-64-139-1-69.sjc.megapath.net> > Content-Type: text/plain; charset=us-ascii > > > > I'd very much appreciate any help that I can get in setting up a > > HP5328B to communicate over GPIB. The goal is to log/graph the > > frequency over time of various VFO's projects I'm working on. > > > I am using the Agilent 82357A USB to GPIB Interface, I have > the manual > > for the counter, so I know some of the basic GPIB commands. I've > > downloaded the Agilent IO Libraries Suite 15.5 and it looks > like I can > > send simple commands to the counter, but I am not having any luck > > reading from the counter. > > > I'd like to use Visual Basic to send commands and receive the > > frequency measurements... but need some HP5328B specific libraries? > > I haven't worked with either the 82357A or HP5328B. I have worked with > similar gear. > > I doubt if you need any HP5328B specific libraries. > > Do you have any documentation for the libraries you are using? > > There may be some initialization magic that you need to do. > > Can you find any examples using the 82357A and the libraries you have? > (even if they talk to another type of box, they may give you some > ideas) > > What makes you think you are sending commands? Do lights blink or > such? Or just that your program doesn't hang? > > If I was debugging something like that, I pick the simplest example I > could find and work on it. > > There is probably a reset command. It might blink some lights but it > doesn't send back any data. > > There is probably an ID command to tell you what type of device you > are talking to. If you can get that to work you are over the hump. > > Sometimes things like this are timing sensitive. A delay of 10 or 100 > ms after each send might help. > > > > -- > These are my opinions, not necessarily my employer's. I hate spam. _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.